The new VS 17.12.1 seems to have broken WS 4.x builds

[nbevans]

The WS compiler seems unable to "see" any referenced types in other project files. It is emitting hundreds of typecheck error FS0039: The type 'MyType..' is not defined. from all over the project.

Has anyone else encountered this?

[granicz]

Are those projects correctly referenced and passed to the compiler? These errors come from before the WebSharper compilation.

[nbevans]

Yes I ran a detailed verbosity MSBuild and i can see the WsFsc.exe command line and it does include -r: args for each expected project reference assembly.

If i comment out the <WebSharperProject>Library</WebSharperProject> in the fsproj, it builds okay - but obviously without the WsFsc step.

[nbevans]

It should be noted that other WS projects build okay (in same solution) but these particular WS projects don't reference any other project assemblies. So the issue appears to be purely related to referenced project assemblies not behaving as before.

[granicz]

@Jand42 Any idea what's going on here?

[nbevans]

I have the .rsp file that gets passed into the WsFsc command line. Am trying to hack around with the .rsp file to see if there is some args to remove/add or otherwise tweak that might help...

[nbevans]

So the WsFsc produces a clear parse error FS0078: Unable to find the file if I change one of the -r references to be an invalid filename.

This means the references going in are valid. But when it performs the compilation, none of the types/namespaces etc in those referenced assemblies can be resolved.

[granicz]

If you ilspy those assemblies, do they contain what you expect?

[nbevans]

Yeah I used a decompiler and they seem to be fine. They contain the types that wsfsc says are missing.

[granicz]

If you replace the offending project references with direct file references, does it make a difference?

[nbevans]

Do you mean replace the SDK-style in the fsproj with the non-SDK style way of referencing projects?

I tried reverting those to how they were some years ago before we refactored to SDK-style projects - and it appears to have made no difference to the errors coming out of wsfsc

The -r:path1\path2\foo.dll args to wsfsc are already absolute paths to the compiled dll

[nbevans]

Okay changing to:

<ItemGroup>
	<Reference Include="myproject2">
		<HintPath>bin\Debug\myproject2.dll</HintPath>
	</Reference>
</ItemGroup>

This kind of approach seems to make a difference to wsfsc (!) I will change them all to this style and see how that goes. What could be the root cause of this though? This feels a bit odd to have happened?

[nbevans]

Unfortunately whilst this fix seems to want to work, it doesn't work reliably. I can't quite pin down why it works for a while, but then stops working.

[nbevans]

Using VS Build Tools LTSC 17.10.9 as the msbuild tool seems to make the build issues go away. So is a regression in MSBuild 17.12 ?

Only issue is that VS 17.12.9 will frequently mess with the build output and require me to restore package via the older msbuild tool.

[nbevans]

If I replace all <ProjectReference> with old fashioned <Reference Include=..><HintPath><Private> equivalents, I can get the build to work but now (from 1 project only - bizarrely) I am seeing some low-level WSFSC errors that are different to the original issue:

WebSharper error FS9001: Unhandled F# compiler generated constructor
WebSharper error FS9001: Failed to translate union case test
WebSharper error FS9001: Type not found in JavaScript compilation

I am not sure whether this indicates the binary produced by the newer FSC is somehow incompatible with WSFSC - or whether this issue has arisen because of the changes to how projects are referenced.

[nbevans]

Okay it looks like these WS errors can be worked around by creating more proxy types and just spending time on going through the errors.

I'm guessing the changes to the project references has broken some technique that WSFSC was using to resolve those projects to find the original types, at least those which didn't need explicit proxy impls. That's odd? Maybe there is a solution to reinstate that behaviour somehow.

[granicz]

@nbevans Thanks for the detailed reports, @Jand42 might have some ideas. In the meantime, have you guys thought about updating to WebSharper 8 beta? If you need help with the update, I can send an invite to our new discord channel.

[nbevans]

Thank you for the discord suggestion - an invite would be warmly received by myself (and not just for this issue).

We are looking to update WS next year; there is a lot of work involved as you can probably imagine. This product is still on net48 and on an OWIN stack. From what I can see WS stopped supporting OWIN some years ago - so we need to migrate the entire OWIN hosting to AspNetCore first. Although, I think AspNetCore does have a OWIN-compat shim that might help us defer some of the porting costs until later - but I don't know if this compat shim has major cons or is even compatible with WS5/6/7/8

For us, right now, it would be best to resolve this build issue in the new MSBuild so that we have sufficient time to properly plan and execute the overall tech stack upgrade.

[nbevans]

I have created an issue on the MSBuild project as my current thought process is that if it works on MSBuild 17.10 but does not work on 17.12 then this is a behavioural regression that they will surely want to know about.

dotnet/msbuild#11019

[granicz]

@nbevans Here is the Discord invite - https://discord.gg/s4nDcXnP