Improve contributor experience with build.cmd

[abelbraaksma]

This issue is to minute suggested changes in a soon to be created PR. This follows from my recent bug reports on build.cmd. At the moment I am thinking of some cleaning up and slightly improved error reporting:

1. Remove code that can cause build.cmd and related build scripts to fallback to older build tools
   • For instance, if the VS2017 tools are not found, it will default to VS2015 or even VS2012 tools, with spurious errors as a result, this should be removed).
2. Fix that build.cmd all is broken, i.e. it removes FSharp.Core.dll from the Debug\net40\bin output directory (ideas???)
3. Raise a clean and clear error if an elevated command prompt is required:
   • scenario: seeing build errors after waiting a few minutes is rather tedious, and often nothing truly suggests you forgot to use an elevated command prompt).
4. Possibly: do not execute ngen if it is not required for the build:
   • this could alleviate problems some contributors have mentioned, in particular when they are in a restricted environment (question: not sure if there are other scenarios where an elevated command prompt is required).
5. Possibly: update the build server to run several variants of the build scripts. Or put this in a NUnit test. The output could be checked for the presence of errors/warnings, if not we have a failing test. This could help any contributor to make sure his code is clean of warnings, or fails in a lesser-used build scenario.
6. Remove warnings

   • several warnings are currently raised. They should either be suppressed, or fixed. For instance:

     D:\Projects\OpenSource\VisualFSharp\src\buildtools\fslex\fslexast.fs(14,6): warning FS0044: This construct is deprecated. The type 'Position' is less accessible than the value, member or type 'Code' it is used in.↔As of F# 4.1, the accessibility of type abbreviations is checked at compile-time. Consider changing the accessibility of the type abbreviation. Ignoring this warning might lead to runtime errors.

     D:\Projects\OpenSource\VisualFSharp\src\fsharp\FSharp.Compiler.Interactive.Settings\obj\debug\netstandard1.6\FSInteractiveSettings.fs(105,16): warning FS1182: The value 'GetStringFunc' is unused

     build.cmd all currently gives 685 warnings (!!!):
     

Other suggestions are welcome. I think if we make the learning curve less steep for new contributors, it may invite more of them to the club :).

[dsyme]

I think if we make the learning curve less steep for new contributors, it may invite more of them to the club :).

@abelbraaksma I totally agree, Thank you for working on the getting-started experience.

[KevinRansom]

@abelbraaksma

sigh !!! there is so much wrong with our build it is hard to know where to begin.

• That the build depends on VS 2017 at all is a mistake. I would welcome any pull request that eliminated the need to have an install of VS for the purpose of build at all. If we need to reference it, then nuget should be how we aquire it. If it isn't acquirable that we we should work with someone to get it nugetable.
• I'm not certain that any of our tests depend on VS either, but probably still may behave badly.
• Dunno what to do with that peverify, and link dependence that seems wrong too, but requires some thought about what makes sense.

Oh my!!!!, anyway thanks for thinking about this stuff, it just makes me want to cry.

Kevin

[abelbraaksma]

@KevinRansom, thanks for your input.

That the build depends on VS 2017 at all is a mistake.

It currently depends on an installation of, in order:

• VS2017 Enterprise, Professional, Community
• VS2017 Preview Enterprise, Preview Professional, Community
• VS2017 MS Build tools (devguide says 2013, not true)

However, if none of these are found, it currently gets hairy. If you have any other installation of VS installed, it will find that (back to 2012 I believe). Result: spurious errors (and the cause of some of my bug reports), as not all build tasks were available.

So, in short: it presently depends on either a VS 2017 installation (except VS Code), or MSBuild 2017. I don't think this is wrong, as it will default to the MSBuild tools (apart from the caveat mentioned above)

I searched for a way to use NuGet to get MSBuild, but I didn't find it. If you can ask the proper people at Microsoft to make MSBuild 2017 and up available by NuGet reference, it would be great and we can download it when not present.

I'm not certain that any of our tests depend on VS either, but probably still may behave badly.

I don't know either. Since I have yet to run a successful build all test (which should rebuild all and run all tests), I cannot know for sure. Obviously, running the VSIX installers will require VS

Dunno what to do with that peverify, and link dependence that seems wrong too, but requires some thought about what makes sense.

Not sure what you mean by this. It is part of the framework and I guess that's the one requirement we cannot live without. Or do you mean that we need the most recent version and currently we don't?