Fsharp: VS2017 Build Issues

[cloudRoutine]

VS2017 does not add VS150COMNTOOLS as a system environment variable, so I needed to manually set it to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\ before the build script would start working properly. This seems worth noting in devguide.md

while the msbuild path resolution in build.cmd works in cmd it will fail in posh

:: Check prerequisites
if not '%VisualStudioVersion%' == '' goto vsversionset
if exist "%VS150COMNTOOLS%..\ide\devenv.exe" set VisualStudioVersion=15.0
if not '%VisualStudioVersion%' == '' goto vsversionset

if not '%VisualStudioVersion%' == '' goto vsversionset
if exist "%VS150COMNTOOLS%..\..\ide\devenv.exe" set VisualStudioVersion=15.0
if not '%VisualStudioVersion%' == '' goto vsversionset

But this can be fixed by changing it to

:: Check prerequisites
if not '%VisualStudioVersion%' == '' goto vsversionset
if exist "%VS150COMNTOOLS%\..\ide\devenv.exe" set VisualStudioVersion=15.0
if not '%VisualStudioVersion%' == '' goto vsversionset

if not '%VisualStudioVersion%' == '' goto vsversionset
if exist "%VS150COMNTOOLS%\..\..\ide\devenv.exe" set VisualStudioVersion=15.0
if not '%VisualStudioVersion%' == '' goto vsversionset

^ adding a trailing \ after "%VS150COMNTOOLS%"
which will still work in cmd

After that fix build.cmd all fails at the same point in both posh and cmd

While producing 152 warnings at the same time

I spent a couple of hours trying to track the bug down further, but I really have no idea how any of this wix/swix stuff works.

the fixes for errors above are in https://github.com/Microsoft/visualfsharp/pull/1760

along with a dotnet cli SDK version lock in global.json to prevent clashes from having preview3 or preivew4 installed.

Related information

• Operating system - Win10
• Branch - master
• .NET Runtime
• Editing Tools - VS 2017

[KevinRansom]

Use the "Developer Command Prompt for VS" from now on VS is going to be really .... really ... really side by side so no more global settings. It's probably best to get used to using the "Developer Command Prompt" that matches the VS you want to use.

[rleigh-codelibre]

@KevinRansom That implies running the command prompt by hand. Not so good when you want to use this in noninteractive workflows, for example for continuous integration; it's also a break with prior versions which is painful when you are building and testing against multiple versions.

If this is being deliberately removed, then there needs to be a documented way of sourcing stuff like vcvarsall from a batch file or other script which is completely noninteractive and independent of a developer command prompt.

[MatrixManAtYrService]

I agree with @rleigh-codelibre. I have a small army of scripts that build the libraries that my project needs to link to. The need to execute these builds by hand represents a huge extra step for newcomers to my team that shouldn't be necessary.

[cartermp]

Note that this is not for dealing with F# projects in general. This is for building the F# Compiler from source (or the Visual F# IDE tools via build vs).

[MatrixManAtYrService]

Oh dear, I'm barking up the wrong tree. Thanks @certermp.

My issue still stands, but it is regarding C++ development, and the way that the absence of a VS150COMNTOOLS variable is going to be a problem for us.

I'll go try and find the right tree to bark up.

In case searches lead others erroneously to this issue, here's the tree I picked: https://developercommunity.visualstudio.com/content/problem/13223/no-environmental-variable-vscomntools150.html

[rleigh-codelibre]

@MatrixManAtYrService Thanks for filing the other ticket; that is indeed exactly the problem I'm facing. Sorry for the noise on this apparently unrelated issue.

[ctaggart]

2690 should help everyone avoid this problem

[cartermp]

Note that there is also official guidance in this area: https://docs.microsoft.com/en-us/visualstudio/install/tools-for-managing-visual-studio-instances

The vswhere tool may be useful to us.