NuGet Restore Fails when a dependency adds .targets import to .csproj

Question

I recently ran into a NuGet recovery problem. I added a project dependency (in this case PostSharp), and then enabled recovery. I checked in the source, but not in the / packages directory (as I don't need ... right!). When TeamCity or another developer grabs the source and runs MsBuild, they get the following error:

C:\TeamCity\buildAgent\work\e374975c0264c72e\ProjectName\ProjectName.csproj(70, 3): error MSB4019: The imported project "C:\TeamCity\buildAgent\work\e374975c0264c72e\packages\PostSharp.2.1.5.1\tools\PostSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. 

The problem is that NuGet has not yet started recovering / downloading PostSharp or the .targets file. This seems like a NuGet bug for me, but I wanted to know if others have this problem.

Does anyone have this problem or you know its solution. Yes, I could register the / packages directory, but why use NuGet at all?

Answer 1

Another approach is to modify the <Import> element in question to make it conditional, for example:

 <Import Project="$(CodeAssassinTargets)" Condition="Exists($(CodeAssassinTargets))" /> 

It depends on the new property defined in the previous <PropertyGroup> . Usually I add one of them to the top of the csproj file with other "global" flags, for example:

 <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <CodeAssassinTargets>$(SolutionDir)packages\CodeAssassin.ConfigTransform.1.1\tools\CodeAssassin.ConfigTransform.targets</CodeAssassinTargets> <AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings> <UseMsdeployExe>true</UseMsdeployExe> </PropertyGroup> 

Then, for the appropriate purpose, such as BeforeBuild, you will receive a useful error message:

 <Target Name="BeforeBuild"> <Error Text="CodeAssassin.ConfigTransforms target is missing. It needs to exist at $(CodeAssassinTargets) in order to build this project!" Condition="!Exists($(CodeAssassinTargets))" /> </Target> 

With these changes, the project will be loaded even if the restoration of the nuget package has never been completed. If automatic package recovery is enabled, the first build attempt should clear the missing target problem, but if it is not, one manual package recovery will be.

Answer 2

@ porterhouse91, did you check your csproj file to make sure it is configured for the appropriate build purpose?
I have not tried the new built-in packet recovery feature yet, but I assume that it works, at least as the previous workflows on the firewalls. If this case, including the restoration of the package in your solution, affects only the projects in your solution at the time of its inclusion. If you added a new project (with NuGet dependencies) to the solution, since you enabled package recovery, you will need to enable it again. Another possibility: previous workflows related to having a .nuget folder that you needed to check in VCS, so you might need to check this if it hasn't been checked yet (if the built-in package recovery function really uses this approach).

By the way, if this answer is generally useful, thanks Steven Richie - he asked me to do this for you.

Answer 3

I had a problem too, but I was able to modify the .targets file in the source package to get around it. Basically, RestorePackages is the build goal that runs when a project is created. Unfortunately, the package will not load properly before the import is satisfied. The only way to find out is to include the .targets file as content, and then change the BuildDependsOn property so that it restores packages before it performs your own tasks.

 <PropertyGroup> <BuildDependsOn Condition="$(BuildDependsOn.Contains('RestorePackages'))"> RestorePackages; CustomTarget; $(BuildDependsOn); </BuildDependsOn> <BuildDependsOn Condition="!$(BuildDependsOn.Contains('RestorePackages'))"> CustomTarget; $(BuildDependsOn); </BuildDependsOn> </PropertyGroup> 

To be clear, this does not help with pre-built packages, but if you can build the package yourself, you can fix it.

Answer 4

I ran into the same issue with Visual Studio 2012 and NuGet packages that were not tested in the original control.

Error:

 The imported project "\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. 

I found msdn writeup in a situation that gave the following workarounds for capturing a project from a source control without NuGet packages.

• Stop using the recovery package and register all package files
• Explicit package recovery before creating a project
• Register .targets files

I decided to go with option # 2, however NuGet currently (v2.6) does not include a way to install all the packages from the packages.config file from visual studio. Some searches have shown that you need to use the NuGet command line to execute the following command before opening Visual Studio ( link ).

 c:\path\to\nuget.exe install -o packages project-folder\packages.config