Run VsDevCmd.bat as part of init-tools

[maririos]

The dev workflow scripts doesn't work in a vanilla cmd. We are now going to call VsDevCmd.bat from init-tools.cmd and not from build.cmd to make the env. variables (like setting msbuild in the path) available for all the scripts that we use.

cc: @jhendrixMSFT @joperezr @weshaggard

[weshaggard]

@ellismg PTAL as I know you had some thoughts on changes to init-tools.cmd. While I don't particularly like this approach I think it does make things easier.

@maririos we should probably follow the same idea in init-tools.sh and add the Tools to the path so we can run msbuild on x-plat. It may also be worth creating a wrapper msbuild.cmd/sh script that abstracts away the need for prefixing with corerun in the individual scripts.

[mellinoe]

It may also be worth creating a wrapper msbuild.cmd/sh script that abstracts away the need for prefixing with corerun in the individual scripts.

Has MSBuild considered just using coreconsole? @dsplaisted

[weshaggard]

@mellinoe we could consider that but we are using a shared framework here so we don't want all the individual tools to have their own host.

[ellismg]

I thought one of our guiding principals was that we didn't want to be injecting stuff into folks environments. This feels little wonky to me.

Long term the plan is to move off of requiring Dev14 installed and instead just consume Roslyn and MSBuild from packages which are restored as part of the tool runtime, correct? In that case, we wouldn't need this anymore?

Do we actually envision a bunch of scripts such that it's prohibitive to just call VsDevCmd.bat from within a script (under setlocal) if the paths aren't defined? If we want to centralize the location to hook up VsDevCmd.bat if needed we could always add a script just for that (which doesn't setlocal) and then call it from all our dev workflow scripts.

[jhendrixMSFT]

@ellismg You have a good point. I think having a centralized script for hooking up VsDevCmd.bat that is invoked from all of our dev workflow scripts is a reasonable solution.

[weshaggard]

@ellismg yes that is our longer term goal and I completely agree with the principal of not mutating the environment. We are trying to figure out the best way to enable this. Perhaps using setlocal in the scripts can help block polluting the environment but it will force folks to use those scripts more often or update their environment.

As for whether or not it is another script or init-tools don't feel strongly about it but I would like to avoid introducing yet another script and would prefer we just do it in init-tools but scope it via setlocal in all the scripts that call init-tools. However if folks want to have it mutate their environment then can call init-tools directly (or we can make an option for init-tools).

[maririos]

I would also prefer to have it in init-tools as I don't think it deserves a full script for it.
As more dev workflow scripts are added (build-packages, build-tests) and they don't call init-tools directly, I think @weshaggard solution of having an option in init-tools will work. That way we can call it only when needed with that specific option but setting it local to that script.

[dsplaisted]

@mellinoe

It may also be worth creating a wrapper msbuild.cmd/sh script that abstracts away the need for prefixing with corerun in the individual scripts.

Has MSBuild considered just using coreconsole? @dsplaisted

We haven't given it much consideration either way. It certainly would be more convenient to use if we didn't have to specify the host separately. If you think this is the right way to go please file an issue in the MSBuild repo.

[weshaggard]

@dsplaisted @mellinoe for now I think I would prefer we keep it as it is and not switch to a native CoreConsole host because I want to use a shared runtime for all the tools. If we find that to be problematic we can revisit.

[weshaggard]

@maririos Are we not doing this any longer? Did you plan to figure out another way and open another PR?

[maririos]

@weshaggard my mistake, I deleted the branch by error. This still on my plate and it is the next thing I'm working on. I reopened the issue.
Thanks Wes

[maririos]

This change is now part of the encapsulation work that we are doing and it is being track by issue #7652 so I'm closing this PR.