Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSharper AspNetCore on net462 -- works with 4.2.x, fails with 4.4.x #1001

Closed
nightroman opened this Issue Aug 4, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@nightroman
Copy link

nightroman commented Aug 4, 2018

WebSharper AspNetCore on net462 -- works with 4.2.x, fails with 4.4.x

Create the folder WSAspNetCore462 and change to it.
Create the project from the WebSharper template:

dotnet new websharper-web -lang f#

In the created WSAspNetCore462.fsproj, remove all package references and change the target framework to net462:

<TargetFramework>net462</TargetFramework>

Copy attached paket.dependencies and paket.references to the project folder.
paket-dep-ref.zip

Note that in paket.dependencies WebSharper packages are pinned to 4.2.x

nuget WebSharper 4.2.14.264
nuget WebSharper.FSharp 4.2.14.264
nuget WebSharper.UI 4.2.6.119
nuget WebSharper.AspNetCore 4.2.3.63

Assuming paket is in the path, invoke

paket install
paket restore
dotnet run

As a result, the app is built and run successfully.

Now delete the file paket.lock and unpin the WebSharper packages in paket.dependencies:

nuget WebSharper
nuget WebSharper.FSharp
nuget WebSharper.UI
nuget WebSharper.AspNetCore

and restore/run again:

paket install
paket restore
dotnet run

As a result, the app is built but it fails to start:

crit: Microsoft.AspNetCore.Hosting.Internal.WebHost[6]
      Application startup exception
System.IO.FileLoadException: Could not load file or assembly 'WebSharper.Sitelets, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies
. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
File name: 'WebSharper.Sitelets, Version=4.4.0.0, Culture=neutral, PublicKeyToken=null'
   at WSAspNetCore462.Startup.Configure(IApplicationBuilder app, IHostingEnvironment env)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
@Tarmil

This comment has been minimized.

Copy link
Member

Tarmil commented Aug 6, 2018

Right, I see the issue.

The base problem is this: we use Mono.Cecil to write the compiled JavaScript into assemblies as embedded files. However, Cecil doesn't support creating strongly-named assemblies when it runs on .NET Core (regardless of the created assembly's own target framework). Since we compile the core libraries for .NET Framework with the .NET Framework compiler and the core libraries for .NET Standard with the .NET Core compiler, I decided to leave the core libraries for .NET Standard not strongly named. But as you found out, it causes problems with WebSharper.AspNetCore: it is only compiled for .NET Standard, so even if your application is .NET Framework, it still tries to reference non-strongly-named core libraries.

There are two possible fixes: either also compile WebSharper.AspNetCore for .NET Framework, or compile the core libraries for .NET Standard with the .NET Framework compiler so that they can also be strongly-named. I think the latter is the best solution, as it will avoid subsequent similar issues too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.