Fsharp: With Lightweight Solution load enabled: VS2017 Clean solution / Rebuild Solution doesn't work

[smoothdeveloper]

I'm unsure if this has been reported / fixed in latest RC:

• build a solution
• click clean on the root solution node
• click build on the root solution node

expected:

a new build is issued

currently:

nothing happens, also clean seems to have done nothing

(the menus somehow don't appear on my capture, I'm clicking clean and rebuild on solution, then on a single project)

[KevinRansom]

@smoothdeveloper

I am unaware of any bugs that were fixed in that area.

However, using the latest RTM build I was able to create a new project and build it by right clicking on the solution node.
Clean again on the solution node caused the built binaries to disappear.

Is there perhaps something different about the project you are using?

Kevin

[smoothdeveloper]

Thanks @KevinRansom, I'm trying with this solution: https://github.com/FSCL/FSCL.Compiler

[cartermp]

In my testing of RTM bits, with the Nu project, it's impossible to build from solution without explicitly building the Prime project first, even though it's clearly a project reference. I can then build from solution. In general, this stuff is kind of janky. I'm not sure if there's a regression here or not, but it's something we ought to really address.

[vasily-kirichenko]

For large solutions it's critical, at work I execute build on solution node a lot, for example.

[forki]

So something broke multi-project rebuild? I noticed a similar thing a while ago in RC 2 but thought I was stupid.
this an absolute show-stopper.

[lambdakris]

Rebuilding is a particularly important part of my workflow at work as I depend on type providers such as FSharp.Data and FSharp.Data.SqlClient, which often make it necessary to rebuild a project in order to regenerate the types when the example file or database has changed. I hope this can be addressed for RTM...

[KevinRansom]

I just got in ...

So ... I created a solution with Library1, Library2 and ConsoleApplication1.

Library 2 has a p2p reference to Library1
ConsoleApplication1.exe has a p2p reference to Library1

It appears to work correctly when building with the latest build from the RTM branch:

I will take a closer look at the project you are using. I would also be gratefull if someone can provide a repro using the out of the box templates. Because at least with them we do not suffer from the ingenious msbuild hand editing.
Thanks

Kevin

This is the highlights of the build output when building the solution from VS

````
1>------ Build started: Project: Library1, Configuration: Debug Any CPU ------
1> C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\fsc.exe -o:obj\Debug\Library1.dll
1>-g

.... elided options and references

1> Library1 -> \mac\home\documents\visual studio 2017\Projects\Library1\Library1\bin\Debug\Library1.dll
2>------ Build started: Project: Library2, Configuration: Debug Any CPU ------
2> C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\fsc.exe -o:obj\Debug\Library2.dll
2>-g

.... elided options and references

2>
2>-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.4.1.0\FSharp.Core.dll
2>-r:\mac\home\documents\visual studio 2017\Projects\Library1\Library1\bin\Debug\Library1.dll

.... elided options and references

2>
3>------ Build started: Project: ConsoleApplication1, Configuration: Debug Any CPU ------
3> C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\fsc.exe -o:obj\Debug\ConsoleApplication1.exe
3>-g

.... elided options and references

2>
3>-r:C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.4.1.0\FSharp.Core.dll
3>-r:\mac\home\documents\visual studio 2017\Projects\Library1\Library2\bin\Debug\Library2.dll

.... elided options and references

2>
3> ConsoleApplication1 -> \mac\home\documents\visual studio 2017\Projects\Library1\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe
========== Build: 3 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

````

[KevinRansom]

@smoothdeveloper

So I cloned the repo at: https://github.com/FSCL/FSCL.Compiler and opened the solution file.

Build, Clean and Rebuild worked the way I would expect them to work. Can you detail what VS you have installed and whether you have the OSS vsix or the preview VSIX installed.

And can you try to produce a simpler repro.

Thanks

Kevin

[smoothdeveloper]

@KevinRansom

Can you detail what VS you have installed and whether you have the OSS vsix or the preview VSIX installed.

I installed VS2017 RC few days ago on a freshly installed machine (see screen on the issue for exact VS version), I didn't install any VSIX on it.

I recall having enabled that "lightweight solution load", I'll try to disable it but that might be the reason I see this.

I would also be gratefull if someone can provide a repro using the out of the box templates.

Out of the box templates from VS2017 (haven't looked at them) aren't what is out in most F# projects though, I think most F# projects have VS2013 / VS2015 templates, FSCL projects don't have anything fancy AFAIU.

[vasily-kirichenko]

@smoothdeveloper with "lightweight solution load" enabled nothing works and has never worked.

[KevinRansom]

@smoothdeveloper
The out of the box templates should be virtually identical to the vs2013 templates from an msbuild perspective.

The reason for asking for a repro based on that is simply to remove as much environmental baggage as possible. The simpler the repro, the easier it is to diagnose the issue.

[smoothdeveloper]

@KevinRansom understood, I'll look more into it and hopefully find a simple repro.

[KevinRansom]

@smoothdeveloper It is lightweight solution load.

The bug is that with lightweight solution load projects don't build and clean correctly ... or it appears at all.

Thanks for sticking with it and remembering the key fact.

Changing the title:

[cartermp]

We'll have to message this clearly: Lightweight Solution Load should not be enabled when using F# until we can figure out a solution here (either in our own project system or externally).

[KevinRansom]

A fix for this will not make the bar for RTM. because the work around is to not enable Lightweight Solution Load for F# projects, until it is fixed.

Kevin

[vasily-kirichenko]

@cartermp the root problem is that VFT does not see collapsed projects at all. So, no solution-wide features works (go to definition, find refs, rename, etc, etc)

[cartermp]

I'm getting behavior that is all over the place, and it's not dissimilar from RC2. Regardless of if Lightweight Solution Load is turned on, my experience as commented still stands: the Nu project cannot be built from the Solution node unless the Prime project, which is depended on by multiple other projects, is built first. This is the same behavior as RC2.

Edit: Evidently I cannot turn off Lightweight Solution Load for my solution, even when closing/reopning the solution or restarting VS. The above behavior is likely due to that.

@vasily-kirichenko When you say collapsed, do you mean visually in the Solution Explorer tree? Build issues aside, I can use Find all References in the Nu solution just fine:

[smoothdeveloper]

Can we add simple text search (find in solution) to the list of things we test, I remember having to mess with individual project to get results to be picked up in those, while expecting the search to search everywhere just after opening a solution.

[cartermp]

@smoothdeveloper Can you provide a repo for that? I've never had text search fail. That's also something we don't control, though.

[smoothdeveloper]

@cartermp right now I do this:

• open FSCL.Compiler.sln
• in solution properties, enable lightweight loading
• close VS
• reopen FSCL.Compiler.sln
• search for "compile" in solution

current results only shows stuff which are not in projects themselves (.sln and .fsproj files are matched though).

I'll try to figure out how it works.

[cartermp]

Ah, so this issue is specifically when Lightweight Solution Loading is on. We'll route that issue as well, since I can repro it.

[cartermp]

Update: the team which owns the deferred project load (lightweight solution load feature) was able to identify the issue and know how to fix it.

Unfortunately, given the ship schedule for RTM of vs2017 (we're at a code freeze for stability purposes), the fix will have to wait until a later update.

Given that, Lightweight Solution Load should not be turned on. You can also turn it off via right-clicking on the solution file and then restarting VS. We'll message this for RTM.

[smoothdeveloper]

@cartermp thanks for the update.

Can we get the message to all teams working on transverse features of VisualStudio that the test cases / QA should always include some F# projects, I gather that that feature was tested with workloads involving C#, VB.NET, TypeScript, but F# is the omission, this is happening on several grounds (dotnet core .fsproj support in VS is a similar example).

The attitude for all MS supported languages should be consistent in this regard, and it doesn't necessarily mean that the feature team is going to do all the work, they'll log issue on this repository for tracking / getting help.

[saul]

@cartermp has this been fixed? When should we expect this to have rolled out?

[cartermp]

@saul No, it has not been fixed. There's currently no ETA, though one of the team members did get preliminary F# support working as an experiment.

[saul]

@cartermp I'm keen to get this working for F#. Is this something that will 'just work' with the new project system, or do we need to do more?

[cartermp]

@saul There's not much (if anything) we can do on our end - CPS support is orthagonal. Currently the work to support F# for Deferred Project Load (the mechanism that Lightweight Solution Load uses) is scheduled for 15.3. Since this is a closed-source area, there isn't anything actionable from the community. I believe that it should be available to test in the first Preview of 15.3, which should be available in a month or so.

[cartermp]

Closing this out. Official statement:

Visual Studio team had decided to discontinue Lightweight Solution Load (LSL) support in the 15.5 release. LSL provided lower than anticipated performance gains, forced Visual Studio customers to choose between faster solution load and a full set of Visual Studio features, and introduced complexity in developing Visual Studio extensions. Instead, we’re working on improving the mainline solution load experience for all Visual Studio customers. Solutions that contain C# and Visual Basic projects should see significant improvements in solution load times in the 15.5 release.

You can send your questions to Visual Studio solution load optimization team at [email protected].

Although the above mentions C# and VB projects, F# projects using the .NET Core SDK will benefit from the work going into project load time improvements. Although 15.5 won't be the release when we declare victory there, subsequent releases will see F# + .NET Core SDK projects benefit, especially as we work out perf issues in our own language service hookup to the project system.

The above improvements will _not_ make it into the current F# project system. This gives us even more motivation to work towards migrating all F# projects over to the .NET project system, thus allowing us to deprecate our own.