update FCS to 2.0.0.2

[vasily-kirichenko]

No description provided.

[dsyme]

You'll need to reference https://www.nuget.org/packages/FSharp.Compiler.Service.ProjectCracker/ too since the project cracking now lives in a different nuget package.

Docs are here: https://github.com/fsharp/FSharp.Compiler.Service/blob/master/docs/content/project.fsx#L309

HTML version here: https://fsharp.github.io/FSharp.Compiler.Service/project.html#Cracking-a-project-file

[vasily-kirichenko]

@dsyme Thanks, done.

[dungpa]

@vasily-kirichenko There are a few tests failing due to API changes in FSharpProjectFileInfo. Could you have a look?

[vasily-kirichenko]

Is it ok that the exe assembly is loaded during the test?

[vasily-kirichenko]

[dungpa]

@rneatherway Could you advise how to use FSharpProjectFileInfo.Parse in unit tests? Here is the error in tests:

Test Error : FSharpVSPowerTools.Tests.GoToDefinitionCommandTests.should be able to go to definition to an external class
System.MissingMethodException : Method not found: 'Void FSharpProjectFileInfo..ctor(System.String, Microsoft.FSharp.Core.FSharpOption1<Microsoft.FSharp.Collections.FSharpList1<System.Tuple2<System.String,System.String>>>, M icrosoft.FSharp.Core.FSharpOption1)'.
at FSharpVSPowerTools.Tests.ExternalProjectProvider..ctor(String projectFileName)
at FSharpVSPowerTools.Tests.GoToDefinitionCommandTests.getCommandFilter(String content, String filePath, String projectPath) in C:\projects\visualfsharppowertools\tests\FSharpVSPowerTools.Tests\GoToDefinitionFilterCommandTests
.fs:line 35
at FSharpVSPowerTools.Tests.GoToDefinitionCommandTests.should be able to go to definition to an external class() in C:\projects\visualfsharppowertools\tests\FSharpVSPowerTools.Tests\GoToDefinitionFilterCommandTests.fs:line 50

Here is the relevant code: https://github.com/vasily-kirichenko/FSharpVSPowerTools/blob/10eb557cab1733f36af29d90e59a96433b9cf9a7/tests/FSharpVSPowerTools.Tests/ExternalProjectProvider.fs#L9

I checked FCS repo, there isn't any unit test that uses FSharpProjectFileInfo.Parse. Thanks.

[dsyme]

I'm not sure you should be referencing this. The unit tests DLL for FCS.ProjectCracker doesn't reference ProjectCrackerTool. Has paket added the reference automatically?

That said, you will need to make sure ProjectCrackerTool.exe gets shipped as part of your VS extension

[vasily-kirichenko]

Yes, Paket added the reference automatically.

[rneatherway]

Don is right, you shouldn't need to reference the .exe, and it should be considered private, so don't call FSharpProjectFileInfo.Parse. Perhaps I should have made everything internal. Just call GetProjectOptions from the .dll. See FsAutoComplete for reference.

There is also this page: http://fsharp.github.io/FSharp.Compiler.Service/project.html#Cracking-a-project-file

However, I see that it still mentions FSharpProjectFileInfo.Parse, which it shouldn't, because that isn't exposed anymore.

[vasily-kirichenko]

OK, I removed reference to Tool.exe and changed code to not use Parse method. Now I got another kind of exception:

(note: the project file is not missing)

[vasily-kirichenko]

I pushed (unfinished, but compilable) changes.

[rneatherway]

I think it might be the .exe file that is missing. Make sure you have a Copy in your project file like I describe at http://fsharp.github.io/FSharp.Compiler.Service/project.html#Cracking-a-project-file

[dungpa]

@rneatherway Well, it's bummer. We need the whole project parsing information to reconstruct project providers. Is there any way to do it in new FCS?

[rneatherway]

Hm that's a bummer indeed. I'm sorry, I didn't realise anyone was using
that interface. Let's work out exactly what you need and how we can get
that back. The interface between the cracker dll and exe is private so we
can change that to pass more information if necessary and expand the
cracker dll interface.
On 16 Jan 2016 11:46 am, "Anh-Dung Phan" [email protected] wrote:

@rneatherway https://github.com/rneatherway Well, it's bummer. We need
the whole project parsing information to reconstruct project providers. Is
there any way to do it in new FCS?

—
Reply to this email directly or view it on GitHub
#1317 (comment)
.

[rneatherway]

@forki is it possible to tell Paket not to automatically add a reference to an assembly in a NuGet package?

[forki]

Mhm I think that could be done in paket.references - I think I saw an issue about that before, but can't remember if we implemented it ;-) not at pc right now. Please take a look and open a new issue if needed

[rneatherway]

OK I had a bit more of a look at this and it sounds like we should change the structure of the FSharp.Compiler.Service.ProjectCracker NuGet package a bit. At the moment we have:

├── lib
│   └── net45
│       ├── FSharp.Compiler.Service.ProjectCracker.dll
│       ├── FSharp.Compiler.Service.ProjectCracker.pdb
│       ├── FSharp.Compiler.Service.ProjectCracker.xml
│       ├── FSharp.Compiler.Service.ProjectCrackerTool.exe
│       ├── FSharp.Compiler.Service.ProjectCrackerTool.exe.config
│       └── FSharp.Compiler.Service.ProjectCrackerTool.pdb

but, as the exe should not be reference, but still copied into the final output folder, should we change it to something like:

├── build
│   └── net45
│       └── FSharp.Compiler.Service.ProjectCrackerTool.targets
├── content
│   └── net45
│       ├── FSharp.Compiler.Service.ProjectCrackerTool.exe
│       ├── FSharp.Compiler.Service.ProjectCrackerTool.exe.config
│       └── FSharp.Compiler.Service.ProjectCrackerTool.pdb
├── lib
│   └── net45
│       ├── FSharp.Compiler.Service.ProjectCracker.dll
│       ├── FSharp.Compiler.Service.ProjectCracker.pdb
│       ├── FSharp.Compiler.Service.ProjectCracker.xml

where the targets file contains the MSBuild Copy task that I recommend at http://fsharp.github.io/FSharp.Compiler.Service/project.html#Cracking-a-project-file ?

This doesn't affect the issue with not providing all the information that VFPT needs, but that can be handled orthogonally.

Sorry for this mixup, but it was my first NuGet package and I wasn't aware of the different features and how the folders would be interpreted by NuGet and Paket.

[dsyme]

@rneatherway Sounds good - that structure looks better!

[vasily-kirichenko]

I don't think we should merge it since we should stop working on VFPT in general.

[rneatherway]

Oh wow are the features going into the core tooling or something?

[vasily-kirichenko]

@rneatherway read this thread dotnet/fsharp#913 Basically, MS team is going to rewrite VFT using Roslyn Workspaces, which means 1. IDE support will be on pair with C#/VB (and will always be up to date) 2. VFPT will stop working. So I think the best thing we can do is to wait until MS team rolled out a Roslyn based VFT and start to contribute to it.

[tpetricek]

For the time being, we're relying on VFPT in F# Formatting (and therefore in the documentation generation for most F# projects out there) and having a VFPT build that use latest version of FCS would be really useful there.

It is only used for the advanced colorization, so perhaps we can extract that functionality in longer term, but for now, merging this PR would be nice for us....

[cloudRoutine]

I don't think we should stop working on VFPT, I think we should work on further decoupling the core functionality from the visual studio api's so the logic and the shell interop have a more tangible delineation. This will be necessary to integrate with the Roslyn workspace APIs that they want to use. The core logic of transforming data from FCS is not going to change fundamentally just because of this shit. There might be a bit more massaging at the edges but the foundation doesn't change.

[dungpa]

@tpetricek I've just pushed VFPT.Core 2.3.0 to NuGet. I'm sorry for the hassle but it has been difficult to update due to breaking changes in FCS.

[dsyme]

@vasily-kirichenko Please don't stop active work here. The fact that the Visual F# Tools team plan to open up a line of work on VFTR (my acronym for Visual F# Tools on Roslyn Workspaces) shouldn't mean that VFPT should stop.

Can we start a long-running discussion thread "What does VFTR mean for VFPT"? For example VFTR would seem to be a huge opportunity for VFPT.Core - all of the logic seems to be reusable. it's also possible that today's VFPT will continue to work with VFTR (perhaps with one or two fixes). That may be critical: it will take a while for VFTR to meet parity with VFT, let alone to incorporate what VFPT has.

[Krzysztof-Cieslak]

@dsyme Could we add Ionide (and preferably also other editors powered by FSAC) to this discussion? Kevin's comment:

It has long been the plan of record that Roslyn cross platform tooling for VSCode will be accomplished by integrating the Roslyn Workspaces layer using OmniSharp

has huge implications (to be fair, it's basically sentence of death) not only for VSCode Ionide but also for plugins for all other editors (as Omnisharp supports all editors). While I understand need of making OOB F# experience in VS, let's not pretend that it has no implications for tools which are at the moment provided by Community

[smoothdeveloper]

@Krzysztof-Cieslak, I see what is happening as Microsoft taking more stewardship on the core of F# tooling (since roslyn workspace is working without VS dependency if I understand correctly) which will enable more consistent experience across editors.

I see this as something similar as to having FCS used by all current tools, only now it will provide features closer to the editor / code transformation use cases, those features can be leveraged / enriched by the community.

[Krzysztof-Cieslak]

Edit: --- Removed random overreaction ---

[cloudRoutine]

@smoothdeveloper based upon the plan that @KevinRansom outlined it seems more like VFPT would be subsumed, Omnisharp would be in charge of all features related to F# tooling in VS code either to replace it or compete directly with it, which would be an unfortunate situation where F# tooling starts getting written in C# again and they take full control over new feature development, support and implementation. At some point in the future it could result in a somewhat more consistent feature set across VS and vscode, but it doesn't seem like other editors have a place in this plan at all. It doesn't seem like a cross platform approach that holds a lot of benefit outside of the "Microsoft Experience ™️"

If you looks at what @srivatsn has been implementing it's directly as a part of the VS integration, not being exposed for other tooling to consume.

As it currently stands it seems like the plan is to relegate Ionide to Atom exclusively and what's happening with VFPT seems to be up in the air. I started working on VFPT in the hopes of bringing some of it's great features into a cross platform service and it seems like that's the direction @dsyme wants us to go in as well.

I'm optimistic about this minor kerfuffle getting resolved in a way that will be most beneficial to the F# ecosystem as a whole and then we can get back to work on bringing F# users a wide variety of great editor tooling features 😄

[cloudRoutine]

discussion moved to dotnet/fsharp#925

[dsyme]

taking more stewardship on the core of F# tooling

This is not correct. The Visual F# Tools team just want to take their Visual F# Tools forward. They want to do the same sort of thing that you are all doing for the editor tooling happening with VFPT, Xamarin, Ionide. In a sense they want to be your peers, i.e. actually start working on their editor tooling again after a long period of little action. That's a good thing. You're reading way too much into it just because it's Microsoft team sketching it out.

I actually suggest we forget all mention of Omnisharp etc. per my comment here. This work wasn't motivated by Omnisharp - it was motivated by making the Visual F# Tools better in a way that is completely natural for the Visual F# Tools team. Any use of the outcomes of this in other editor settings are a long, long, long way away, so far that it's just wild speculation. This work is about Visual Studio and nothing else.

Please don't be negative here. The Visual F# Tools team really want to improve their tooling. Let them do it. And if you happen to use VS as your editor (or care about Visual F#, or F# more generally) then please help them where you can.

[smoothdeveloper]

@dsyme, understand and sorry for adding confusion. As a VS and F# user, I'm looking forward for the revamp of F# editor in Visual Studio, it's promising to see MS working on major F# features in the IDE.

I also think it would not make sense for MS to take dependency on FSharp Powertools Core, what seems to be needed is to expose the key underlying services that will be used in the new Visual F# Tools to it (so there aren't 2 FCS instances as mentioned in other comments).

I'm sure things will get sorted out toward the right solution.