Prior to NuGet, it was common accepted 'best practice' to check-in all external DLLs used on a project. Typically in a Libs or 3rdParty directory.
When working with NuGet, am I supposed to check-in the packages directory, or is there a way for MSBuild to auto download the needed packages from the nuget feed?
No
Since this question was asked there is now an easy workflow to use NuGet without commiting packages to source control
From your package manager console you need to install the 'NuGetPowerTools':
Install-Package NuGetPowerTools
Then to enable your projects to support pack restore you need to run another command:
Enable-PackageRestore
Now you are ready to commit your code base without the packages folder. The previous command changed your project files so that if packages are missing they get automatically downloaded and added.
Source
Using NuGet without committing packages to source control
Yes. Consider the "packages" directory to be equivalent to your "libs" directory that you mentioned in your question. This is the approach I personally take with my OSS projects.
We are investigating features that would allow MSBuild to auto download the needed packages, but that hasn't been implemented (as of NuGet 1.1).
I think some people may have already implemented such features on their own, but our plan is to look at having that feature built in to NuGet 1.2 or 1.3 hopefully.
Despite all the answers here, it is still a plain ole' horrible solution to not have all your dependencies under "some kind" of version control.
For GIT, this would mean GIT-LFS.
The recent episode with NPM shows why: If the internet repository of which you depend breaks, are unavailable etc., well then you're screwed aint you?
You are no longer able to build your stuff - and therefore not able to deliver.
Since asking the question, I've put in the following approach so that I do not have to check in the toplovel Packages directory.
In a toplevel build.msbuild file:
<Target Name="NuGet">
<ItemGroup>
<NuGetPackage Include="*\packages.config" />
</ItemGroup>
<Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages' />
<!-- optional for project that has JavaScript content -->
<CreateItem Include="Packages\*\Content\Scripts\*">
<Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
</CreateItem>
<Copy SourceFiles="#(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
<Delete Files="MainProj\Scripts\.gitignore" />
<WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
<Delete Files="#(PostNuGetFiles)" />
</Target>
In each project.csproj file
<Target Name="BeforeBuild">
<Error Condition="!Exists('..\Packages\')" Text="You must run > msbuild build.msbuild to download required NuGet
Packages" />
<!-- optional for project that has JavaScript content -->
<ReadLinesFromFile File="Scripts\.gitignore">
<Output TaskParameter="Lines" ItemName="ReqJSFiles" />
</ReadLinesFromFile>
<Message Text="#(ReqJSFiles)" />
<Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run > msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
</Target>
I realize the reality was different when this question has been originally posted and answered, but fortunately the answer changed a bit. It is now possible to use NuGet to download dependencies via MSBuild using a Pre-Build event. You don't need to put the packages folder in your code repository, all dependencies will be downloaded and/or updated on build. It may a workaround, but it looks decent enough. See the following blog post for details: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
AS of 09/20/13, there is something called "Nuget Restore". You actually don't have to check in package folder if you wish to do so. (Especially if you are using DVCS)
Check out this: Using NuGet Without commiting packages to source control
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
This post has become very outdated. The answer is still NO, but the solution has changed.
As of NuGet 2.7+ you can enable automatic package restore without including the NuGet.exe file in your source (this is undesirable to say the least) and if you use any modern DVCS you can ignore the packages folder. If you need any special customizations you can create a nuget.config file in the solution root.
http://docs.nuget.org/docs/reference/package-restore
Also, with the new csproj format you can avoid the extra nuget.config files as well since that is integrated now. Please check out this post which explains that better:
Should .nuget folder be added to version control?
Related
I've just added the nuget package Grpc.Core.Api into one of my projects.
The build platform target for this project is marked as x86, however the build process is placing both grpc_csharp_ext.x64.dll and grpc_csharp_ext.x86.dll into my output directory.
At ~10.2MB, this feels unnecessary. Is there any way to prevent the x64 variant from being included (other than manually adding a delete command in the Post-build event).
I can see these two .dll files: grpc_csharp_ext.x64.dll and grpc_csharp_ext.x86.dll after installing Grpc.Core NuGet package, and if I only installing Grpc.Core.Api NuGet package, they won’t be generated.
By checking the detailed MSBuild output log, this two files are copied by default task Copy. The logic(or control) of judging whether to copy or skip copying should be stored in .targets file of Grpc.Core NuGet package folder.
I then find the Grpc.Core.targets file under …\MyProject\packages\Grpc.Core.xxxxx\build\net45. If you find and open it, you will see the related settings:
<ItemGroup Condition="'$(Grpc_SkipNativeLibsCopy)' != 'true'">
<Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win-x86\native\grpc_csharp_ext.x86.dll">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Link>grpc_csharp_ext.x86.dll</Link>
<Visible>false</Visible>
<NuGetPackageId>Grpc.Core</NuGetPackageId>
</Content>
<Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win-x64\native\grpc_csharp_ext.x64.dll">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<Link>grpc_csharp_ext.x64.dll</Link>
<Visible>false</Visible>
<NuGetPackageId>Grpc.Core</NuGetPackageId>
</Content>
...
The <condition="'$(Grpc_SkipNativeLibsCopy)'!='ture'"> and <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> make grpc_csharp_ext.x64.dll be copied to the project output directory.
I don't think this can be overridden or be changed or be prevented by using MSBuild in .csproj files. As you mentioned, manually adding a delete command in the Post-build event should work, but it works after the file has been copied.
What I think/suggest
I may provide a silly or risky workaround. I don't recommend modifying the Grpc.Core.targets file, but if you change to <CopyToOutputDirectory>Never</CopyToOutputDirectory> for grpc_csharp_ext.x64.dll, this file will not be generated again if you only build for x86.
This maybe needs to be changed by author of this NuGet package, unless these actions(copy ..x64 files to output directory when building under x86) are necessary or for some reasons that we don't notice.
Again, I would agree on considering using Post-build event is better.
Is there a way to auto-increment the NuGet package version when using "Generate NuGetPackage on Build" in C#/.NET Standard 2.1?
If you build and publish the project by a build server, and manage the version by Git, you can try the MSBuild GitVersion task. For a similar issue, see here.
But if you just want a clean build and publish in local Visual Studio without using Git, then I'm afraid for now there isn't any Visual Studio option or MSBuild task to support this behavior. You can go to the Developer Community to suggest the feature because it's a meaningful idea, but currently it's not available.
Also, as from hints from Martin and Alexandre, you can add this script into xx.csproj:
<PropertyGroup>
<GenerateNuspecDependsOn>$(GenerateNuspecDependsOn);SetPackageVersion</GenerateNuspecDependsOn>
</PropertyGroup>
<Target Name="SetPackageVersion" DependsOnTargets="Build">
<PropertyGroup>
<!-- <PackageVersion>$([System.DateTime]::Now.ToString("yyyy.MM.dd.HHmmss"))</PackageVersion> -->
<!-- You can customize the format and the rule about how version increases here. -->
<PackageVersion>$([System.DateTime]::Now.ToString("1.MM.dd"))</PackageVersion>
</PropertyGroup>
</Target>
Then when you publish the package today, its version is 1.10.4. Tomorrow for 1.10.5, it works if you don't really need to publish different versions of one package in a day. Also you can customize the script to define your version-increasing rule.
If targeting multiple frameworks, see Build project with multiple targetframeworks in TFS as a NuGet package
This works when setting the assembly version to wildcard.
<Deterministic>false</Deterministic>
<AssemblyVersion>3.0.*</AssemblyVersion>
As of toDate with Visual Studio 2019 and .NET 5.0, what LoLance suggested about scripting the increment inside the .csproj file still works, and we now can use shell commands directly inside the package definition's PropertyGroup for multiple fields, as shown in the picture below:
We have solution with a lot of projects and a more or less complex dependency graph between those projects. Now each of those projects should become its own nuget package and the dependency graph of the nuget packages should mirror the on of the projects.
I have two questions:
Is it possible to achieve this while keeping all projects within the same solution? If so how?
Is advisable to keep all projects in the same solution? What would be the a common / "best practice" approach to this?
The situation in our project is the same and we took the following approach:
The first step is to create the nuspec files defining your packages. We have placed all theses files in a folder named ".nuspec" which is located in the solution's root directory. The nuspec files are added to the solution in a solution folder that is named ".nuspec", too.
The solution itself has a global AssemblyInfo file that contains the versioning information as well as some copyright stuff - in short all information that is common between our projects. Each project then has its own assembly info adding the information specific to each project.
The nuspec files do not contain a version. Instead we use $(version) as a placeholder there:
<?xml version="1.0" encoding="utf-16"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
<id>MyCompany.MyProduct.Server.DataAccess</id>
<version>$(Version)</version>
<authors>MyCompany</authors>
<projectUrl>http://example.com/myProduct.html</projectUrl>
<iconUrl>http://example.com/myProduct.icon.png</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Some description goes here.</description>
<summary>The summary goes here</summary>
<copyright>Copyright © MyCompany 2015</copyright>
<language>en-US</language>
<dependencies>
<dependency id="MyCompany.MyProduct.Common" version="$(Version)" />
<dependency id="MyCompany.MyProduct.Server" version="$(Version)" />
</dependencies>
</metadata>
<files>
<file src="path\to\MyCompany.MyProduct.Server.DataAccess.dll" target="lib\net45\MyCompany.MyProduct.Server.DataAccess.dll" />
</files>
</package>
(Of course the dependencies might have dependencies themselves. The server component might reference a logging component for example.)
Initially we created a console application reading the version of the solution from the global AssemblyInfo file and parsing it into all of the nuspec files before creating and publishing the packages.
The console application worked well, but was a bit tedious to maintain in a TFS environment with continuous integration enabled. So we defined a custom TFS build template doing this work. All we need to do now to create a set of nuget packages for all of our projects is to trigger a TFS build.
This approach has the advantage that all packages have the same version and thus work well together.
This approach has the disadvantage that all packages have the same version and cannot be released independently.
We chose that approach because it prevented us from producing a conglomerate of badly integrated components. Our projects provide a small framework that is used to develop small LOB-applications that all are quite similar. Due to the fact that we deliver the framework in a set of different packages the developers can choose which of the packages they actually need and then install only those. Should a developer decide to add a missing functionality lateron he just installs the relevant packages that have the same version as those already installed. Thus there's no need to worry about compatibility.
Currently, in VS 2017 you can have several library projects in a solution which are built into separate packages and also reference each other by <ProjectReference>. Surprisingly, VS is smart enough to use <ProjectReference> when building solution AND to produce correct package <dependencies> for referenced projects in nuspec. In other words, you can conveniently work with many projects simultaneously in one solution and have them all published as a set of packages depending on each other.
Yes, you can "probably" make this work. I say probably because I haven't tried it, but I would approach it with something like this: https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild/ with a manual nuspec defining your references would work. If you wanted to get really fancy, you could write some post-build Roslyn code to parse your project dependencies and build up the nuget dependency tree. That said, don't do this, in a non-trivial solution, its almost guaranteed to become manual and brittle pretty fast.
Ultimately, it's much preferable to just break your solution up -- create a solution per Nuget package, and pull in your dependencies using Nuget itself. Assuming you have a build/CI server, this should be fairly trivial. Just run your own Nuget repo and publish the build artifacts as they get built -- that way your dependent projects will pull the latest package you JUST built. You'll want to ensure your build process refreshes Nuget each time and you can use the standard nuget spec command as a post-build step. As a nice bonus, it'll force everyone working on the code to really think thru the dependencies when making changes.
I ran into an issue recently with NuGet restore. I added a project dependency (in this case PostSharp) and then enabled restore. I checked in the source, but not the /packages directory (as I shouldn't needed to....right!). When TeamCity or another developer grabs the source and runs MsBuild, they receive the following error:
C:\TeamCity\buildAgent\work\e374975c0264c72e\ProjectName\ProjectName.csproj(70, 3): error MSB4019: The imported project "C:\TeamCity\buildAgent\work\e374975c0264c72e\packages\PostSharp.2.1.5.1\tools\PostSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
The problem is, NuGet hasn't run yet to restore/download PostSharp or it's .targets file. This feels like a NuGet bug to me, but wanted to see if others have this same issue.
Anybody have this issue or know the resolution. Yes, I could check-in the /packages directory, but then why use NuGet at all?
Another approach is to modify the <Import> element in question, to make it conditional, e.g.:
<Import Project="$(CodeAssassinTargets)" Condition="Exists($(CodeAssassinTargets))" />
This depends on a new property defined in an earlier <PropertyGroup>. I usually add one at the top of csproj file with other "global" flags, e.g.:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CodeAssassinTargets>$(SolutionDir)packages\CodeAssassin.ConfigTransform.1.1\tools\CodeAssassin.ConfigTransform.targets</CodeAssassinTargets>
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
<UseMsdeployExe>true</UseMsdeployExe>
</PropertyGroup>
Then in an appropriate target, like BeforeBuild, give a helpful error message:
<Target Name="BeforeBuild">
<Error Text="CodeAssassin.ConfigTransforms target is missing. It needs to exist at $(CodeAssassinTargets) in order to build this project!" Condition="!Exists($(CodeAssassinTargets))" />
</Target>
With these modifications, the project will load even if the nuget package restore has never been done. If auto package restore is enabled, the first build attempt should clear up the missing target issue, but if it does not, one manual package restore will.
#porterhouse91, have you checked your csproj file to make sure it has been set up with the appropriate build target?
I haven't yet tried the new built-in Package Restore feature, but I'm assuming it works at least somewhat like the previous workflows out there on the interwebs. If that's the case, enabling Package Restore in your solution only affects the projects in your solution at the time you enable it. If you've added a new project (having NuGet dependencies) to the solution since enabling Package Restore, you're gonna need to enable it again.
Another possibility: the previous workflows involved having a .nuget folder that you needed to check in to VCS, so you might need to check that in if it hasn't been checked in yet (if the built-in Package Restore feature does indeed use this approach).
BTW, if this answer is at all helpful, thank Stephen Ritchie -- he asked me to give it a shot for you.
I had a problem like this as well, but I was able to modify the .targets file in the source package to work around it. Basically, RestorePackages is a build target that runs when the project is built. Unfortunately, the package won't even load properly before the imports are satisfied. The only way I know to fix this is to include the .targets file as content and then change the BuildDependsOn property so it restores the packages before it runs your custom tasks.
<PropertyGroup>
<BuildDependsOn Condition="$(BuildDependsOn.Contains('RestorePackages'))">
RestorePackages;
CustomTarget;
$(BuildDependsOn);
</BuildDependsOn>
<BuildDependsOn Condition="!$(BuildDependsOn.Contains('RestorePackages'))">
CustomTarget;
$(BuildDependsOn);
</BuildDependsOn>
</PropertyGroup>
To be clear, this doesn't help with pre-built packages, but if you can build the package again yourself, you can fix it.
I ran into this same issue with Visual Studio 2012 and NuGet packages not checked into source control.
The error:
The imported project "\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I found a msdn writeup on the situation that gave the following workarounds for grabbing a project from source control without the NuGet packages.
Stop using package restore and check-in all package files
Explicitly run package restore before building the project
Check-in the .targets files
I decided to go with option #2, however, NuGet currently (v2.6) does not include a way to install all packges from the packages.config file from within visual studio. Some searching revealed that you need to use the NuGet Command Line to execute the following command before opening Visual Studio (reference).
c:\path\to\nuget.exe install -o packages project-folder\packages.config
Let's say I have a project with this structure:
MyLibrary\
MyLibrary.sln
MyLibrary.Core\
MyLibrary.Core.csproj
MyLibrary.Extensions\
MyLibrary.Extensions.csproj
MyLibrary.Tests\
MyLibrary.Tests.csproj
I want to create a single NuGet package which packages MyLibrary.Core.dll and MyLibrary.Extensions.dll. I can't seem to figure out how to get NuGet to do this. I've tried building a spec file manually and I've tried building one using "nuget spec MyLibrary.Core.csproj". I've tried adding all of the DLLs to a lib/ folder which I understand to be the convention-based mechanism for adding DLLs to the package. In every case I can get the MyLibary.Core.dll to get into the package but the MyLibrary.Extensions.dll does not end up packaged along with it.
TLDR: What is the best practice for creating a NuGet package with multiple projects / assemblies? Is there a tutorial out there that focuses on this? The tutorials I've found all focus on simple single-project demos.
You'll run NuGet on a single project (or nuspec file), but it supports pointers to other projects via the file element. This element uses the names of your project's References, so you avoid having to a) find the location of other project files, and b) copy files to a particular place as a post-build step.
Supposing you have a nuspec file for MyLibrary.Core.csproj, and it references MyLibrary.Extensions and MyLibrary.Tests such that they end up in the bin directory after a build:
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
...
</metadata>
<files>
<file src="bin\Release\MyLibrary.Extensions.dll" target="lib\net40" />
<file src="bin\Release\MyLibrary.Tests.dll" target="lib\net40" />
</files>
</package>
With this setup, all of your references should end up in the appropriate place in the NuGet package. You still have the hard-coded 'Release' in there, but I'd wager most probably don't distribute NuGet packages of their debug builds anyway.
Did you generate a blank nuspec file with:
nuget spec
If you use that file and then put your dlls in a folder under it named lib, it will package them up.
I had a little trouble with trying to generate a nuspec file from a project or dll. Also, if you manually reference any files in the nuspec file, the conventions are not used. This is probably the problem with nuspecs generated from dlls or projects.
Also, if you are trying to run this from a build script that executes in a different folder, you can tell nuget the location of your .\lib folder via the -BasePath command line:
build\nuget.exe pack nuget\Company.Project.nuspec -BasePath nuget\
Have you tried NuGet Package Explorer? Might be the easiest way:
http://nuget.codeplex.com/releases/view/59864
It seems your problem is the same as this question: Why doesn't nuget include the referenced project when packing?. If so, you can use the -includereferencedprojects option (See http://docs.nuget.org/docs/reference/command-line-reference#Pack_Command).
I recently published a solution for this...
My solution enables automatic creation of NuGet packages when you build the solution where each package can contain multiple assemblies, references to both external NuGets and NuGets created during the same build and even include the source code for debugging.
In your case, all you will need to do is add a new class library project to your solution, reference the projects you want to package, then add a post build event.
You can find an article with a walk-through guide here
and the source code here.
i have some tutorial how i did it with windows and visual studio:
create local folder and call it packages like: c:/packages//lib - important to create another folder in folder call it lib and past there dll.
open nuget package explorer - https://npe.codeplex.com/downloads/get/clickOnce/NuGetPackageExplorer.application
the ui very intuitive just add dll and export it to /lib (for tutorial https://blog.zwezdin.com/2014/building-nuget-packages-with-gui-tool/ it in russian but see on pictures the flow it's about 3 clicks)
it will create nuspec file
open GIT BASH - https://git-for-windows.github.io/ and navigate to: cd c: => cd packages (the path of )
*maybe on windows you will need provide developer options for windows's linux stuff (https://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/)
in GIT BASH enter command: nuget add -source [options]
where: : the full name of nuspec (include .nuspec)
and: the path of folder lib in folder (c:/packages//lib)
after the action ended successfully
in GIT BASH enter another command:
nuget pack .nuspec
not in this folder you have .nupkg file.
How to install a Nuget Package .nupkg file locally? - tutorial how to add it to visual studio.
I had the same problem and I decided to create Nuget which will allow to create other nugets from chosen project.
Package is deployed on the Nuget.org site. After referencing it in the project You need to add nuspeck file to the projects which should generate the projects.
Project with the required nuspeck file
Last thing which should be done by you is invoke command Create-Nuspec in Package Manager. Than the powershell module will take all libraries which are result of the build it will add also the required dependencies and create the nuget in the output directory.
Description about this package is placed here.
I had an issue when adding extra dlls references to a Nuget packages, and testing the package on a sample project, the extra dlls was not being added apparently, no matter the way that I create the Nuget Package.
Then I released that when you uninstall and install again a local Nuget Package with the same version number the changes no take effect, the extra dlls are not added.
So each time you uninstall the package, close visual studio and clear the Nuget Cache,
How to clear NuGet package cache using command line?
Then open again Visual Studio and reinstall the local package to make the change takes effect.
Or make the package version to increase each time to be for Visual Studio to recognize your changes.
For example:
Package-1.0.0
Package-1.0.1
Package-1.0.2
.....
To create a Nuget package from a sample project there are some ways, for example:
Right click to your Visual Studio project and choose the "Pack" option
Then install the nuget package explorer:
https://www.microsoft.com/es-ec/p/nuget-package-explorer/9wzdncrdmdm3?activetab=pivot:overviewtab
And add manually your extra references (dlls files) to your specific targets.
Create a nuget package using a .nuspec file how specified in the documentation:
https://learn.microsoft.com/en-us/nuget/guides/create-packages-for-xamarin
<files>
<file src="Plugin.LoggingLibrary\bin\Release\Plugin.LoggingLibrary.dll" target="lib\netstandard1.4\Plugin.LoggingLibrary.dll" />
<file src="Plugin.LoggingLibrary\bin\Release\Plugin.LoggingLibrary.xml" target="lib\netstandard1.4\Plugin.LoggingLibrary.xml" />
<file src="Plugin.LoggingLibrary.iOS\bin\Release\iOsDependence.dll" target="lib\Xamarin.iOS10\iOsDependence.dll" />
<file src="Plugin.LoggingLibrary.Android\bin\Release\AndroidDependence.dll" target="lib\MonoAndroid10\AndroidDependence.dll" />
</files>
In your files part add your .dll files.
And dont forget, each time you uninstall and install again the nuget package from your local source.
Or you increase the version of the package each time:
Or close Visual Studio, clean the nuget cache and Rebuild your project.
In order to take effect the changes.