NuGet: Install separately or all at once as dependency? RRS feed

  • Question

  • I would like to ask what's considered to be the "best practice" in cases like these: I need two packages equally, Mimekit and Mailkit. But Mailkit is dependent on Mimekit.

    Should I install Mimekit, and let the other needed package be installed "passively" as dependency, or install both separately?

    The thing, if I only install Mailkit, Mimekit isn't shown in the packages window in VS (it's there when you expand Mailkit). It's perfectly logical of course, given the dependency, but I find that somewhat confusing, because I need them in equal priority.

    If I install Mimekit separetely first, and then Mailkit, both are shown separately. And this way I am sure I have installed both of them.

    The same issue happens with all those Microsoft.Extensions.* packages: Should I install the package I need separately, or go with the other package I also need that has that package as dependency etc.

    So what's the best practice for this?

    Saturday, April 4, 2020 6:49 PM

All replies

  • Hello,

    There is no best practice per-say but instead personal choice. Since you know they are there are one depends on the other it's a moot point.

    My preference, especially when starting a new project using Entity Framework Core, my choice is to install the SQL-Server package which does all the dependencies (and there are a great many) rather than installing the base package then installing the Sql-Server package for EF Core.

    In all cases the dependencies are there, that is the important aspect in the end.

    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    profile for Karen Payne on Stack Exchange

    Saturday, April 4, 2020 7:10 PM
  • Hi,

    Thank you for posting here.

    In my opinion, there is no need to install all the dependencies separately.

    For the developer, when he can think of this problem, it means that he knows the required dependencies, so it does not matter whether it is displayed or not.

    For users, they don't care about this at all.

    So, as long as it does not affect the function, it is enough to install Mimekit.

    Of course, this is just my personal opinion.

    Best Regards,


    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

    Tuesday, April 7, 2020 6:31 AM
  • It depends on what type of app we're talking about in my experience.

    If you're using PackageReference then when you build it will pull in all dependencies. In this mode you should probably only reference the packages that you explicitly use. In your case if you explicitly call MimeKit then include it as a dependency. This serves 2 purposes. Firstly it ensures you are using the latest version because you depend on it. When you rely on dependency detection in NuGet the "unreferenced" packages will use whatever version the requiring package uses (within its limits of version ranges it specifies). Secondly, if the dependency is removed from MailKit later then your code will continue to work. Nothing is more frustrating than upgrading a package and suddenly packages you relied on disappear and you have to add dependencies on them.

    If you're not using PR then you can run into dependency issues. When you build, dependencies are pulled into the current project but it doesn't extend beyond that. So if project A relies on project B and project B relies on packages C and D then project A won't always copy the package C/D assemblies into its output which results in build errors. This is most common when the referenced packages are not direct dependencies. But unfortunately it doesn't show up until runtime. We've been bitten by this more than once so for non-PR apps we always include all packages we rely on.

    Michael Taylor

    Tuesday, April 7, 2020 2:08 PM