_From @MelbourneDeveloper on August 16, 2016 1:8_
There are many project types created by Visual Studio that add a "EnsureNuGetPackageBuildImports" target element to csproj files. In this case the element is defined in a Xamarin Forms project. It was newly minted in the last week or so from a standard VS template. The target looks something like this in the csproj file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>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 {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Xamarin.Forms.2.3.0.107\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Xamarin.Forms.2.3.0.107\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets'))" />
</Target>
The element is usually benign until you move the project to a different location on the hard drive, or another developer tries to compile the code. When this happens, you get:
_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.2.0.0.6482\build\portable-win+net45+wp80+win81+wpa81+MonoAndroid10+MonoTouch10+Xamarin.iOS10\Xamarin.Forms.targets._
This error message is very misleading and untrue. I've wasted countless hours in many projects trying to get Visual Studio to refresh the packages, but the error just keeps coming up even though there are no other compilation problems in the project. I don't know if the element is useful or not, but the various teams that create the templates need to either remove this element from the templates, or correct the element so that it doesn't cause errors. I can't even count how days I sat there scratching my head over this error until I finally found the error text in the csproj file. Yesterday, my colleague experienced it when she opened up an ASP MVC app. The whole point of NuGet is supposed to be that if the other person doesn't have the libraries, the libraries are silently downloaded and compilation ensues.
Other people can recreate this problem, and there are people reporting this problem all over the place. Here is my original MSDN thread on the topic:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/300b0549-58c9-4c50-bd64-7c82516495a9/nuget-error?forum=visualstudiogeneral&prof=required
_Copied from original issue: NuGet/NuGetGallery#3195_
Has anyone looked in to this?
I just got the issue today. I created a sample SignalR project. I then moved it to another folder and immediately the compilation error comes up. So, I went in and deleted the text from the csproj and the problem was fixed.
This is such a major headache for so many people. Do you have any idea how many new programmers follow a "how to" guide, finish the process of creating a working project, and then move the folder and suddenly it won't compile anymore?
This bug is super easy to reproduce.
Sorry, this is a general limitation of "packages.config".
Our new model, providing Transitive Restore (Project.json or PackageRef in VS "15", solves this.)
Workaround: In Package Manage Console, type: "Update-package -reinstall"
We will improve the error message.
https://github.com/NuGet/NuGet.Client/search?utf8=%E2%9C%93&q=EnsureNuGetPackageBuildImports
@rrelyea thanks for looking at this, but I don't think you've grasped the magnitude of the problem. This problem may not rest solely with your team.
I'm not mentioning this problem simply because the problem exists - I am mentioning it because it affects nearly every recently created project template in Visual Studio. It happens with Xamarin and ASP .NET Core projects for a start. Many people will be getting this issue across the board, and will be completely stumped as to why this is happening.
The error message isn't really the issue. I was able to work around the problem by deleting the "EnsureNuGetPackageBuildImports" element from the csproj file.
The issue is that even when the new model is created, you will need to go back and update the Visual Studio project templates so that when people create new projects, they are not left with the old structure that has this issue.
Agreed! this is a major headache and took me a long time to figure out why my projects weren't building when the references in my .csproj were correct.
I have the same issue over and over , no matter what project I tried to open.
it was working just fine last week , so I thought it may be my project . then I started downloading other project or templates and I got the same issue.
is this a bug that once you find it you can get rid of it?
How did you fix it ? it is driving me crazy
I'm having this too. It's wasted 3 hours this morning for me. And a total of 3 days across the past couple of months.
+1
I installed NuGet version 4.5.1 and this issue is still occurring. Error Condition lines are not removed from .csproj under EnsureNuGetPackageBuildImports for previous .props package references. Currently, the only solution I've found is to manually remove these lines. Is there any way to to have NuGet.exe removing the old package reference lines from the .csproj file while updating packages?
Any progress on this? Removing the EnsureNuGetPackageBuildImports workaround didn't work because then they were missing at runtime, also the Update-package -reinstall workaround didn't help at all.
Try go to the projects solution and delete all bin and object folder for ios android and forms / quit visual studio and open and compile again.
On Apr 9, 2018, at 2:36 PM, Katie Ellison notifications@github.com wrote:
Any progress on this? Removing the EnsureNuGetPackageBuildImports workaround didn't work because then they were missing at runtime, also the Update-package -reinstall workaround didn't help at all.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
@rrelyea your workaround does not work unfortunately. We have a solution B with a project that is from another project area A. The packages folders are not at the same level in each project area so having a path to ../../packages is fine when building in the project area A but in B, it appears that this is used relative to the solution and not the project so it fails. This path, if anything, should be only relative to the project, in which case it would work fine.
If I run Update-Package -reinstall to attempt to install it into the solution B packages folder, it ends up adding a hard reference to the second package folder e.g. ../../SolutionB/packages, which means it won't work in Solution A any more and also it doesn't remove the original paths so it still fails in B.
I am unclear whether I can migrate the project to PackageReference since it is .Net Web App and there are mixed messages about it working (the migrate feature on packages.config is not allowed in Visual Studio)
The only option is to manually remove the EnsureNuGetPackageBuildImports section which is a rubbish workaround and which we need to remember to do any time it is recreated.
Fixed in newer core projects
Not sure this is still relevant.
Most helpful comment
@rrelyea thanks for looking at this, but I don't think you've grasped the magnitude of the problem. This problem may not rest solely with your team.
I'm not mentioning this problem simply because the problem exists - I am mentioning it because it affects nearly every recently created project template in Visual Studio. It happens with Xamarin and ASP .NET Core projects for a start. Many people will be getting this issue across the board, and will be completely stumped as to why this is happening.
The error message isn't really the issue. I was able to work around the problem by deleting the "EnsureNuGetPackageBuildImports" element from the csproj file.
The issue is that even when the new model is created, you will need to go back and update the Visual Studio project templates so that when people create new projects, they are not left with the old structure that has this issue.