Don't invoke MSBuild from within the CLI about source-build HOT 15 CLOSED

In general we need to be killing environment variables. Letting them influence our build this way is just creating a new razzle. Not our goal.

Instead use explicit parameters

from source-build.

I still have a inkling that the CLI could do something better to support this scenario. Maybe an option that doesn't set these env vars?

For sure, the "CscToolExe" env var is a hack. This doesn't work for non-built-in languages like F#, so why do we do C# this way?

The other 2 env vars MSBuildExtensionsPath and MSBuildSDKsPath are necessary though, it tells dotnet msbuild where to find its assets.

I'd hate tell people that they can't/shouldn't use dotnet msbuild to build their MSBuild projects, and they they have to go about finding/restoring/installing their own MSBuild just to build an MSBuild project. You should be able to use dotnet msbuild in the normal cases.

from source-build.

It is still the case that we don't want anyone being dependent on the internal folder layout of the .NET Core SDK. So if you are still assuming that MSBuild.dll is in a specific location of the SDK, then it still needs to be changed.

from source-build.

That being said, I also think we need to fix certain repos - like corefx - that don't use the CLI's dotnet to build on Windows, but use it to build on Linux. I think building corefx should be consistent across platforms.

Totally agree that is something that is being worked on by @joperezr

from source-build.

from source-build.

@eerhardt do you know if this is still the case?

from source-build.

@eerhardt I agree that we should try to use dotnet msbuild instead of assuming its location in the CLI and I also prefer that over downloading our own msbuild to use. What do you think is the right solution here? Should we fix the repos that don't work with this env variable or fix the CLI to stop setting them? Or do we have some extension point to try and clear those variables?

from source-build.

What do you think is the right solution here?

I think the right solution is what I said on Mar 7. #58 (comment)

I think the CLI needs to change to allow for this scenario.

from source-build.

If that is the case it sounds like we need a CLI issue tracking this so we can make some progress. cc @livarcocc @nguerrera

from source-build.

That being said, I also think we need to fix certain repos - like corefx - that don't use the CLI's dotnet to build on Windows, but use it to build on Linux. I think building corefx should be consistent across platforms. Instead today it uses whatever MSBuild is on the path, which is different between machines, and different between command prompts on the same machine.

from source-build.

I would like to understand why it's a requirement to let any constituent repos of source build override the compiler that is used. Ultimately, everything should be building with the same LKG toolset.

from source-build.

Because as it currently exists, different repos use different toolsets.

For example, coreclr and corefx use BuildTools, which currently brings its own MSBuild, Roslyn, etc. And on Windows, these repos currently use whatever MSBuild.exe is on the $Path, so there's another toolset.

The cli repo uses a different toolset to build - it uses a previously build .NET Core SDK which has a different MSBuild, Roslyn, etc.

I agree we should be moving towards using the same toolset, but it is taking a long time to get there. And to me it doesn't look like it is happening any time soon.

Another reason is because there are varying needs between the repos, and the same toolset may not work for all repos at all times. For example, right now corefx is using C# 7.2 and the latest Roslyn compiler. However, the latest Roslyn compiler is breaking coreclr. See dotnet/coreclr#14002 (comment). So in this case, we would be blocking corefx from moving forward because coreclr can't take the updated compiler.

from source-build.

dotnet/cli#7311 by @khyperia will remove the setting of CscToolExe. :) It is going in to 15.5 SDK. I think we wait until source build can use a 15.5+ SDK as LKG and then switch source-build to plain dotnet msbuild. I'm not worried about dotnet path/to/msbuild.dll in the meantime because 2.0 SDK layout won't ever change.

from source-build.

We just took a PR in master from @khyperia where we are no longer setting CscToolExe.

from source-build.

Applies to build.ps1, build.sh, and support/tarball/build.sh.

from source-build.