With VS 2022 and multi-repo support I was excited to start splitting out some projects into their own solutions. But I ran into an issue with the associated test projects.
I picked one of the smaller projects and the test project and made a new folder in my workspace for it.
I then opened the project and added the test project.
Immediately I got an error, "This project references NuGet packages(s) that are missing on this computer. Use the NuGet Package Restore to download them ... The missing file is ..\packages\MSTest.TestAdapter.2.1.2\build\net45\MSTest.TestAdapter.props.".
I didn't think much of this initially and ran the package restore and the error persisted.
I should also mention that the main project doesn't have this issue; the one I opened initially. One the project that I added to the new solution seems to have this issue.
When I run the package restore again, it says that all packages are already installed and there is nothing to restore.
In playing around, I unloaded the test project and looked at the project file. I noticed that it's referring to one folder up called "Packages":
<Import Project="..\packages\MSTest.TestAdapter.2.1.2\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.2.1.2\build\net45\MSTest.TestAdapter.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
I then took the opportunity to convert to nuget package reference but selecting it in the right click menu. The above lines did not change in the project file. Using references, it was my understanding that it was using my local "profile\ .nuget" folder.
To test that it was looking at this folder, I created the "..\Packages" folder manually and copied in the missing nuget packages.
The error went away and I was able to compile it.
However, this doesn't fix the problem. If I were to check this solution out again, this folder would be missing.
I'm assuming that the project file is what is causing my problem. Does anyone know how I can get a project to force looking at my profile.nuget using package reference?
After much work I finally found a blog that talked about the differences between packages.config and packagereference. It appears the migration didn't complete properly and didn't clean up the packages.config configuration.
I backed up the .csproj file in question
I then unloaded the project and edited the .csproj file
Anywhere that the packages were reference, I removed the entries.
Then I reloaded the .csproj file and it compiled.
When I looked at the references folder in the solution explorer I saw that the icons changed for the packages that were not found prior.
Not sure why this happened, but this is what fixed it.
I tried to build a project from downloaded source code using VS2017 community edition. Got following error
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\..\packages\Xamarin.Forms.3.2.0.637442-pre1\build\netstandard2.0\Xamarin.Forms.props.
not sure whats the issue. I tried
Delete packages folder and restore packages.
Delete obj and bin folder. Tried to clean rebuild.
First, restart Visual Studio, cleaning and building the solution most times is not enough.
Try unloading the project in Visual Studio and edit the csproj file.
Search for that props file reference in the file. Sometimes it gets duplicatedthe current version and one outdated version as well. Remove the old one and reload the project.
Check in your Forms, Android/iOS if the csproj is referencing the same Xamarin.Forms version,and are no strange lines/characters.
<PackageReference Include="Xamarin.Forms" Version="x.x.x.xxxxx" />
In the last resort, try to downgrade the XamarinForms version and check if it helps.
I recently successfully switched all of our projects over to automatic NuGet restore. To do this I followed this guide. Everything worked great, I was able to delete my /packages folder and restore to my heart's content.
One of the steps in that guide says to edit your .csproj file and remove the EnsureNuGetPackageBuildImports related element.
The problem I am having now is that, after going in and downgrading one of my projects libraries, NuGet seems to have automatically added the EnsureNuGetPackageBuildImports related element back into my .csproj file.
Is there some other setting I should be changing to prevent NuGet from doing this? I would rather not have to edit my .csproj file every time I make a NuGet related change.
Is there some other setting I should be changing to prevent NuGet from doing this?
I`m afraid the answer is not if you going in and downgrading one of your projects libraries.
The target "EnsureNuGetPackageBuildImports" is used to ensures that the imported .props or .targets files are indeed imported in the old way "Enable Package Restore". NuGet has supported NuGet MSBuild support since NuGet 2.5.
Since Nuget 2.7+, Microsoft has dropped support for the 'Enable NuGet Package Restore' in VS2015 and you need to do some manual changes to either migrate old solutions or add the feature to new solutions. Nuget Automatic Package Restore has changed in Nuget 2.7+. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 and before who will now need to upgrade to 2.7+. In this case, NuGet will automatically added the EnsureNuGetPackageBuildImports related element back into your .csproj file when you going in and downgrading one of your projects libraries.
To resolve this, we advice that do not mix 'old' and new methods for automatic package restoration(Remove that files when you use automatic package restoration).
Besides, if going in and downgrading one of your projects libraries is unavoidable, there is a PS script can help you remove it more convenient:
DisableNuGetPackageRestore.ps1
I've got problem with version of dependency that I set manually.
Note: I use Automatic restore within Visual Studio.
When I set Version="1.3.12.5" for my dependency in packages.config I expect that restore will install package and it will be referenced in next build I trigger. But it is not true. Package is installed and placed in packages directory but build does not use this downloaded packages (as csproj is not changed automatically).
Do you know possible scenarios to workaround this problem?
I tried to use Proget Client Tools but it turned out that it is not possible to use local directory feed with this. I need local and remote feeds support also, so it is additional requirement.
So, paraphrasing my question is...
How to easily change referenced version of package without touching csproj? (which is hard to edit in visual studio) Editing version twice (one in packages.config, two in csproj) is also an overkill.
Remember Package Restore simply downloads the package to the packages folder. It does not update project references as NuGet expects that the package had previously been installed. It's simply downloading the missing package files.
Package Restore is not a replacement for Install-Package. You can specify a specific version when installing. This will add the project references properly.
With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.