Questions / solutions to deploying local builds, nightlies, and multiple instances of Visual Studio 2017 (nicknames)

[abelbraaksma]

Motivation for this question: the instructions say you can run update-vsintegration.cmd and if you want to restore, you can do so by running a Repair using Visual Studio 2017 setup. After I did that, I found out that several files in the deployed directories were still the local-built assemblies, yet others were rolled back correctly.

So, the goal is to collect some more insights, try them out, and if necessary create relevant PR's to fix things, hence /cc @dsyme, @KevinRansom, @cartermp.

We have roughly the following parts:

• F# SDK tools, this is fsc.exe and fsi.exe and related libraries
• F# Visual Studio integration, which is the whole of all services, libraries that do the syntax highlighting, handle keystrokes, intellisense and integrate FSI with VS.
• The test suite, which contains unit tests, stress tests and integration tests

How do these parts fit in inside a typical Visual Studio 2017 installation?

More to the point, this is a brain dump of some questions I have been having the last couple of days or so, while working with the build scripts:

• Running update-vsintegration.cmd updates the SDK paths, but it does not seem to effect Visual Studio (regardless of its name). How do I get Visual Studio to use the compiled libraries?
• How can I restore to the previous state?
• When using VSIXInstall to install/uninstall. If I install multiple times, and I uninstall, what is the expected effect? Do I get the situation back of pre-local (i.e., from whatever the VS2017 setup installed)? What files are replaced?
• VS2017 can be installed side-by-side (Preview, Enterprise, Code, Community), how do I install to a specific instance?
• And perhaps most importantly: how can I verify that the following elements are using the local builds? (using Process Explorer works, but is hardly productive)
  • Syntax highlighing, intellisense
  • Debugger
  • The compiler used when I select version F# 4.1 as target
  • The compiler when I select an older version of F#
  • The compiler when I select an older version of .NET
  • The compiler used for portable and .NET Core profiles
  • Version of FSI used
• The compiler tools can apparently also be installed via NuGet (but I don;'t think this updates the SDK), how do I use this technique to use my local build?

I realize I have often relied on click-and-run installations and never much had to manually adjust compilers and everything, unless for build scripts, but there it is easy enough. As you can see, I have trouble finding out what gets placed where and when and I think this is vital to know exactly, as users will report bugs inadvertently on older versions, or against versions they don't even know they are running.

Part of this is necessarily related to #3645 and #3643.

I'm sure I can find all of this out on my own, and I think I have most parts of the puzzle, but it would be great to verify so that I can update DEVGUIDE.md.

[KevinRansom]

@abelbraaksma :

We will add the compiler to the VSIX, there needs to be some magic to wire it up to msbuild. Roslyn does something similar. The MSI installer does not work for multiple instances and needs to be used only for reference assemblies dll's. It breaks our side by side story and the F5/Vsix install.

Nightlies and F5 install only install the VSIX (FSI/Editor/LangageService/ProjectSystem) no compiler updates.

The VSIX installer allows you to specify which instance of VS to install to.

We don't yet build and publish a desktop compiler nuget package. There is an FSharp.Compiler.nuget package, published by Steffen and Enrico.

VSixInstall will not install a second time until you uninstall.

The F# compiler used by VS and MSBuild is always the compiler in
C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0
Until we add it to the vsix.

When you select an older version of F# Core, the compiler remains as specified above. However we choose a different FSharp.Core version dependent on select fSharp.core.

When you select an older version of .net, the compiler remains as specified above. However we choose a different dotnet reference assemblies.

Ditto for different dotnet profiles.

There is no solution yet to installing the coreclr version of F#.

The compiler doesn't really evolve fast enough for us to get too confused by bug reports about the compiler.

I never directly use update-vsintegration.cmd.

I hope this helps

Kevin

[abelbraaksma]

Wow, many thanks @KevinRansom, this helps a lot!!! 💯 🥇.

So, essentially this means that, if you start playing around with the code and run some builds and run the VSIX or manual xcopy them, the syntax-parser/checker/highlighter is different from the compiler used when doing a Ctrl-Shift-B build in Visual Studio.

The compiler doesn't really evolve fast enough for us to get too confused by bug reports about the compiler.

While that makes sense, for people like me, who like to check upon resolved (compiler) issues, this helps explain why on several accounts I kept telling @dsyme I didn't see a change in behavior. Now it's clear why there's a difference.

I never directly use update-vsintegration.cmd.

Maybe you should ;) (it's also in DEVGUIDE). But I'm updating it so that it becomes more useful. Thanks to your answer I'm more confident about my changes. Apparently, that script does update the compiler used from Visual Studio, as it updates C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0 and some other SDK-related paths.

There is no solution yet to installing the coreclr version of F#.

In update-vsintegration.cmd there are lines that use variables set like the following:

set COMPILER78ASSEMBLIESPATH=%X86_PROGRAMFILES%\Reference Assemblies\Microsoft\FSharp\.NETCore\3.78.%FSHARPVERSION2%.0

Isn't that the location of (one of the versions of) .NET Core, aka CoreCLR?

[KevinRansom]

Well ... the trick is to install the vsix ... except that doesn't yet deploy the compiler. We would have included fsc in the VSIX when we first created it, except wiring it up to msbuild requires some magic to happen, because the VSIX installer puts the package in a directory with a random name and we need to find it. There is a way to do this, roslyn does it, by writing a breadcrumb file on package initialize. We will do the same thing ... eventually. However, other stuff keeps getting in the way.

[KevinRansom]

@abelbraaksma that directory is the path to FSharp.Core.dll portable profile for profile 78. Off the top of my head: net45+sl+win8 store+win phone 8 + Xamarin.

The name netcore predates the coreclr and in fact refers to the --targetprofile:netcore command line switch which is used to tell the F# compiler that object is in System.Runtime. Until I remove that requirement ... again other stuff keeps getting in the way :-)

If I was smarter or quicker ... I would have less stuff that needs to get done.

[abelbraaksma]

@KevinRansom, that sounds like that, once it is in VSIX, it becomes self-contained, that means, the SDK remains untouched and the VSIX will have all its files in one place? That sounds like an improvement to me (though at the expense of a bigger complexity).

[abelbraaksma]

If I was smarter or quicker ... I would have less stuff that needs to get done.

Well said! That haunts me everyday!

Tx, I should've known about those profiles. I don't do much .NET-for-mobile development, so it's easy to get confused.

[KevinRansom]

Actually it will be less complex.

• The compiler will no longer go into the sdk at all ... oh yeah side by side again.
• The MSI will only deploy the profile dll's and earlier versions of fsharp.core into the reference assemblies directory.
• The VSIX will ship with VS and install fsc, fsi, build tasks, targets & props, IDE, LanguageService, project system and templates into a well known location.
• Nightlies and F5 will install a duplicate of the VSIX only with updated bits into a per user random named directory ... it will be glorious.

There is no need to worry about profiles. they have gone away ... C# dropped them at VS2017 RTM, we will drop them by the end of the year. We will still ship them in VS but lose the templates, we already don't build updated ones.
Kevin
files/LanguageService/ProjectFiles and IDE

[abelbraaksma]

C# dropped them at VS2017 RTM, we will drop them by the end of the year.

Aha. I thought I heard such rumor...

The story on the considered update for the installation and debugging experience sounds awesome, esp. the last line:

Nightlies and F5 will install a duplicate of the VSIX only with updated bits into a per user random named directory ... it will be glorious.

which is precisely what I have been struggling with to get right. Just no wish to have to install a whole VM just to do some testing, or do a full repair just because I'm not 100% sure I didn't utterly screw something up by hand in the myriad of files, settings, reg entries, ngen'ed images, strong-naming, or not etc etc.

[KevinRansom]

@abelbraaksma we know it is a pain in the nether regions, it's just there is so much to do that this low hanging fruit takes a long time to get done. @OmarTawfik put the vsix together and @brettfo wired up the nightlies. Once we add the compiler and refactor the VSIX we will be set. Well apart from the 900 other things of course :-)

[abelbraaksma]

@KevinRansom, I totally understand, I wasn't trying to put pressure on you or anybody else in any way. I really appreciate the fast feedback I'm getting in this project 👍 .

For me to do some meaningful work, it is necessary to understand this process properly. My current update for the update-vsintegration.cmd will lessen the immediate need for an updated VSIX, as I've added a rollback mechanism, so you can switch between local built and official versions easily.

But I wasn't sure I was testing the right things. Your remarks here have helped a lot in speeding that part up. It is basically finished, so you can expect a PR soon.

[KevinRansom]

I didn't interpret it as pressure my friend. This is a hard repo to deal with, and we fail at some of the easy stuff. But it really is amazingly better than it was and it is slowly getting better. The test stuff is what worries me the most. I have no idea how to deal with it.

[abelbraaksma]

You mean coverage? Cause I'm working on that, at least for the reporting of it ( these other questions are related to it), or do you mean stability of tests? Or the complexity of the whole test set and the difficulty of running gui tests?

[KevinRansom]

Coverage would be good … but we have 3 or 4 different test frameworks. They have poor integration with VS … are hard to run, hard to debug, and hard to diagnose. From: Abel Braaksma [mailto:notifications@github.com] Sent: Thursday, September 28, 2017 11:16 PM To: Microsoft/visualfsharp <visualfsharp@noreply.github.com> Cc: Kevin Ransom <Kevin.Ransom@microsoft.com>; Mention <mention@noreply.github.com> Subject: Re: [Microsoft/visualfsharp] Questions / solutions to deploying local builds, nightlies, and multiple instances of Visual Studio 2017 (nicknames) (#3664) You mean coverage? Cause I'm working on that, at least for the reporting of it ( these other questions are related to it), or do you mean stability of tests? Or the complexity of the whole test set and the difficulty of running gui tests? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.202132.xyz%2FMicrosoft%2Fvisualfsharp%2Fissues%2F3664%23issuecomment-333040273&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C527d701791d24e9f73b408d507017ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636422625363202065&sdata=rwARcOOez5tBlWrzRIlnh1HTuXDp5OJpXr8UipwdDFQ%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.202132.xyz%2Fnotifications%2Funsubscribe-auth%2FAE76FqNWtx5SLTtfOC36fHDiz3OvlOXfks5snIsGgaJpZM4PoHIt&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C527d701791d24e9f73b408d507017ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636422625363202065&sdata=k3jDExJgBcgACJGbdmfmWC8TkWLqUygqcDkeAobzJbA%3D&reserved=0>.

[abelbraaksma]

Ah, you mean the mix of nunit, fsunit,unquote etc? I don't think they integrate badly (at least not with ncrunch, though there are some issues), but some tests give problems due to the way they are written. That won't change with a different framework. It's also on my to-do list ;)

[KevinRansom]

You, me and @brettfo have them on our todo list :-)