Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
For Web Projects, VS2012 sets some crazy imports that MD currently has no way to handle:
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<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" />
@mhutch, I think we actually parse all these things now with the new project model drop.
No, because we still use an internal engine for evaluation.
> 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.
Hm. Do we set VisualStudioVersion? Because falling back to "10" isn't great.
No, we don't set a VisualStudioVersion. This might be a good plan for VSfM.
Note that if the project imports Microsoft.Common.props then *that* will set VisualStudioVersion.
What needs to be done?
I checked with MD master and VS2017:
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".
On Mac it's 10.0 in commandline msbuild too.
I forked the common props issue into bug 54309.
Note also that the VS MSBuild toolset sets
<property name="VSToolsPath" value="$(MSBuildProgramFiles32)\MSBuild\Microsoft\VisualStudio\v$(VisualStudioVersion)"/>
This fixes the issue with the $(VisualStudioVersion) being 10.0, on the command line and during the build in XS.
And this adds a fallback path for $(VSToolsPath) - /Library/Frameworks/Mono.framework/External/xbuild/Microsoft/VisualStudio/v$(VisualStudioVersion) .
Fixed VisualStudioVersion and VSToolsPath in the built-in evaluator with https://github.com/mono/monodevelop/pull/2087/commits/665a6cc6141042f4a09a9634e7b26d7bcf95d244
PR was merged.
Hello @Mikayla Hutchinson,
can you provide proper steps or description for verifying this bug.