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

Question

I ran into an issue recently with NuGet restore. I added a project dependency (in this case PostSharp) and then enabled restore. I checked in the source, but not the /packages directory (as I shouldn't needed to....right!). When TeamCity or another developer grabs the source and runs MsBuild, they receive 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, NuGet hasn't run yet to restore/download PostSharp or it's .targets file. This feels like a NuGet bug to me, but wanted to see if others have this same issue.

Anybody have this issue or know the resolution. Yes, I could check-in the /packages directory, but then why use NuGet at all?

Answer 1

Another approach is to modify the <Import> element in question, to make it conditional, e.g.:

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

This depends on a new property defined in an earlier <PropertyGroup>. I usually add one at the top of csproj file with other "global" flags, e.g.:

<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 in an appropriate target, like BeforeBuild, give a helpful 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 modifications, the project will load even if the nuget package restore has never been done. If auto package restore is enabled, the first build attempt should clear up the missing target issue, but if it does not, one manual package restore will.

Answer 2

@porterhouse91, have you checked your csproj file to make sure it has been set up with the appropriate build target?
I haven't yet tried the new built-in Package Restore feature, but I'm assuming it works at least somewhat like the previous workflows out there on the interwebs. If that's the case, enabling Package Restore in your solution only affects the projects in your solution at the time you enable it. If you've added a new project (having NuGet dependencies) to the solution since enabling Package Restore, you're gonna need to enable it again. Another possibility: the previous workflows involved having a .nuget folder that you needed to check in to VCS, so you might need to check that in if it hasn't been checked in yet (if the built-in Package Restore feature does indeed use this approach).

BTW, if this answer is at all helpful, thank Stephen Ritchie -- he asked me to give it a shot for you.

Answer 3

I had a problem like this as well, but I was able to modify the .targets file in the source package to work around it. Basically, RestorePackages is a build target that runs when the project is built. Unfortunately, the package won't even load properly before the imports are satisfied. The only way I know to fix this is to include the .targets file as content and then change the BuildDependsOn property so it restores the packages before it runs your custom tasks.

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

To be clear, this doesn't help with pre-built packages, but if you can build the package again yourself, you can fix it.