1

Closed

Unable to restore packages with .targets files

description

Unable to restore packages with .targets files.

Steps to reproduce:
1) Create Portable Class Library Project.
2) nuget-install Microsoft.Bcl.Async (for example)
3) Enable NuGet package restore
4) Close solution and cleanup packages folder
5) Try to rebuild project. Build fails with message like:

[project].csproj : error :
The imported project "[path]\packages\Microsoft.Bcl.Build.1.0.0-rc\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.
Closed Mar 12, 2013 at 1:04 PM by dotnetjunky
This is a known behavior. When the package adds an Import element to your project, package restore won't be able to restore the imported .targets file before the project is built. \n\nThe good news is that we're working on a new implementation of package restore which will solve this very problem.

comments

racielrod wrote Apr 19, 2013 at 2:45 PM

Any ETA on this new Package Restore Implementation? It would be a huge help for people using PCLs.

MarcoPiazzi wrote Apr 23, 2013 at 2:45 PM

Any news for this BIG issue?

dotnetjunky wrote Apr 23, 2013 at 4:40 PM

Not yet. Please be patient. We're still in development.

richard_szalay wrote May 6, 2013 at 6:59 AM

[dotnetjunky] Not yet. Please be patient. We're still in development\n\nI assume this feature didn't make it into 2.5? I'm still see the error

dotnetjunky wrote May 6, 2013 at 5:26 PM

No, it's not in 2.5

MuiBienCarlota wrote May 31, 2013 at 9:40 AM

I have same issue \"Microsoft.Bcl.Build.targets\u201D was not found prevent my from loading project using async on a machine without \"packages\" folder. \n\nI use VS 2012.2 and nuget 2.5 on Win7/Win8 machines with .Net 4.5 installed but my project need to target .Net 4.0 for XP support.\n\nThis issue have yet be encountered by others.\nI have this case each time I VCS checkout my project on a new folder (different folder on same machine or new machine). I have checked nuget package restore during build but I cannot start build of unloaded project.\n\nMy only temporary solution was to add packages folder to VCS.

maroy wrote May 31, 2013 at 6:17 PM

I have same issue \"Microsoft.Bcl.Build.targets\u201D was not found prevent my from loading project using async on a machine without \"packages\" folder. \n\nI also encountered this error today... Kind of frustrating... I tried to update all the nugets on my projects and It add Microsoft.Bcl.Build that is causing that error on our build server...\n\nHope it'll be fix soon... That's kind of a show stopper for us...\n\nThanks..

nikolawannabe wrote Jun 1, 2013 at 2:23 AM

This broke all packages depending on Microsoft.Net.Http, since the new version pushed yesterday to that package uses a target file. Anyone using this who intends to rely on package restore (such as in a build system...) will need to use the older version of Microsoft.Net.Http: 2.0.20710.0.

benhu wrote Jun 3, 2013 at 8:02 AM

Ok, here's a temporary solution that I used to get Jenkins to build my project with the new BCL build tools.\n\n1. Go to [solution dir]\packages\Microsoft.Bcl.Build.1.0.6\tools, copy the file Microsoft.Bcl.Build.targets and paste it somewhere else (let's say [solution dir]\buildtools\Microsoft.Bcl.Build.targets)\n\n2. Unload your projects, open up the project file and locate this line (in my case it's very close to the bottom):\n\n <Import Project=\"..\..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets\" />\n\n3. Replace that line with\n\n <Import Project=\"$(SolutionDir)\biuldtools\Microsoft.Bcl.Build.targets\" />\n\n4. Make sure build targets file is added to your source control (e.g. git add -m blah)\n\n5. Now commit, push, and your build server should be happy enough to build the solution just for now.\n

benhu wrote Jun 3, 2013 at 8:23 AM

Hmm, a better solution that does not require copying files would be modifying that line with a condition:\n\n<Import Project=\"..\..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets\" Condition=\"Exists('..\..\packages\Microsoft.Bcl.Build.1.0.6\tools\Microsoft.Bcl.Build.targets')\" />\n\nIt'll work too.

vihangshahit wrote Jun 3, 2013 at 3:01 PM

Hi benhu.\n\nYour solution works very well.. Thnx man for saving my time.. :)

benhu wrote Jun 5, 2013 at 2:33 AM

Ok, I have tinkered for a few hours now and have figured that the best temporary option for now is to actually force Nuget to update the packages from command line. I have written a small C# program to do just that. Run from the solution folder, it should locate all the project folders that contains packages.config file and uses the nuget bootstrapper exe to install the packages.\n\nProject can be found at https://bitbucket.org/hhu_ies/nugetpackagerestorer\n\nDisclaimer: this code is not fully tested and use at your own risk...\n\nI hope this can helpful.

IDisposable wrote Jun 6, 2013 at 7:49 PM

Thanks, BenHu, that's perfect!

IDisposable wrote Jun 7, 2013 at 8:53 PM

In case anyone is wondering, the Microsoft.Bcl.Build release 1.0.7 from today will change your project file and strip BenHu's fix. It also removed the \"prerelaseversion\" from the assembly metadata and fixes the .target file's assembly search order. It DOES NOT fix the package restore issue (loading the solution without the package folder being present).

IDisposable wrote Jun 7, 2013 at 9:07 PM

Updated the related Connect bug and the Community posting with BenHu's work-around with 1.0.7 version.

Jaans wrote Jun 9, 2013 at 11:19 PM

FYI - The workaround does not help with failing builds via the TFS Build Service.

baskint wrote Jun 11, 2013 at 4:16 PM

Thanks for the workaround, this worked for us.

tathamoddie wrote Jun 18, 2013 at 11:51 AM

This is a pretty disappointing oversight, that's causing a lot of unnecessary pain with build servers.

dotnetjunky wrote Jun 18, 2013 at 2:48 PM

As I have said, this was not an oversight. We were aware of this issue, and we are working on a new implementation of package restore that will solve this issue. Thank you for your patience.

Dnx wrote Jun 20, 2013 at 10:20 AM

Yes, i have the same issue, hope you will find a fix soon...

jamierytlewski wrote Jun 21, 2013 at 6:46 PM

What I did to fix this issue was loaded up the Package Manager Console (you could also use the regular command line) and fired up this following nuget command.\n\nnuget install .\GlobalInit_MVC\packages.config -OutputDirect packages\n\nThis worked great for us.

chrisdrobison wrote Jun 27, 2013 at 4:02 PM

So with 2.6, has this issue been addressed?

blakeja wrote Jun 29, 2013 at 4:18 PM

This is still an issue with 2.6

JeffHandley wrote Jul 1, 2013 at 9:47 PM

Yes, this is still an issue. NuGet doesn't do anything automatically for ensuring targets files referenced by packages via PowerShell are retained on disk.\n\nIf the package utilizes the new MSBuild imports feature through the \build folder, NuGet imports the targets file in a way that allows the package restore build to succeed, but then a 2nd build is needed for a completely successful build.\n\nWe are still working on some package restore improvements for NuGet 2.7 where we hope many workflows will be improved, with this scenario as one of them.

JasonQue wrote Jul 9, 2013 at 3:11 AM

Really wish this wasn't closed. I understand that it's a known issue, etc., but I'd like to get updates to this ticket so I know when I can remove the workaround.

tathamoddie wrote Jul 9, 2013 at 8:11 AM

This is not a known issue in my opinion. It is a fundamental flaw introduced by a feature being released that did not meet what should have been done criteria. You don't break the ability for projects to build and call it a \"known issue\".

dotnetjunky wrote Jul 9, 2013 at 9:15 AM

@JasonQue: Please subscribe to our blog at http://blog.nuget.org where we'll announce future releases. For every new release, we include release notes which will tell you when the new package restore is added.

dotnetjunky wrote Jul 9, 2013 at 9:16 AM

@tathemoddie: We acknowledge it is an issue that we know about. But we're not going to fix it the way it is now. Instead, we'll introduce a new way to do package restore.

stijnherreman wrote Sep 3, 2013 at 11:22 AM

@dotnetjunky
We are still working on some package restore improvements for NuGet 2.7 where we hope many workflows will be improved, with this scenario as one of them.
I'm using 2.7 and this is still a problem.
The imported project "C:\Foo\Bar\packages\Microsoft.Bcl.Build.1.0.5\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.

stijnherreman wrote Sep 5, 2013 at 9:23 AM

Updating the packages (after manually restoring them) fixed it.

Kritner wrote Oct 22, 2013 at 8:40 PM

Still no resolution for this issue? Not really clear on getting this to work on TFServices builds

oscar_agreda wrote Jan 20 at 3:09 PM

the best and simplest way to fix is as follow

1-install or re-install the package http://www.nuget.org/packages/Microsoft.Bcl.Build/
2-then edit the project file (extension .csproj) and look for the reference to "Microsoft.Bcl.Build" in that file.
3-change the version number (folder) to match the one you have on your nuget packages folder
viola