Questions / solutions to deploying local builds, nightlies, and multiple instances of Visual Studio 2017 (nicknames) #3664
Comments
|
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 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 |
|
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
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.
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
In set COMPILER78ASSEMBLIESPATH=%X86_PROGRAMFILES%\Reference Assemblies\Microsoft\FSharp\.NETCore\3.78.%FSHARPVERSION2%.0Isn't that the location of (one of the versions of) .NET Core, aka CoreCLR? |
|
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. |
|
@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. |
|
@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). |
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. |
|
Actually it will be less complex.
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. |
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:
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. |
|
@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 :-) |
|
@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 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. |
|
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. |
|
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? |
|
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.com%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.com%2Fnotifications%2Funsubscribe-auth%2FAE76FqNWtx5SLTtfOC36fHDiz3OvlOXfks5snIsGgaJpZM4PoHIt&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C527d701791d24e9f73b408d507017ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636422625363202065&sdata=k3jDExJgBcgACJGbdmfmWC8TkWLqUygqcDkeAobzJbA%3D&reserved=0>.
|
|
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 ;) |
|
You, me and @brettfo have them on our todo list :-) |
|
BTW - see https://github.com/dotnet/roslyn/tree/master/src/Compilers/Extension (specifically here) for how Roslyn manages this. There is a VSIX that on-load updates some msbuild extensions in per-user folders to redirect the compiler path. |
|
Closing this since numerous improvements have been made, including:
Not perfect, but it seems like a lot of what was discussed here as been addressed. |
|
I agree, thanks for taking care of this! |
Motivation for this question: the instructions say you can run
update-vsintegration.cmdand 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:
fsc.exeandfsi.exeand related librariesHow 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:
update-vsintegration.cmdupdates 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?VSIXInstallto 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?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.The text was updated successfully, but these errors were encountered: