WebSharper 4.2.5

This is a bugfix release for WebSharper 4.2 (core libraries and compiler only).

Templates for Visual Studio 2017: http://websharper.com/installers/WebSharper.4.2.5.223.vsix

Fixes

• #924 ASP.NET Core sites using .NET types that are proxied by WebSharper dlls that are not used directly (for example events, Linq extensions, some System.Collections.Generic and F# collections) are now correctly including the links to the .js files that are declaring those types.
• #923 F# functions with generic measures (having a parameter with type MyType<'T> where MyType is defined with MyType<[<Measure>] 'T>) compiles and works in client code without errors.

WebSharper 4.2.4

This is a bugfix release for WebSharper 4.2. See the associated WebSharper.UI release

Improvements

• #917 You can now use query expressions in client-side F# code.

Fixes

• #920 Libraries created with Interface Generator targeting .NET 4x are no longer referencing netstandard.dll. This also means that WebSharper binaries targeting .NET 4.6.1 are no longer depending on anything targeting .NET Standard.
• #919 C# analyzers for WebSharper errors and UI template code generation works as expected.
• F# templates for Visual Studio now use FSharp.Core from NuGet, and runs out of the box for Visual Studio 2017 Update 6.

WebSharper 4.2.3

This is the first stable release of WebSharper 4.2. See the associated WebSharper.UI release

Improvements

• #910 Improved command line parsing and help message for wsfsc.exe and zafircs.exe.

Fixes

• #895 Fix UserSession.Logout() on ASP.NET when a cookie domain is specified.
• #904 Fix exception when compiling a project that uses FSharp.Data.TypeProviders.SqlDataConnection
• #914 Fix invalid output code when using a generic type alias to a struct union
• #916 Fix compiling C# classes inheriting from System.Exception

WebSharper 4.2.2-beta

This is a bugfix release for WebSharper 4.2-beta.

Fixes

• #911 More System namespace numeric types handled correctly by Router.Infer (both for server and client-side usage): SByte, Byte, Int16, UInt16, UInt32, Int64, UInt64, Single.
• #906 Fix handling of F# type alias resolving to a type parameter (type Alias<'T> = 'T)
• #909 Compiling with WebSharper does not require installing .NET 4.7.1 anymore; 4.6.1 is now sufficient.

WebSharper 4.1.7

Fixes

• #911 More System namespace numeric types handled correctly by Router.Infer (both for server and client-side usage): SByte, Byte, Int16, UInt16, UInt32, Int64, UInt64, Single.
• #906 Fix handling of F# type alias resolving to a type parameter (type Alias<'T> = 'T)

WebSharper 4.2.1-beta

This is a bugfix release for WebSharper 4.2-beta.

Notice

Currently having the .NET 4.7.1 runtime installed is required to run the WebSharper compilers. We are exploring to run on only .NET 4.6.1, this is planned for stable 4.2 release.

Fixes

• #908 .pdb files are modified correctly when WebSharper writes resources to a .dll, restoring the ability to debug with breakpoints which was broken in 4.2.0-beta.
• #907 The custom JSON de/serialization methods are now available in WebSharper.TypedJson when using C#. (Previously there were multiple WebSharper.Json classes, causing an unresolveable ambiguity.) No breaking changes in F# code.

Templates

• dotnet-websharper/templates#10 .NET Core SPA templates write js/css output to the correct directory (wwwroot/Content).
• .vsix is now targeting only Visual Studio 2017, as WebSharper 4.2 relies on FSharp.Core 4.1 which is not supported in VS2015.
• Visual Studio templates correctly have minimum framework requirement of .NET 4.6.1

WebSharper 4.2-beta

Enhancements

.NET Standard and .NET Core support

This is the first version of WebSharper compiled for .NET Standard 2.0, and therefore compatible with .NET Core 2.0.

The compiler itself still runs on .NET Framework, due to the F# compiler's current limitations in particular when dealing with type providers. So having .NET 4.6.1 or Mono installed on development machine is still required; however the runtime is 100% .NET Standard 2.0 compatible.

ASP.NET Core support

WebSharper can now run on top of ASP.NET Core thanks to WebSharper.AspNetCore. The server-side runtime, including Sitelets as well as RPC functions, can be run on top of ASP.NET Core.

C# and F# dotnet project templates

Templates for .NET Core are now available for both C# and F#. They can be installed with the following command:

dotnet new -i WebSharper.Templates

There are four templates for each language (add -lang c# or -lang f# to choose):

• dotnet new websharper-web creates an ASP.NET Core application with a WebSharper client-server site.

• dotnet new websharper-spa creates an ASP.NET Core application containing a WebSharper Single-Page Application.

• dotnet new websharper-html creates a WebSharper-generated static HTML website.

• dotnet new websharper-lib creates a WebSharper library, compiling C# or F# code to JavaScript.

Build configuration via wsconfig.json file

If a wsconfig.json file is found next to a WebSharper project, build settings are read from it, overriding project variable setting if one exists in both places. Existing project variables all have equivalents: these are

• "Project": WebSharper project type
• "OutputDir": Output directory
• "DCE": dead code elimination on/off (shortened from WebSharperDeadCodeElimination)
• "SourceMap": source map generation on/off
• "WarnOnly": give WebSharper errors only as warnings (shortened from WebSharperErrorsAsWarnings)
• "DownloadResources": download all remote js/css resources for web projects.
• "AnalyzeClosures": give warnings on unintended captures in JS closures.

New settings:

• "JavaScript": emulate usage of JavaScript attribute on assembly level, allowing compiling full projects/files without annotating in source.
• "JSOutput"/"MinJSOutput": write out .js/.min.js to given location.

Changes

.NET 4.6.1

In parallel to the new .NET Standard 2.0, the minimum requirement for running WebSharper on the .NET Framework has been bumped to v4.6.1.

WebSharper 4.1.6

Fixes

• #897 F# module-level pattern matching with let now translates successfully. (For example: let a, b = 1, 2)
• #902 Sitelet.InferWithCustomErrors and Router.InferWithCustomErrors work as intended (previously was throwing a null exception).

WebSharper 4.1.5.205

Fixes

• #894: in BundleOnly mode, do still output a dummy empty DLL to avoid trouble with outside tools (like MSBuild) that expect it as output.

WebSharper 4.1.5

Enhancements

• #891 Bundle project output is now generated quicker.
• #891 Also, if you have source mapping turned off (as default) and dead code elimination too (with <WebSharperDeadCodeElimination>False</WebSharperDeadCodeElimination>) then bundling will just concatenate already compiled JavaScript output for referenced assemblies instead of rewriting to a single scope, resulting in faster compilation speed.
• #892 You can use the new project type value <WebSharperProject>BundleOnly</WebSharperProject> to have only the .js/.css/.html output for bundle projects. In the case of F#, this means that no .dll is created. For C#, the .dll is just not touched, it will contain no WebSharper-specific resources. This allows faster iterative development on bundle projects. Most time is gained if that project itself (and not just references) contain large amount of code.