none
Using mimekit nuget package (via paket) in common project removes existing System.net.http.dll from other projects referencing in common project RRS feed

  • Question

  • I had added a new reference of mimekit library (added mimekit and mailkit via paket) in common project used by several other projects.

    To use mimekit I used below code:

    using MimeKit;
    namespace Project.Common.Email.Interfaces
    {
        public interface IMailKitBody
        {
            BodyBuilder BodyBuilder { get; set; }
        }
    }

    But while building the complete solution, System.net.http.dll is getting removed from one of the dependent projects having reference of common project and another project which actually have a reference of System.net.http.dll.

    And as soon as I remove this file from Common then System.net.http.dll starts appearing in the dependent project.

    I know Mimekit is dependent upon System.net.http.dll and it could conflict with existing one in dependent projects.
    I have already tried following things:
    -removing System.net.http.dll reference from common
    -Setting Copy Local property of DLL to True 
    -Adding reference System.net.http.dll from package folder

    Could anyone help me out how this problem be resolved?
    Thursday, May 2, 2019 1:24 PM

Answers

  • I understand that System.net.http should never be copied to output folder and I believe that's what wrong with the project; and it might be happening because we are using Fake Core SDK to build the project. Since I can't change existing behavior of project for not copying System.net.http as it will break many things.

    So today I found one solution where I am not copying Mimekit locally (source of my problem) from common project to child projects, now it would be child project responsibility to bring Mimekit library into their output folder (via nuget) so that when reference of Mimekit is required by Common project then it can use child project Mimekit.dll

    And the conflicting solution where System.net.http was not getting copied, is not conflicting anymore and copying system.net.http in their respective output folders.

    Wednesday, May 8, 2019 1:21 PM

All replies

  • What framework are you targeting? System.Net.Http is shipped as part of the framework if you're using NET Framework but it ships as a NuGet package when using .NET Core. If your target is .NET Standard you'll take a dependency on one vs the other. Depending upon what framework version you're targeting (e.g. 4.7.2+) then the assembly might show up in the output but it'll thunk to the framework version if needed.

    Looking at the NuGet page for this package, it only has a dependency on System.Net.Http when targeting .NET Standard/Core. For a regular NF app then it doesn't need the reference in your project. Are you actually getting runtime errors or something? Out of the box your code is only going to depend on assemblies that are actually being used. Everything else will fall away. This is determined at compilation time so it shouldn't cause any issues.

    You shouldn't ever directly add a reference to a DLL in a package. Use NuGet for this only. You'll cause problems if you try. Personally I'd recommend that you remove the NuGet package and then remove any references to System.Net.Http in your code unless you explicitly have a dependency on it. Then add the NuGet package back in. Then compile and run and it should work fine.


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, May 2, 2019 1:53 PM
    Moderator
  • Thanks for your reply on it.

    I am targeting 4.7.1 framework and using .NET Core, when new dependency of system.net.http is added then it's done via nuget only, but the existing dependency in a different project is shaken due to that.

    Existing dependency system.net.http was copying it locally and using it, but as soon as I use code from Mimekit library it removes that DLL from folder and project using that DLL fails are runtime looking for dependency.

    Since I can't change existing dependencies and have to use new one as mimekit needs it, so can't figure out the way in which both should work fine independently.


    Thursday, May 2, 2019 3:11 PM
  • You cannot target both NF and NC. They are platforms. Your app determines the platform and any class libraries should target .NET Standard.

    You shouldn't be copying a NF assembly locally under any circumstances. In fact it wouldn't have any impact. The NF assemblies are signed which means the runtime will always try to pull the assembly from the GAC. Since it is a framework assembly it'll be there. Your local copy would never be used. The only care where it might possibly be used is if your app targets, say .NET 4.7.1, and the user doesn't actually have 4.7.x installed. In this case it wouldn't find it in the GAC (assuming the assembly version had changed, haven't looked) and use your local copy but in this case you're actually running on a platform that isn't installed so I would expect bizarre behavior as your app runs.

    Here's what I believe you need to do. Please follow these steps and confirm your app works.

    1) Remove all references to the Mimekit NuGet package.

    2) Remove all references to System.Net.Http.

    3) Add back a reference to the NuGet package where needed.

    4) Recompile and run your code.

    5) If you get compilation errors about System.Net.Http then go into only those projects and add a reference to it via the Framework references. DO NOT change any of its properties.

    6) Recompile and run again.

    If this doesn't work then please post the exact errors you're getting. Again, you should not be setting any assemblies to copy local.

    Now, it also matters where the dependency is coming from. If you're adding Mimekit to a .NET Standard/.NET Core project then you're using the SDK format and therefore you don't need to include dependencies explicitly. The project system will figure out the dependencies and add them at build time. Furthermore the NuGet package will detect that you're using .NET Standard/NC and rely on the NuGet version of System.Net.Http. This is also fine and correct. At build time it will likely copy that assembly into your output and that is also fine. However at runtime if you're using NF 4.7.1 then it'll use the version from the GAC, not your local copy. If you're running on NC then it'll use your local copy. Either way it will just work. If it doesn't then, again, please post the exact error you're getting.


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, May 2, 2019 4:03 PM
    Moderator
  • Hi

    Is your problem solved? If so, please post "Mark as answer" to the appropriate answer, so that it will help other members to find the solution quickly if they face a similar issue.

    Best Regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, May 8, 2019 6:48 AM
    Moderator
  • I understand that System.net.http should never be copied to output folder and I believe that's what wrong with the project; and it might be happening because we are using Fake Core SDK to build the project. Since I can't change existing behavior of project for not copying System.net.http as it will break many things.

    So today I found one solution where I am not copying Mimekit locally (source of my problem) from common project to child projects, now it would be child project responsibility to bring Mimekit library into their output folder (via nuget) so that when reference of Mimekit is required by Common project then it can use child project Mimekit.dll

    And the conflicting solution where System.net.http was not getting copied, is not conflicting anymore and copying system.net.http in their respective output folders.

    Wednesday, May 8, 2019 1:21 PM