I am wondering if anyone is aware of how to properly include an Nuget package in my application. Installing it - adds the references automatically in Solution Explorer. In addition it create/display a file called package.config - and it looks like it wants to be added in my project. It is shown in Solution Explorer but appears in my root folder with a little + sign next to it - and allows me to Check In Pending Changes / add it. Am I supposed to add it to my project?
I basically don't want to screw up anything.
Yes the packages.config file is required. This file holds the packages you reference and the versions youre using. NuGet uses this file to restore your packages in a TFS build of on the machine of another developer.
Here is some more information on NuGet dependency resolution
Note that you should not checkin the packages folder in your solution folder. NuGet will restore packages to this folder using the packages.config file
UPDATE: the <PackageReference> format was introduced a while back. It can be used with both the old and new .csproj formats. One of the benifits is that the paths to the packages are no longer in your project file so you will get a lot less updates/merge conflicts when updating NuGet packages. See this page for more information: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Yes, it's usually checked in as part of your solution. Source control and all that.
Related
I recently upgraded an old ASP.Net MVC3 project that was storing all our COTS (commercial off-the-shelf) .DLL files in source control to use NuGet Restore Packages instead.
Now whenever someone gets the source afresh from TFS (Team Foundation Server), the references I updated to NuGet Packages all have the warning icon on them. Neither building nor cleaning and rebuilding fix the references.
If I click any NuGet reference in a project, the references all appear to update. The warning icons disappear and the references seem to be fine. The project builds without sissue.
This has to be done for each project in the solution, though once done once it is fine and doesn't reoccur. But this is slowing down new employees and is cumbersome.
Does anyone know of something I might have missed?
The .ddl files are for packages like MVC, StructureMap, Log4Net ect
I have searched (via Google) and the only related question is one showing NuGet packages having a different icon.
You can use the Restore Nuget Packages option from the Solution Explorer by right clicking on the solution:
You can also configure Nuget Restore to run on build from the Nuget Manager Settings windows:
I'm trying to follow the no-commit strategy in keeping assemblies out of TFS while using NuGet. I'd like the projects to auto-restore dependencies and not add pending changes to TFS.
I've read a few ways to do this; one being using .tfignore, which will be a pain with the number of projects we have. We could cloak the folder in TFS, but we would need to add the packages folder for every project in order to cloak it. The last way, is to configure NuGet via NuGet.config using disableSourceControlIntegration which will keep the NugetClient from adding the packages to the project or solution.
**This is the configuration XML I'm using:
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
If I place it in my {SolutionDir}.nuget folder it works for that solution. I'm trying to place it in my %AppData%\nuget folder so that it is applied to all solutions but package restore is still causing TFS to add my packages folder contents.
I'm using Visual Studio 2013, NuGet 2.8.6 and TFS from VSOnline.**
I dont think there is a way to put this key in the root location, looks like Nuget only honors the key when it is specified in the {SolutionDir}.nuget folder. The Nuget document clearly mentions that this key works at solution level and need to added to the {SolutionDir}.nuget folder.
Source Control Integration
"disableSourceControlIntegration" under section "solution" allows you to disable source control integration for the "Packages" folder. This key works at the solution level and hence need to be added in a NuGet.config file in the "$(SolutionDir).nuget directory". The default value for this key is true.
EDIT & UPDATE : thanks to #TonyStewart871 for finding this information. I haven't tested this in Version 3.2 nor could find the official documentation.
But as per this GITHUB LINK Comments Section, from NuGet version 3.2 it is possible to add the key "disableSourceControlIntegration" at the user level for all solution's in the %appdata%\nuget\nuget.config file instead of adding at the individual solution level. Please find below the comment from deepakaravindr:
"You can add the setting not just to the solution level nuget.config, but also to your nuget.config at %appdata%\nuget. That works too! Just that it will get applied to every solution that you open on that machine. Remember to add the following section as a child to < configuration > section. And, note that the setting should always be under the < solution > section for it to work"
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
NUGET Documentation
There is a DisableSourceControlIntegration-TFS NuGet package that will add the {SolutionDir}.nuget folder and config files to the solution, as well as a .tfignore file for the NuGet packages folder. It's even easier than adding a single config file by hand. You can find it here: https://www.nuget.org/packages/DisableSourceControlIntegration-TFS.
It is correct this strategy of allow exclusion of NuGet Packages folder relatively to a single TFS project, because has sense to exclude nuget packages only if you needs to have access on a common project repository from several developers.
And so, if anyone needs to replicate solution's structure on his local machine restoring first time only NuGet packages (and so its content (libraries)), can do it without having any problems related to compatibility libraries and so on..
Every time NuGet restore libraries in Packages folder and solution compiles well.
While, if you only should configure NuGet behaviuor, others developer should have so too and therefore it should miss the convenience about this configuration policy: anyone should replicate this configuration rule everytime on his local machine..
Instead, storing this rule in tfs with its solution allows to everyone to inherits this rule.
Alternatevely, if one wants to work on a project alone, he can avoid if he wants to configure NuGet for don't commit its "Packages" folder content, and so the strategy of store this particular NuGet rule in TFS it is a good choice.
I am hoping for a little advice.
I am checking in my project (asp.net mvc 5) to source control (TFS) and when a fellow colleague tries to pull it down, most of the references are not being added to his project.
How can I insure that all the references to get added?
Generally, best practice is to use NuGet.
At least for packages that are not internal you must use NuGet. Let's say for EF, BundleTransformer & so on.
For that you must enable NuGet package restore and fetch all you need from NuGet Feed. More here: http://docs.nuget.org/consume/package-restore/msbuild-integrated
For internal dll's you can create an internal NuGet feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds and get packages from there or copy them in your project.
Don't forget to include the files into project if you copy them "by hand" and i think this is a good start.
There are other best practices like not referencing anything from GAC anymore and move all the dll's/dependencies/referencing to NuGet or to create a raw "Library/Vendor" folder in your project and copy all the necessary DLLs there (problem here is that you check in all the dll's to source control), but you will be sure that everyone will get exact the same version/reference & so on because the files are stored there (physically).
What are the references to?
There are a few different things to bear in mind:
References to other projects within the solution should just work, if they don't make sure that the referred to projects are building
References to things like nunit are best managed through nuget so you add them using it and then when your colleague checks out he only has to restore the nuget packages and it all works
References to things that aren't in nuget, you can either put them into nuget or I prefer to create a lib folder and put them into there. To get them actually checked in as dll's are normally excluded, add the folder and dll's and then use the source control explorer to find the folder, right click and choose "Add items to folder" and use that to add the dll's and files that you need. If you then reference the dll's in the lib folder they will be checked out and should resolve correctly for the other user.
For example if I create new ASP MVC 5 project with Identity authentication and Internet template.
Is it possible to somehow extract installed nuget packages from it so I can install them in another project so I don't have to check one by one?
Why I need this.
I want to create empty project and I want to add dll references same like in internet template.
The assemblies are in the packages folder at solution root and the packages.config lists the installed NuGet packages.
But I'd rather use NuGet and let the tool try to determine the necessary dependencies. It may also automatically add necessary settings to your web.config.
I installed PostSharp on my project, but everybody has error when get solution, I asked my problem of postsharp technical support he said you must add packages to source control.
Now I am not sure adding packages to source control or no? if I make a mistake again, all of users get error on his project,
I read the number of solutions and test one of them, so I caught error and I can not test they are right, please help me
You have a few options here.
Use NuGet to manage your dependencies. This is by far the easiest option -- you can configure your solution to have NuGet package restore enabled, so when anyone builds your project, if the required dependencies aren't present, they'll be automatically downloaded.
Source control your dependencies in a folder somewhere in your project's structure (like \lib), and then reference those dependencies out of that folder. Ensure that the contents of that folder are in source control.