We are going to publish one of our commercial components, a .NET grid control, as a NuGet package. The product is separated into 2 DLLs - one is the core functionality, and the other is the design-time support assembly. The core assembly can be redistributed as a "normal" DLL and can be placed into any location. But to make the whole product work properly in VS IDE, the design-time part should be installed into a special folder like the Visual Studio PrivateAssemblies folder or into any folder with a special registry key that points to it. Do NuGet packages allow us to do this?
You need to use Chocolatey packages for a run-time dependency like this. NuGet packages are [designed for] for build-time dependencies only.
See http://chocolatey.org/ - Chocolatey uses NuGet under the hood, but has a different focus. You'd probably use NuGet for the "anywhere" DLLs, and a separate Chocolatey package for the VS designer support.
Related
Suppose I am building two class libraries in a single solution in visual stuido. The projects are called "Core" and "Extensions".
Extensions depends upon Core.
I would like to publish these as separate nuget packages for other developers to consume, because while the Core package would always be used, the extensions package just provides some optional functionality.
When I am developing the solution in visual studio, however, it is much simpler for me to set a project dependency from Extension to Core. Otherwise (in a naive approach), building the whole solution would require the following steps:
In visual studio, commit and push Core.
Wait for the CI server to build Core and publish the nuget package to our internal feed.
In visual studio, manage nuget packages for the Extensions project.
Connect to the internal nuget feed
Get the updated Core nuget package.
This approach would work, but is obviously very tedious.
The main difficulty I have been encountering while researching how to do this is that the way all of these things interact has been changing quite rapidly over the past few years, with sdk vs non sdk style projects, nuget pack vs dotnet pack vs msbuild pack, and so on and so forth.
Perhaps the most relevant, most recent answer appears in this question How do I create an individual nuget package for each project in a solution, with project references converted to nuget dependencies? however the answer is now quite old, and is for a dot net framework style project (using packages.config), not a .net5 project.
So, can anyone provide up to date advice on how to correctly accomplish the following:
In a visual studio solution with multiple .net5 class library projects, have dependencies set up as project dependencies at dev-time, but convert each project to its own nuget package with the equivalent package dependencies at publish time.
I have a visual studio solution (microsoft visual studio professional 2017) with a main project, that uses classes from a DLL project in the same solution.
The DLL is a "class Library (.NET framework).
Main project is (for my preliminary investigations) a console app. Future versions will be a WPF. I think that the problem appears on all applications that use DLLs that use other DLLs.
The DLL uses other DLLs from a Nuget package. In this case: SQLite. I want to hide to my main project that my DLL uses Sqlite. That makes it possible to change it in future versions to a different database, or maybe use entity framework to access the data.
So my main project only knows that it uses the DLL in the same solution. It does not know that this DLL uses other DLLs.
Problem: These other DLLS are not copied to my main application folder.
This has been asked before: Copying a DLL's dependencies in Visual Studio
The answer says that you should use classes from the Sqlite to make sure the DLLs are copied. That is just what I wanted to prevent: users of my DLL should not have to know that this DLL uses SQLite
That question is 11 years old.
I wonder if Visual Studio has now a better solution for this.
A method to solve the problem was given in Install and manage packages in Visual Studio using the NuGet Package Manager. It is not ideal, the main project still needs to know that the other projects use certain Nuget packages, but at least you don't have to edit the .csproj files, nor type command lines
MySolution
MyMainProject. Refers to MyDll
MyDll. Uses Nuget packages
In Visual Studio. Menu - Tools - Nuget Package Manager
The window that opens shows the installed Nuget packages. If you click on them, you can see on the right the projects that use these packages.
For all installed packages that your main program complains that it is missing at run time, check the box near MyMainProject. At the bottom click Install.
Alas, I'd rather have something in project MyDll that tells everyone who uses this DLL that they also need these Nuget packages. But for the time being I'll use this method.
Will check again in 11 years if there is any improvement.
I am trying to use some references in Visual Studio, I have installed NuGet to use some libraries.
Is there a way to use only part of the package installed with NuGet? For example, if I am using TeklaOpenApi and the following .dll files are installed with this package:
TeklaModel
TeklaDialog
TeklaDrawing
Use for example just TeklaModel, could I do this using NuGet?
Is there a way to use only part of the package installed with NuGet?
I am afraid that you cannot get what you want. It is designed by nuget package. Usually, when the nuget package contains other dlls which means they are probably depended on a master DLL, or used at runtime.
All of them play an important role in this nuget, so we cannot easily remove them.
Although we can use Assembly Reference format(Right-click on References-->Add Reference--> choose one Dll) to reference the specific dll, but there is a risk that if the DLL depends on other corresponding DLL, an error will be reported. So we don't recommend it.
The best way is to install the whole nuget package with all the related dlls.
Hope it could help you.
Visual Studio interfaces with NuGet via a dll, but the command line tool is solely an exe (nuget.exe).
Is there a reason they don't share a common library? It seems like this introduces the risk of allowing for code divergence between the dll and exe.
Visual Studio and NuGet.exe share a common library called NuGet.Core.dll. Things have changed a bit with NuGet 3.0 but they still share dlls.
The NuGet.exe has the NuGet.Core.dll merged into it instead of having a separate file.
I don't get it - can someone please explain to me why I should use NuGet rather than installing a bunch of libraries via a setup.exe or MSI? What advantage is there?
For example is it better to install Entity Framework 4.3 via NuGet rather than downloading the setup? Also, if I install entity framework via NuGet then is it available to any new solutions or projects that I create (bit confused here).
Basically what does NuGet do that a normal install doesn't do (or vice versa!)
Besides making it simple to add a package to your project, I think NuGet's biggest advantage is dependency management.
NuGet allows project owners to package their libraries as packages. Before, if they depended on other libraries like log4net, they would include those assemblies in their setup/zip file and upload to their web site.
With NuGet, they simply add a reference to these external packages in the .nuspec file. When NuGet installs the package, it will see that there are dependencies and will automatically download and install those packages as well. It also supports conflict management so that if 2 packages depends on different versions, it will figure out the correct one to install.
I think the best way to determine if NuGet will work for you is to actually try using it. I'm sure that once you do, you'll realize that it has many benefits.
Nuget provides several additional benefits:
it automatically configures your projects by adding references to the necessary assemblies, creating and adding project files (e.g. configuration), etc.
it provides package updates
it does all of this very conveniently
What advantage is there?
Nuget simplifies third libraries incorporation : With a single command line (Install-Package EntityFramework) you make your package available for your project. Instead of googling-find the package-download-setup-reference the package in your project...
Auto-Update is not mandatory, Nuget configuration file let you specify the version, or the range of version, that your application is compatible with.
Also, if I install entity framework via Nuget then is it available to any new solutions or projects that I create
Once you installed a package, dlls are copied in a directory at solution level, you can then reference them from there in others projects of your solution.
For each new solutions, re-installing packages is a better solution. As it is very easy with nuget, it won't be a problem.
Nuget contributes to creating a DLL hell and makes the solution go out of control very quickly, especially when different versions of so called "packages" come into play. Apart from assembly versioning, there are now nuget package versions. Nuget is just adding another wrapper over DLLs and does nothing that would make developers' life easier.