I have a solution with 6 R&D projects in it. Recently we upgraded to Visual Studio 2013 and after upgrading the solution I added a 7th project (ASP.net MVC) which added a packages folder to my solution folder.
I recently added my solution and projects to our production share which is shared across 3 other developers. We have a libraries subfolder that our production solution references. Discussing my newly added solution and project folders to our production environment with our build developer, he would like to see the packages folder moved as a subfolder of the Libraries subfolder and all the team reference the single packages folder at that location. We do not use Team Foundation.
Since I did not tell nugget where to create the packages (they were just placed in the solution folder) is there a way to tell it where to look for the packages after I move the folder to its new location? How will the other developers configure their Visual Studio instance to look at the shared folder instead of their local machine? Assuming, once they build the solution locally it will also add a local packages folder and we don't want that.
Seems like this is pretty straight forward. In fact, NuGet site says you can share packages folder but it says you have to modify nuget.config and I don't have that in my solution. Any thoughts/suggestions are appreciated.
Nuget, in and of itself, is a package management repository. It's entire purpose is to allow you to centrally pull down packages (libraries, configurations, whatever) that you need to a place locally on your system (whether it's dev, production, whatever) without having to actually commit those libraries to your source control. Instead, any developer will just be committing a file that says the equivalent of, "Get me a package by this ID (name) and version."
This process creates a file called packages.config at the top level of every project within your solution. The file would look something like this:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.1.1" targetFramework="net45" />
<package id="jQuery" version="2.1.1" targetFramework="net45" />
</packages>
The files themselves are placed in the projects where they need to be (in the case of projects like jQuery) or, library binaries are stored at the top-level of your solution in a folder called packages and should not be checked into source control.
You can also enable "auto-restore" packages for Nuget so that when anybody checks out your project, they will automatically get the libraries and things they need in order for your project to run/build correctly.
This means that everybody gets what they need, you do not need to manage your own "library repository" (please...no shared folders!), and, at any point, you can look at the packages.conf folder to see what your project depends on.
Here are some more links on how to enable and work with Nuget for development and build systems. There are scores of other resources on the web as well.
Introduction to Nuget
Using NuGet Without Committing Packages
Package Restore
Related
Trying to tidy up my file structure, I moved packages.config to a subfolder. Only to discover it was not being picked up by Nuget any more.
Is it possible to move the file or is it hard-coded into VS that it must be in the same directory as the project file?
Googling doesn't give me an obvious answer, I just get general information on packages.config's purpose.
Does packages.config have to be in the project folder?
You cannot move that packages.config file into any other sub folder except the project's root folder.
Also, I agree with thatguy.
Packages.config nuget management format allows packages.config file be in the root directory of the project and nuget and msbuild will be able to recognize this file and manage the nuget packages in your project. That's its mechanism.
So my suggestion is that you should move it back to the project's root directory. And so far, this is the only way to ensure that you successfully manage packages using packages.config.
Besides, if you still want your request to come true, I suggest you could suggest a feature request on our User Voice Forum(click suggest a feature). And The Team will consider your request carefully and I hope they will give you a satisfactory reply.
If used, packages.config is typically located in a project root. It's automatically created when the first NuGet operation is run, but can also be created manually before running any commands such as nuget restore.
This is from the packages.config reference. Although it states that the configuration file is typically located in the project root, there is no indication on any requirements for moving it. Therefore, it might be a limitation of the Visual Studio Nuget package manager that expects the packages.config file in the project root. I have never seen any official documentation or a working example of moving this file without breaking the package manager.
Here's my setup. I have a classic .Net website, not web app. I have all my compiled objects in a self-hosted nuget repo. When I build in VS, it looks at my packages and copies the binaries to the bin folder but when I try and build in Azure DevOps it's not working. My Nugets restore just fine but I haven't hit on the right msbuild arguments to make it work. I know that .Net websites are not common these days. I found this (How to use NuGet packages with an ASP.NET Website on CI Server) which was a path I was considering (putting .refresh.dll files in source control) but it seems like there should be an easier way.
How do I get my nuget packages copied to bin during a build for a asp.net website (not web app)?
What you are considering (putting .refresh.dll files in source control) is the most appropriate way.
From here:
They are simple because if you view them in a text editor, you’ll see
they contain nothing more than the full path to the dll.
Turns out, these dll.refresh files are an exception to the rule, and
they should go into source control. Its the only way your web project
will know where its references live.
For building and package restore to work, you can keep the bin folder and any .refresh files. You can remove the other binaries from your version control system.
Hope this helps.
I am attempting to migrate to nuget's new Automatic Package Restore. Whilst it works fine on my own machine (packages are restored), builds performed as a TFS Build on the build server do not build, complaining that they cannot find the various dlls (that should have been downloaded as part of the restore).
I have created a nuget.config in my solution folder, as specified here:
http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
I have also tried putting this nuget.config file next to the nuget.exe file in TFS, in the hope that it would be used, but to no avail.
The nuget reference here:
http://docs.nuget.org/docs/reference/nuget-config-file
states that the nuget.config in my solution folder should be picked up. But it appears that it isn't.
I'm at the end of my tether. According to nuget, the Package Restore feature is designed specifically so that packages don't need to be checked in. However, there's scant information about how to get TFS to actually restore the packages, and what I've found does not work.
Any help would be gratefully received.
My nuget.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<add key="ads" value="<address to local repository>" />
</packageSources>
</configuration>
As it so often turns out, the answer is the answer to a question I didn't actually ask:
"How does TFS even know how to call nuget?"
After sitting and thinking about this for a while (and as #Matt Ward correctly points out) it occurred to me that the TFS Build has no way of knowing nuget is even involved, since the new "Automatic" package restore removes the need for it to be part of the build itself.
This question has actually been asked here:
How does TFS know about nuget?
Although the accepted answer is NOT actually the correct one. Scroll down to probackpacker's answer, which is essentially that:
"If you are using automatic package restore, you must have a build process that calls it before building your solution"
This is actually well documented at nuget:
http://docs.nuget.org/docs/reference/package-restore-with-team-build
However, I had disregarded it since a) the entire point of Automatic Package Restore is to move away from an MSBuild based process (although I do now understand why this is different), and b) it seemed more complicated than I needed. It's not. That said, a clarifying statement such as "If you are using Automatic Package Restore with TFS Team Build, you MUST create a an MSBuild project in order to call Package Restore" would have been helpful. It's obvious once you understand what's happening - confusing when you don't. But we live and learn.
depending on the version of visual studio, it should just be a matter of right clicking on the solution and selecting Enable NuGet Package restore. this will create a Nuget folder that contains, NuGet.exe, a NuGet.Targets file and NuGet.config.
you can update the targets file with a local NuGet Feed if you have one.
to test locally, delete the contents of your packages folder, and ReBuild the solution, this will download the files from NuGet and your solution should build correctly. check in the NuGet folder and files to source control, your packages should not be added to source control.
your TFS build should now be able to restore the packages
Now if this is how you are set up and it still doesn't work on TFS, log onto the build server with the build account and load the solution locally, make sure the package restore works as the build account on the build machine, you may have a firewall / proxy issue, where the build server / build account can't access the Nuget.org internet site
I've got a packages.config file checked into source control. This specifies the exact version of the Nuget dependency I want. We have our own NuGet repository. We are creating these NuGet packages ourselves.
<packages>
<package id="Dome" version="1.0.0.19" targetFramework="net45" />
<package id="Dome.Dojo" version="1.0.0.19" targetFramework="net45" />
</packages>
These packages have some JavaScript files which when you add the Nuget package as a reference in Visual Studio are copied to the Scripts folder in the project.
I don't want to check these JS files in to source control, I just want to check in the packages.config file.
When my project builds in Team City (or when I build in Visual Studio after a fresh checkout) it doesn't copy the JS files from the NuGet package. There's a question here explaining a similar problem:
NuGet package files not being copied to project content during build
But, the solution in the answer to that question doesn't work for me; that solution uses ReInstall, which is problematic because it can automatically upgrade the version in the packages.config file (say if a dependency is specified as a >=).
The whole point of this is that I want to be able to checkout a revision from my source control, and build that version with the right dependencies AND I want to use the nice packaging features of NuGet. So, I don't want any "automatically update to the latest version during the build."
There's an issue against NuGet (http://nuget.codeplex.com/workitem/2094) about NuGet files not restoring content files. And it's Marked as Closed By Design.
Thinking about how this works a little more, it appears to me (but I'm not 100% sure) that for assemblies NuGet has a different behaviour - it doesn't copy them into the project, instead it references them from the location in the packages folder. It strikes me that js files in the NuGet package should be referenced analogous to how dlls are referenced.
Is there a way to construct a NuGet package so that it references the JS as links in the project (in a similar way to how you can add an existing File as a Link in VS)? And would this solve my problem?
If not then I'll take the advice given by Jeff Handley when closing ticked Nuget Issue 2094 mentioned above:
The option you'd have is to create a new console executable that
references NuGet.Core, and you could build a supplemental package
restore for your own use that copies package contents into the
project.
Writing my own command line tool to copy the contents does seem like I'm pushing water uphill here - am I doing something fundamentally wrong?
The underlying problem here is Visual Studio's relatively poor support of JavaScript projects and JavaScript's lack of built-in module loader.
For C#, when you install a package it adds a reference in your .csproj file to the assembly on disk. When you build, MSBuild knows to copy the thing referenced to the bin directory. Since you aren't checking in your bin directory, this all works great.
Unfortunately for JavaScript, the build system isn't nearly as matured and there aren't well defined guidelines for NuGet to follow. Ideally (IMO), Visual Studio would not run web sites directly from your source directory. Instead, when you built it would copy the JavaScript files, CSS and HTML files to a bin directory from which they would be executed. When debugging, it would map those back to the original JavaScript or TypeScript files (so if you make a change it isn't to a transient file). If that were to happen then there is now a well-defined build step and presumably a well-defined tag for JavaScript files (rather than just "content"). This means that NuGet would be able to leverage that well-defined MSBuild tag and package authors could leverage the NuGet feature to do the right thing.
Unfortunately, none of the above is true. JavaScript files are run in-place, If you did copy them to bin on build Visual Studio would do the wrong thing and editing from a debugger would edit the transient files (not the originals). NuGet therefore has no well-defined place to put files so it leaves the decision up to the package author. Package authors know that the average user is just going to be running directly from source (no build-step) so they dump files into the source folder where they must be checked in to version control.
The entire system is very archaic if you are coming from a modern ecosystem like C# where someone took time to think these things through a bit.
What you could do is create an MSBuild task that, before build, would go through all of your packages, look for content, and copy that content to the desired location. This wouldn't be terribly difficult, though would take a bit of work.
Also, package authors could include a build-task that does this in their package so that before-build all of their content was copied local. Unfortunately, if only some package authors do this then you end up with weird fragmentation where some packages need to be committed to version control and others do not.
When a package is installed into a project, NuGet in fact performs these operations,
Download the package file from source;
Install the package into the so called packages folder, which is $(SolutionDir)\packages by default;
Install the package into the project, which consists of adding references to DLLs, copying content files into the project directory etc.
When a package is restored, only the first two steps are executed. Projects will not be touched by nuget package restore. Which is why the js files in your project will not be "restored".
The only solution for now is to check in the js files in your project.
If you are the owner of the package then you could use the nuget package i've created to be able to have a folder called "Linked" in the package and have a simple Install.ps1 and Uninstall.ps1 (one liners) to add every file in the nuget package's linked folder as existing to the project.
https://github.com/baseclass/Contrib.Nuget#baseclasscontribnugetlinked
I didn't try out how publication treats linked files, the problem is debugging the Project, as the JavaScript files will be missing in the directories.
If you are using git as source control you could try my nuget package which ignores all the nuget content files and automatically restores them before building.
Step by step example in my blog: http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0
I have a Visual Studio project which I have committed to VisualSVN (via the VisualSVN => Commit menu in Visual Studio). I have added a number of libraries to this project via NuGet.
My colleague has downloaded the project I have uploaded to SVN (via VisualSVN => Get solution from Subversion...) and has found that these libraries are missing, and he is having to re-download them.
A few questions:
Is this by design? Or have I not committed my Solution properly? Or has my colleague not download the solution to his machine properly?
If this is by design, what is the correct way to re-add references to a solution downloaded from an SVN server? I am worried that I may have added a reference and worked with it, and that it may have been updated since so whenever my colleague re-adds the same reference via NuGet he will get a more up to date version that will be different, and this will break my program. Is this a valid concern?
Yes, this is by design. The whole concept of using Nuget is that you will not have to keep libraries in your version control system.
You need to Right Click on your solution in Visual Studio and select Enable NuGet Package Restore.
This will configure the solution to restore the NuGet packages (if any missing, or in case of none) whenever you'll do a build. Also, all the libraries that you've added for a particular project will have an entry in the packages.config created in the project's source drectory; for eg:
<packages>
<package id="jQuery" version="1.8.3" />
</packages>
This way NuGet makes sure everybody gets the same version.
Just enable "Nuget package restore" in your solution and packages will be automatically downloaded during the build:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages