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.
Related
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 have a proof-of-concept solution that has a .NET Standard project in it. I use Paket to manage my nuget dependencies. I am able to use paket add and dotnet restore, per these instructions, to add a nuget dependency to that project. When I reopen my solution, I see that a paket.references file has been added to that project, and that a "NuGet" section has been added under the project's "Dependencies" section in "Solution Explorer".
I'm curious, how does VS2017 know what dependencies to list that "NuGet" section?
From the instructions I linked to above:
In contrast to traditional .NET projects Paket will not add assembly
references to your project files. Instead it will only generate a
single line:
<Import Project="..\..\.paket\Paket.Restore.targets" />
This hook tells the .NET SDK to restore packages via Paket's restore
mechanism. A nice benefit is that your project files are now much
cleaner and don't contain many assembly references.
I'm sure I'm missing something, but I don't see anything in Paket.Restore.targets that would tell Visual Studio where to look to find the dependency chain of the nuget package I added to the project. There are no direct references to any dependencies mentioned in the project file.
For context, I have a repo where I'm trying to add a .NET Standard project to a solution that is full of .NET Framework projects. I'm running into an issue where paket add seems to correctly create a paket.references file for the new project, but dotnet restore doesn't seem to be causing the project references to update, resulting in my project not having a reference to the nuget dependency I'm trying to have it reference. I'm having trouble creating a reproducible example (my proof-of-concept seems to be working fine), so I'm trying to better understand how this infrastructure works to help with debugging.
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
Why do we need them?
What is done / changed in our project when we install each one of them?
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Before any comments or misunderstandings: this answer is NOT composed by me, but it was accepted as an answer here, so for the sake of the users trying to find an answer to this, I am literally Copying the answer to your question in this place.
What is the difference between a NuGet package, a Reference (is reference similar to a tool?), and a template in Visual Studio?
References are used to pull additional libraries into your project. For example, your colleague develop a library which implement some functions that you wanted. You needn't write it by yourself, just add the dll into your project through add reference. Of course you can add any libraries not it come from third part or from Microsoft. But it won't notice you when the libraries changed or updated.
NuGet package is the package manager for the Microsoft development platform including .NET. It will help you manage your packages which installed on your project. When the package has new version released, it will notice you to update it. The NuGet client is a tool provide the ability to produce and consume packages.
Template is similar to a sample project which provides the frameworks based on different type of project. You just need to add your content/functions into this frameworks to implement your requirement. For example, if create a WinForms project, it will reference System.Windows.Forms automatically which contains all stuffs you needed in WinForms project.
Why do we need them?
NuGet package and Reference can help us invoke some functions which have been implemented by others or some have been encapsulated by Microsoft. And the Template can help us create a project without build framework by our self. All of them help us save a lot of time when developing a project.
What is done / changed in our project when we install each one of them?
Add references in your project, it will let you invoke the functions in these references in your project.
Install NuGet packages will add the package reference into your project automatically and then you can use the functions the package provided.
The template will be installed when you install Visual Studio. Most of common templates will be installed. Then you can create a new project through these templates quickly.
Are they dependent on each other in some way? Which one(s) of them are global installs, and which one(s) need to be installed in every project?
Reference and NuGet packages need to referenced/installed on a project. But this project can be create through the templates or can be create by customer self. So in some way, reference and NuGet package are dependent on project.
Templates is global installs and NuGet packages and reference need to be install in every project.
I have noticed many times that developers tend to reference assemblies directly by browsing to the .dll file under the .\packages folder (installed by another project) and adding that to project references instead of installing the nuget package on that project. In that case, even though it compiles, but the Nuget Package Manager does not know that the referenced assembly is from a package, and so updating the package solution-wide does not update those references in that project. If you are doing a Service Oriented architecture where each piece of feature in your application is a separate project in the solution, then you probably have hundred of projects, and managing those references would become a nightmare. Is there any way to prevent developers from referencing assemblies directly if they belong to a nuget package? For example is there any MSBuild task to verify all references to package assemblies require the package to be installed on the project?
If your team uses resharper, they have a plugin to help with this:
http://blog.jetbrains.com/dotnet/2012/11/20/add-packages-not-references-a-nuget-plugin-for-resharper/
I'm guessing the issue is caused by people using resharper without it, since by default VS won't know to include that DLL but Resharper will find it and reference it (and not update package config without the plugin)
Also get used having people using nuget at the solution level, not project level. That will force people to update all nuget packages across the solution, and not leave you with V 1.1.1.0 on Project A and v 1.1.2.0 on Project B.