I am using Visual Studio 2010 with Team Foundation Server 2010. I have created a root for a project which uses AutoMapper and EntityFramework which I installed for the solution using NuGet package manager.
When I branch from the root the resulting branch has a yellow warning triangle in the references section for the AutoMapper and EntityFramework. I have tried uninistalling the packages and then reinstalling but nothing allows me to include these references and build the solution. The only message I get is that the package aready exists.
All suggestions gratefully received.
I have solved the problem. The root solution was a created from existing projects from another source and there were some NuGet package references in the packages.config files in the project folders. The steps were:
Delete the packages folder (if it has been copied over) from the root of the solution
delete any NuGet references to the packages from the solution file (.sln)
delete any NuGet references from the packages.config files
Using Manage NuGet Packages for the solution to uninstall any packages
Reinstall from the solution level
And then all was fine.
Related
I am using Visual Studio 2015 Community. I have got a C# project with a bunch of NuGet packages. When I build the project the NuGet assemblies get copied into bin\Release but I don't want them in the root directory of my application, I want them to be put in a lib subdirectory.
The output path build setting doesn't do what I want, it changes the general output directory. I think that it's Visual Studio which copies the NuGet assemblies on build.
I like my projects organized and don't want a bunch of dependency DLLs in the root folder.
One suggestion is that you could think about using the init.ps1. When the NuGet package is installed for the first time or every time the solution is re-opened in Visual Studio, Init.ps1 will runs once for your solution.
Reference Ryan Vice's share us the detailed steps about how to let NuGet copy dlls to [solution root]\lib in this case:
How to copy Nuget content files relative to the solution root
I'm training 5 people on using Visual Studio. They've mapped their drives and have "downloaded" the solution from TFS which contains 10 projects. All located at the same depth in TFS folder structure. When the new folks download the solution there's one project that doesn't get the NUGET references even though the Package folder (created by NUGET) is at the same depth of the other 10 projects when viewed in TFS.
We know how to add these manually but is there a way to automatically have VS do it? Why would only one project lose it's reference with the Package Folder right there?
It seems you are still using MSBuild-Integrated package restore approach. If NuGet recognizes that the MSBuild-Integrated package restore approach is enabled for the solution, Automatic Package Restore is skipped.
You need to migrating MSBuild-Integrated solutions to use Automatic Package Restore, then the packages will be restored automatically.
In addition, you need to update you NuGet manager to the latest version in VS Tools--Extensions and Updates. And make sure Visual Studio is configured to 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in Visual Studio' in VS Tools--Options--NuGet Package Mnager--General.
To Fix:
Unload all projects first, then right click and select edit project.
Find this line:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Comment it out.
Reload all the projects and compile.
This applies to Nuget api version 2.
Note you may configure all projects for Nuget at the solution level.
The package manager for the solution presents a set of check boxes for every project along with the buttons (Install or Uninstall).
I'm working on a TFS project with a small team. This project has a bunch of nuget packages installed, but it's for a 4.0 project, and the nuget package manager GUI doesn't even offer the older versions of the packages any longer since their 4.5 equivalents are now being used. In order to allow other team members to compile the project, they need to have the exact versions of the packages. I'd like to check in the entire "packages" folder used by nuget. Is this a good idea? If so, how does one check in the "packages" folder and all its contents since it exists at the solution level? There is no "Include in Solution" option in Visual Studio as there is when you right-click an assembly.
in the past I have also checked in the NuGet packages into version control. With this some problems appeared:
Some packages where not checked into version control when committing from Visual Studio into TFS.
Updating packages became a real problem.
For the first problem I had used the TFS Power Tools. The problem with this solution is that every developer needed to install the Power Tools.
A better solution came up with NuGet 2.7. It introduced package restore. With package restore there's no need to check-in the packages folder. They will be restored during build.
We use an on-prem TFS install with no internet access so we have to check in our package folders or our builds fail. The biggest issue is that VS does not behave consistently when it comes to adding the pending changes for new package files, often times it will ignore the .dll files in the pending changes window, sometimes it adds everything fine.
I am trying to use NuGet Package Restore with VS2010 + Visual Sourcesafe. It is working partially for me.
Where this is coming from: NuGet not getting missing packages
My Solution2 has asp.net website[Project1 in above image] that has another nuget package installed. Now another developer opens the Solution2 via VS2010, the automatic restore works for Library projects in Solution1. It gets all missing packages for Library projects that is referenced in this Solution2 and I see them in Solution1/packages folder.
But for Website it says external dlls i.e. pacakages missing. The issue I think is because website doesn't have a .csproj file and so it doesn't know things needs to be restored.(http://nuget.codeplex.com/workitem/1663)
Making it work partially:
Added packages/repositories.config to website solution (What is a solution folder in visual studio)
Another developer goes to VSS and get that packages folder manually. Now when he builds the solution, the Package Manager Console prompts for restore i.e. has "Restore" button. On clicking it will bring the AjaxControlToolkit.
Questions:
- Is the above approach the only and best available for Websites?
When the developer clicks "Restore" button it brings packages for Library as well to Solution1/packages along with packages for nuget. Any reason why would it do that?
Any ideas on above issues?
Per you link, nuget doesn't support websites. If you really need to use Nuget, and let's face it, everyone does, then in my opinion the best approach is to switch your website over to a web application, at which point visual studio will create a csproj file for you, detailing the nuget packages that are contained in the project.
HTH
For adding Solution level "packages" folder with repositories.config to VS Solution Explorer, I created a Solution folder and added repositories.config.
That created packages folder in the SourceSafe when I checked-in the solution.
I also found someone pointing the same thing here.
Update: I think the newer nuget is restoring the packages. But one other trick for nuget to add the dll to the bin folder it to check-in the .refresh files for AjaxControlToolkit and its dependent packages.
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.