{"action":"created","issue":{"url":"https://api.github.com/repos/GitTools/GitLink/issues/145","repository_url":"https://api.github.com/repos/GitTools/GitLink","labels_url":"https://api.github.com/repos/GitTools/GitLink/issues/145/labels{/name}","comments_url":"https://api.github.com/repos/GitTools/GitLink/issues/145/comments","events_url":"https://api.github.com/repos/GitTools/GitLink/issues/145/events","html_url":"https://github.com/GitTools/GitLink/issues/145","id":209815273,"number":145,"title":"Handle custom MSBuild location","user":{"login":"jaredpar","id":146967,"avatar_url":"https://avatars3.githubusercontent.com/u/146967?v=3","gravatar_id":"","url":"https://api.github.com/users/jaredpar","html_url":"https://github.com/jaredpar","followers_url":"https://api.github.com/users/jaredpar/followers","following_url":"https://api.github.com/users/jaredpar/following{/other_user}","gists_url":"https://api.github.com/users/jaredpar/gists{/gist_id}","starred_url":"https://api.github.com/users/jaredpar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaredpar/subscriptions","organizations_url":"https://api.github.com/users/jaredpar/orgs","repos_url":"https://api.github.com/users/jaredpar/repos","events_url":"https://api.github.com/users/jaredpar/events{/privacy}","received_events_url":"https://api.github.com/users/jaredpar/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2017-02-23T16:38:04Z","updated_at":"2017-04-01T17:31:00Z","closed_at":"2017-02-26T18:54:54Z","body":"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.  \r\n\r\nIt 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.  \r\n\r\nThat 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. \r\n\r\nConsider 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\r\n\r\n``` xml\r\n<Import>$(MSBuildExtensionsPath32)\\Microsoft\\Portable\\v5.0\\Microsoft.Portable.CSharp.targets</Import>\r\n```\r\n\r\nThis 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.\r\n\r\n> 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 <Import> declaration is correct, and that the file exists on disk.  E:\\code\\roslyn\\build\\Targets\\Imports.targets\r\n\r\nA 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? \r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/GitTools/GitLink/issues/comments/290934817","html_url":"https://github.com/GitTools/GitLink/issues/145#issuecomment-290934817","issue_url":"https://api.github.com/repos/GitTools/GitLink/issues/145","id":290934817,"user":{"login":"pharring","id":9952654,"avatar_url":"https://avatars0.githubusercontent.com/u/9952654?v=3","gravatar_id":"","url":"https://api.github.com/users/pharring","html_url":"https://github.com/pharring","followers_url":"https://api.github.com/users/pharring/followers","following_url":"https://api.github.com/users/pharring/following{/other_user}","gists_url":"https://api.github.com/users/pharring/gists{/gist_id}","starred_url":"https://api.github.com/users/pharring/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pharring/subscriptions","organizations_url":"https://api.github.com/users/pharring/orgs","repos_url":"https://api.github.com/users/pharring/repos","events_url":"https://api.github.com/users/pharring/events{/privacy}","received_events_url":"https://api.github.com/users/pharring/received_events","type":"User","site_admin":false},"created_at":"2017-04-01T17:31:00Z","updated_at":"2017-04-01T17:31:00Z","body":"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 https://github.com/Microsoft/ApplicationInsights-dotnet/pull/496\r\nWe will probably move to 3.0 when it's stable."}}
{"actor":{"display_login":"pharring"}}