7

I've asked a question about build errors and continued investigating the issue further by my desperate self.

I have a guesstimation that the issue is about the packages that are fetched but not placed correctly. Looking through the painfully boring logs gave me this.

2016-01-15T21:50:40.8680146Z
The target "BeforeGenerateProjectPriFile" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets (186,61)" does not exist in the project, and will be ignored.

Shortly thereafter, I can see the first sign of something going sideways.

2016-01-15T21:50:43.9631666Z ##[warning]
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
2016-01-15T21:50:43.9631666Z 2>
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [C:\a\1\s\MyStuff\MyStuff.csproj]

And then it continues a lot about considering stuff that aren't existing.

2016-01-15T21:50:43.9661661Z
Considered "..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\lib\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll", but it didn't exist.
2016-01-15T21:50:43.9671655Z
For SearchPath "{TargetFrameworkDirectory}". 2016-01-15T21:50:43.9681655Z
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.winmd", but it didn't exist.
...

I'm not familiar with CI on TFS nor VS Online so it tells me very little about where to strike on the problem. I've googled myself half to death and tested a gazillion of different settings all over the portal. No luck. I can cause other errors (when I know that I'm typing in wrong stuff etc.) but one way or the other, I revolve to this one.

Any hints would be appreciated.

Community
  • 1
  • 1
Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438
  • It does sound like missing NuGet packages. The last part you have, where it's trying to find the assembly - that location is coming from the `HintPath` (which is considered first) that NuGet adds to the .csproj. I would think that either your package file isn't setup correctly (does that version, `1.0.0`, match what's in packages.config?) or NuGet restore isn't being called. Since it's VSO, I'm assuming this is VS2015/TFS2013+? TFS2013+ build templates will automatically restore NuGet packages before MSBuild is called. – makhdumi Jan 15 '16 at 23:57
  • 1
    The first part seems harmless. See https://github.com/NuGet/Home/issues/1814. Also, if you're using VS2015, you should migrate away from the nuget.targets file (you need to remove the import from all your .csproj files, and totally delete that .nugets folder). VS2015/TFS2015 will behave differently if the .nuget folder exists. – makhdumi Jan 16 '16 at 00:03
  • @Al-Muhandis It's VS2015, good guess. The file packages.config isn't edited by me at all. It got there as I installed e.g. EF. So the versions should be correct. I get it to compile locally, too. Should I remove all thepackages and re-build to verify that it loads correct packages? – Konrad Viltersten Jan 16 '16 at 00:49
  • I also verified in the following way. First I create a brand new console application - upload and build. Green light! Bravo! Then, I add EF, WebGrease and Atl3r (just a package or two) using the manager on the project. Upload and build. Guess what... Poof! Doesn't work anymore. So it **is** definitely the packages. Problem is, though, I have no idea how to trouble-shoot it... There's no .nuget folder checked in... – Konrad Viltersten Jan 16 '16 at 00:52
  • Can you verify that after the warning "MSB3245: Could not resolve this reference. Could not locate the assembly “xxx”. Check to make sure the assembly exists on disk.", there's something like this in the logs: *PrepareForBuild: Creating directory "obj\Debug\"* followed by *RestorePackages: "C:\a\...\.nuget\nuget.exe" install "C:\a\...\packages.config" -source -RequireConsent -o "C:\a\...\packages"*? –  Jan 16 '16 at 18:28
  • @AndyJ I can confirm that it's seem to be like this in my case. Apparently I was mistaken on the packages being restored. Suggestion on what to do with it? I can get a project to build **unless** using packages. Kind of limiting circumstance... – Konrad Viltersten Jan 16 '16 at 19:28

1 Answers1

6

Starting with version VS2015, there's no need for NuGet folder, contrary to the guides that I've seen. In fact, the only file that's needed is the config with the packages. There's the common but very deceitful work-around to check in the packages and their executables but that can create a lot of issues down the road. I wouldn't recommend that because it's hiding the problem, not resolving it.

First, verify that your build actually restores the packages. I noticed that in the error logs, it looks like if it does but that's a pitfall. It's an attempt to restore, not the actually success. If you encounter a warning like this (and the same goes for nUnit, WebGrease, NewtonSoft or any other package under NuGet's control):

Warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework". Check to make sure the assembly exists on disk.

start by verifying that the logs contain the following passages:

PrepareForBuild:
Creating directory "obj\Debug\".
...
RestorePackages:
"C:\a\src\src.nuget\nuget.exe" install "C:\a\src\src\xxxx.Entities\packages.config"
-source -RequireConsent -o "C:\a\src\src\packages"
...
Successfully installed "EntityFramework 6.3.1". ResolveAssemblyReferences:
Primary reference "EntityFramework".

Keep in mind that when you look through the log files, search for partial strings, since the directories, versions, packages' names etc. can vary slightly. If you can't find it, there's a good chance that the packages aren't restored on the build server. Compiling locally proves that there's a difference between environments, most likely the file packages.config isn't available. It's a tricky error because the failed logs won't tell you that it's missing. In fact, I haven't it mentioned at all in my logs.

  1. First, I created a brand new project Auto and checked it in. The build succeeded.
  2. Then, I added Entity Framework and the build failed with the same warning as yours.
  3. Finally, I checked in the packages.config file. The build succeeded.

enter image description here

The problem occurs because the initial check-in selects a number of files to ignore. Mostly it's the bin, obj etc. but also the packages.config. It needs to be specifically selected as not-ignored. If someone checks in all the files (not very wise, in my view), he also gets the file needed and so it appears like if they're doing it right. Please note that you should add the file to the version control first. That way, it's being checked in at each change. Otherwise, the issues will start to reappear if you add a new package locally or if you update an existing one.

If you get the warning but the packages are restored (the logs have the lines listed), try to update the package locally or reinstall it. Finally, you could refresh the installation from the package manager console by running Update-Package -Reinstall.

  • Similar issue with an older version of Package Manager here.
  • Incorrect advice on the files that need to be checked in (since VS 2015) here.
  • Outdated description of the file layout (valid for VS 2013 and earlier) here.
  • More info on how NuGet files structure is built up here.
  • Very good blog on the issue (strange that it doesn't come up at top in Google) here.
Community
  • 1
  • 1
  • 1
    I can confirm the correctness of your reply, so I'll accept it as an answer. However, while able to follow your steps in the console application (made it build, broke the build, restored the build), I noticed that the same isn't valid for MVC projects! I get the same error even though I have the packages.config uploaded! See for yourself. Default, vanilla ASP.NET MVC... – Konrad Viltersten Jan 17 '16 at 01:22
  • 1
    I had tried everything but `Update-Package -Reinstall` and that command tweaked a bunch of configs and downloaded some additional files. Most notably it updated the hintPaths for my packages but it also re-added the `EnsureNuGetPackageBuildImports` target which I removed manually. After checking in those changes the Kudu deployment worked and was really fast – Bron Davies Sep 08 '16 at 22:02