I have setup our internal class libraries to be built in VSTS and to create nuget package hosted in our VSTS upon each successful build.
Our application then references those class libraries by downloading the nuget package off of our own VSTS url.
If we want to make changes to our class library we modify the solution, increment the assembly number, rebuild it online and a new nuget package will replace the existing one. Then update our application with the latest package.
Now because the class library is referenced through nuget in the application, what would be the best strategy to test changes made to the class library at the application level?
Should I remove the nuget package, reference the library locally then test, then re-add nuget reference?
Should I just create a new package each time and come up with an internal policy with other developers when it comes to managing assembly version numbers to only use specific assembly versions?
I'd go with option 2 - generate a pre-release nuget package.
"A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version" (http://semver.org/spec/v2.0.0.html)
Related
I have a vendor provided DLL which is based on .NET Framework. I do not have access to code and I only have the DLL. I have packaged this DLL into a nuget package and now I am trying to refer this into a .NET standard project. But I am getting warning as - Package 'MyPackage 0.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project..
If I refer the DLL directly into a .NET standard project it doesn't show this warning. But using it after creating a nuget package shows that.
I also tried creating a .NET standard lib project, added DLL reference and then created a nuget package but still it was showing same warning.
Is there another way of doing it? Vendor doesn't provide DLLs targeting other frameworks and I have to use it after packaging it into Nuget because of requirements.
In my side, I test the situation as you described. Create a net standard lib project called test, then use this node to include into the package.
1) create a net standard lib nuget project called test and only add this node under test.csproj file:
<ItemGroup>
<None Include="xxx\xxx\xxx.dll"(the whole path of the net framework dll) Pack="true" PackagePath="lib\$(TargetFramework)"></None>
</ItemGroup>
2) right-click on the net standard test project-->click Pack button and you can get the new version of the nuget package.
Before you install the nuget package into another main project, you should first clean nuget caches or delete all files under C:\Users\xxx(current user)\.nuget\packages.
And I did not face the issue in my side with all the above steps.
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.
As the title says, I'd like to know if there is a way to automatically update an installed NuGet package as soon as a new version becomes available in the package source.
The use case is a package that applies certain company policies (code analysis, signing, ...) to our projects, and as soon as this package is updated, I'd like to be able to configure an automatic update for this package.
I do know that there is a package restore feature for NuGet which will automatically download the missing packages when the project is built, but does this download a specific version or the most recent package with a matching name?
Although coming late to the party, I would like to add, that updating NuGet packages may be possible with PackageReference.
See https://learn.microsoft.com/de-de/nuget/reference/package-versioning.
The NuGet package restore feature intentionally only works for one specific version. The same package with a different version number will not be used if the package with a lower version is missing.
Example 1
packages.config references 1.0.0.0
package source contains 1.0.0.0 and 1.0.0.1
1.0.0.0 is the version that will automatically be restored
Example 2
packages.config references 1.0.0.0
package source contains only 1.0.0.1
no automatic restore will be performed, the project won't build
This behaviour makes sense as otherwise there is no way to control what you are actually building. Imagine someone updates the package source with a newer version of a package just before you build a release that will get shipped...
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.
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.