Bug 10861 - Support for VSToolsPath in MSBuild engine
Summary: Support for VSToolsPath in MSBuild engine
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Visual Studio Compatibility ()
Version: Trunk
Hardware: PC Windows
: Normal normal
Target Milestone: 15.2
Assignee: Lluis Sanchez
URL:
Depends on:
Blocks:
 
Reported: 2013-03-03 21:41 UTC by Mikayla Hutchinson [MSFT]
Modified: 2017-05-09 06:42 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Mikayla Hutchinson [MSFT] 2013-03-03 21:41:18 UTC
For Web Projects, VS2012 sets some crazy imports that MD currently has no way to handle:

  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Comment 1 Marius Ungureanu 2016-11-03 10:58:25 UTC
@mhutch, I think we actually parse all these things now with the new project model drop.
Comment 2 Mikayla Hutchinson [MSFT] 2016-11-03 18:11:01 UTC
No, because we still use an internal engine for evaluation.
Comment 3 Marius Ungureanu 2016-11-07 09:22:01 UTC
> No, because we still use an internal engine for evaluation.

We do set MSBuildBinPath and MSBuildExtensionsPath32, so these should be evaluated? I'm  not sure what you're referring to.
Comment 4 Mikayla Hutchinson [MSFT] 2016-11-07 16:22:56 UTC
Hm. Do we set VisualStudioVersion? Because falling back to "10" isn't great.
Comment 5 Marius Ungureanu 2017-02-14 08:46:00 UTC
No, we don't set a VisualStudioVersion. This might be a good plan for VSfM.
Comment 6 Mikayla Hutchinson [MSFT] 2017-02-14 16:31:04 UTC
Note that if the project imports Microsoft.Common.props then *that* will set VisualStudioVersion.
Comment 7 Lluis Sanchez 2017-03-30 10:48:17 UTC
What needs to be done?
Comment 8 Mikayla Hutchinson [MSFT] 2017-03-30 23:01:10 UTC
I checked with MD master and VS2017:

VS: VisualStudioVersion=15.0
Windows MD: VisualStudioVersion=15.0
Mac MD + msbuild: VisualStudioVersion=10.0
Mac MD + xbuild: VisualStudioVersion=14.0

These values are coming from the MSBuild _engine_. They're not set by MD. So MD needs to handle them in its MSBuild evaluator.

It also looks like there's a problem in our Mac MSBuild if it's using version "10.0".
Comment 9 Mikayla Hutchinson [MSFT] 2017-03-30 23:04:29 UTC
On Mac it's 10.0 in commandline msbuild too.
Comment 10 Mikayla Hutchinson [MSFT] 2017-03-30 23:05:23 UTC
I forked the common props issue into bug 54309.
Comment 11 Mikayla Hutchinson [MSFT] 2017-03-30 23:55:46 UTC
Note also that the VS MSBuild toolset sets

<property name="VSToolsPath" value="$(MSBuildProgramFiles32)\MSBuild\Microsoft\VisualStudio\v$(VisualStudioVersion)"/>
Comment 12 Ankit Jain 2017-03-31 03:05:59 UTC
This[1] fixes the issue with the $(VisualStudioVersion) being 10.0, on the command line and during the build in XS.

And this[2] adds a fallback path for $(VSToolsPath) - /Library/Frameworks/Mono.framework/External/xbuild/Microsoft/VisualStudio/v$(VisualStudioVersion) .

1. 
https://github.com/mono/msbuild/commit/04770809b3d0ef5690cf0b8509de8d588677ddbf

2. https://github.com/mono/msbuild/commit/baa1b304633f0407450febf427da111c6faae71e
Comment 13 Mikayla Hutchinson [MSFT] 2017-03-31 04:06:23 UTC
Fixed VisualStudioVersion and VSToolsPath in the built-in evaluator with https://github.com/mono/monodevelop/pull/2087/commits/665a6cc6141042f4a09a9634e7b26d7bcf95d244
Comment 14 Mikayla Hutchinson [MSFT] 2017-03-31 18:21:43 UTC
PR was merged.
Comment 15 Roshan Mankani 2017-05-09 06:42:31 UTC
Hello @Mikayla Hutchinson,
can you provide proper steps or description for verifying this bug.