MSBUILD_EXE_PATH about buildalyzer HOT 8 CLOSED

I'm wondering if this could/should be used as an alternative to setting MSBuildExtensionsPath and MSBuildSDKsPath. For example, this seems to be working:

var ext = projectAnalyzer.GlobalProperties["MSBuildExtensionsPath"];
Environment.SetEnvironmentVariable("MSBUILD_EXE_PATH", Path.Combine(ext, "MSBuild.dll"));
projectAnalyzer.RemoveGlobalProperty(Buildalyzer.Environment.MsBuildProperties.MSBuildExtensionsPath);
projectAnalyzer.RemoveGlobalProperty(Buildalyzer.Environment.MsBuildProperties.MSBuildSDKsPath);

Setting RoslynTargetsPath still seems necessary though.

from buildalyzer.

Interesting. Do you have to remove the global properties for the environment variable to work or will the environment variable do the trick even when the global properties are set? If the latter I’d say we should go ahead set both. If keeping the global properties makes it so the MSBUILD_EXE_PATH environment variable is ignored and we have to remove them, then I’d want to be sure we’re not fixing one case by breaking another build configuration that depends on those global properties but not the environment variable.

That’s the frustrating part about this project - it’s like whack-a-mole. You figure out how to get one build configuration to work and another one breaks.

from buildalyzer.

Do you have to remove the global properties for the environment variable to work or will the environment variable do the trick even when the global properties are set?

It works the same either way. If you remove the properties, then MSBuild sets them to the directory component of MSBUILD_EXE_PATH, so they end up with the same value that Buildalizer uses. There is certainly no harm in leaving it the way it is.

from buildalyzer.

Cool - then I don’t see any problems with adding this as another environment variable that we set by default before running the build.

from buildalyzer.

Added this (it'll ship soon), but I'm setting MSBUILD_EXE_PATH to the same value as MSBuildToolsPath right now. That should help resolve some issues I noticed with VS (see #48). The way it'll work is that MSBUILD_EXE_PATH will get set to where Buildalyzer thinks it should be, but we'll honor a custom MSBUILD_EXE_PATH if it's already set (and adjust the tools path accordingly).

Perhaps the bigger problem is why Buildalyzer was unable to locate your MSBuild at it's correct location at "/usr/local/share/dotnet/sdk/2.1.4/MSBuild.dll". That should have been reported by dotnet --info which is what Buildalyzer uses for the check.

from buildalyzer.

As far as I can tell, there isn't really anything wrong with Buildalyzer. As you noticed in the other issue you linked, the interactions between MSBuild properties is so complex that it is rather difficult to get the "expected" results. Other projects, such as docfx, suffer from the same sorts of problems with MSBuild.

from buildalyzer.

Buildalyzer 1.0.0 was released to NuGet last night. Can you please try it out when you get the chance and let me know the status of this issue?

FYI - the Buildalyzer 1.0.0 API has changed significantly. Revised documentation is forthcoming, but I wanted to get the release out there ASAP. Hopefully you'll be able to figure out the differences, but if not the source code of the tests is a good place to look or wait until better docs are out next week.

from buildalyzer.

I just published Buildalyzer 2.0 which runs MSBuild out-of-process (as opposed to the old way of running it via MSBuild APIs). In general, if you can build it Buildalyzer should now be able to build it. Given how drastically different this new technique is, I'm closing all existing bug reports.

Please try the new version and if you're still having problems, please open a new issue.

from buildalyzer.