WebSharper 10.1.8

This is a minor release of WebSharper 10.1. NuGet version 10.1.8.682.

Templates for .NET Core SDK: dotnet new install WebSharper.Templates@10.1.8.682

Enhancements

• Faster builds:
  • #1608 wsfsc, wscsc and the wsfscservice booster now run with Server GC (non-concurrent), like fsc and csc.
  • #1609 The F# type check needed for WebSharper translation now uses the F# compiler service's TransparentCompiler, which type checks files in parallel. This applies to both standalone compilation and the wsfscservice booster. Opt out system-wide with the WebSharperTransparentCompiler environment variable set to false, or per project with "transparentCompiler": false in wsconfig.json, the WebSharperTransparentCompiler MSBuild property set to false, or the --transparentcompiler- flag.
  • #1587 F# projects now emit the .NET assembly in parallel with WebSharper translation, both standalone and through the booster. When translation needs to reflect into the project's own assembly (macros or generators defined in the same project, [<ReflectedDefinition>] bodies, RequireFeature types, RPC signature verification), it waits for the assembly at that point. WIG and bundle-only projects still compile serially. Opt out with "parallelCompilation": false in wsconfig.json, the WebSharperParallelCompilation MSBuild property set to false, or the --parallelcompilation- flag. The --wstimings / WebSharperTimingLog stage log reports the emission separately, plus Waiting for F# output (join) and Waiting for F# output (reflection) stages for the time translation was blocked on it.
• #1440 The WebSharper C# analyzer is included again in the WebSharper.CSharp package, showing WebSharper translation errors and warnings live in the IDE for C# projects.

Fixes

• #1607 wsfsc "Global error" messages now include the stack trace of the original exception, not only the compiler's worker-thread wrapper.
• wsfsc no longer fails with exit code 1 and no message when the F# compiler fails with an exception but no error diagnostics, or when only the type check for WebSharper translation reports errors.
• #1440 The WebSharper C# analyzer works again in Visual Studio:
  • It no longer turns itself off on first use. It detects command line builds (csc, VBCSCompiler), where the WebSharper compiler reports the same diagnostics, by the process instead of a compilation action, which Roslyn also runs for single-document IDE analysis.
  • Macros from referenced assemblies run again in the .NET-hosted Roslyn analyzer process: references to WebSharper compiler assemblies resolve to the analyzer's own copies instead of loading a second WebSharper.Core. Referenced assemblies are loaded from bytes, so build outputs are not locked by the IDE.
  • Referenced C# projects passed by the IDE as in-memory compilations are translated for their WebSharper metadata.
  • Constructor macros that cannot run in the analyzer give a warning instead of an error, same as method macros.
  • WebSharper F# projects do not produce reference assemblies in design-time builds either, so IDEs reference their output assembly that contains WebSharper metadata, not a nonexistent obj/.../ref assembly.
  • Reference errors are shown on the analyzed file instead of skipping analysis silently, and cached reference metadata is refreshed when the referenced assembly is rebuilt.