Handle custom MSBuild location

[jaredpar]

The dotnet/roslyn repo, and other dotnet repos in general, can have MSBuild installed into a custom location. This happens as a part of bootstrapping / xcopy scenarios or simply as a part of taking a bug fix in a SxS installation of MSBuild in Dev15.

It doesn't seem that GitLink has a way of being asked to use these copies of MSBuild. Instead it seems to rely on the machine copy of MSBuild 4.0.

That seems like a good strategy in general but ends up breaking down in a couple of cases. The reason is that these custom deployments may bring along props / targets that aren't part of the machine state.

Consider for example the bootsrap case on a clean machine. A machine which never had any version of MSBuild installed via MSI. There will be no reference assemblies or portable target files. Hence <Import> declarations of the following nature will fail when using the 4.0 installation of MSBuild

<Import>$(MSBuildExtensionsPath32)\Microsoft\Portable\v5.0\Microsoft.Portable.CSharp.targets</Import>

This works using the custom deployment of MSBuild because $(MSBuildExtensionPath32) is set to the proper place in the deployment. The machine copy of MSBuild 4.0 though will use C:\Program Files(x86)\... which has nothing to offer. Ends up leading to errors like the following when using GitLink.

Failed to load project 'E:\code\roslyn\src\Compilers\Core\Portable\CodeAnalysis.csproj': The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v5.0\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. E:\code\roslyn\build\Targets\Imports.targets

A number of tools are handling this by allowing the path to MSBuild to be specified as a command line option (NuGet.exe for instance). Would it be possible to get this added to GitLink as well?

[GeertvanHorrik]

Pinging @AArnott since he knows more about this than I do.

[AArnott]

@jaredpar Which version of GitLink are you using? If the v2.x variety, where the command line tool may actually invoke MSBuild, that's obsolete anyway. If you use the v3.x beta that is now on chocolatey and nuget, the only MSBuild use in GitLink is when MSBuild invokes GitLink rather than the other way around, so I think we've already addressed this.

[GeertvanHorrik]

GitLink has never invoked msbuild, but it did use the vs project system to load the projects (to retrieve the output directories + pdb files). Probably that's what you are seeing and I think the solution @AArnott is suggesting (use the upcoming 3.0.0 which is equal to PdbLink) is the best.

[jaredpar]

GitLink has never invoked msbuild, but it did use the vs project system to load the projects (to retrieve the output directories + pdb files). Probably that's what you are seeing

Agree. That seems to be what is causing the problem here.

I think the solution @AArnott is suggesting (use the upcoming 3.0.0 which is equal to PdbLink) is the best.

Is there a nice HOWTO consume this new version document we can take a look at?

[AArnott]

but it did use the vs project system to load the projects

Not strictly true. The VS project system is not involved here as this is just an msbuild operation. When I say "invoked MSBuild" I didn't mean executed msbuild.exe, but it does call into MSBuild assemblies, which it must find in the GAC or other places.

Is there a nice HOWTO consume this new version document we can take a look at?

Yes: I think this page has all the instructions you need. 😋 Just install the package and it works automatically on release configuration builds. Same as PdbGit in that sense. There is also a command line tool you'll find in the nuget package that you can pass an individual pdb to if you prefer that route.

[jaredpar]

There is also a command line tool you'll find in the nuget package that you can pass an individual pdb to if you prefer that route.

Likely prefer that route. We only ship a small subset of our entire solution and only add source server info on very specific builds.

Thanks!

[Roblinde]

I'm running into this as well when trying to add GitLink 3.0 to NetStandard 1.4 project.

Getting:

error MSB4062: The "LinkPdbToGitRemote" task could not be loaded from the assembly GitLinkTask.dll.
Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0
, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. 
The system cannot find the file specified. 
Confirm that the <UsingTask> declaration is correct, 
that the assembly and all its dependencies are available, 
and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

A quick scan of my system shows that I do have the Microsoft.Build.Utilities.v4.0 installed, just probably not where LinkPdbToGitRemote is looking.

Any suggestions on how to solve this?

Thanks!

[AArnott]

@Roblinde are you seeing this when building within VS? at the command line with msbuild.exe, or dotnet build, or a combination?

[pharring]

Just FYI, Application Insights also uses GitLink 2.2 and we ran into this same problem (MSBuild 4.0 doesn't resolve our .props). Had to workaround it in microsoft/ApplicationInsights-dotnet#496
We will probably move to 3.0 when it's stable.

[Roblinde]

@AArnott seeing it both with dotnet build and from within VS. Haven't tried MsBuild.exe directly.

@pharring thanks, I'm actually running the 3.0 build which is why I was a bit surprised to see the issue.