FS2030 Invalid use of emitting a reference assembly : when compiling with VS 2022, .NET 7, F# 7

[BentTranberg]

I get this error when I try to compile with VS 2022 Preview latest just installed, .NET 7 and F# 7. It happens in all my Bolero client projects, including latest version of Bolero.

FS2030 Invalid use of emitting a reference assembly, do not use '--staticlink', or '--refonly' and '--refout' together.

[BentTranberg]

I inserted this - the second line - in the project file, and then the project compiles without errors. I do not know what this setting is doing.

    <TargetFramework>net7.0</TargetFramework>
    <ProduceReferenceAssembly>false</ProduceReferenceAssembly>

Then I ran the project. A blank page appeared, and the application logged only info entries in the console. I do not know what this next issue is. I did not go through and read the logging line by line. I'm out of time for now.

I assume the default demo project of Bolero will show the same problem - a blank page.

[BentTranberg]

EDIT: Sorry, if you see the original text of this, ignore it. I made a mistake while testing.

The problem also exists in VS 2022 v 17.4.0 which was just made available to me, with F# and .NET 7.

Updating to F# 7 works just fine, and doesn't require anything except removing any explicit references to old FSharp.Core

Updating to net7.0 framework makes all Bolero projects show just a blank page when run, and again this is after using <ProduceReferenceAssembly>false</ProduceReferenceAssembly> to make them compile, as initially explained. I'm thinking that perhaps using that setting is the wrong fix.

[baronfel]

Updating to net 7.0 causes the F sharp compiler to start emitting reference assemblies, which are a new feature. Maybe some of the bolero tooling doesn't understand reference assemblies yet?

[BentTranberg]

I'm testing to get closer to a solution to this problem.

I made sure to download the latest Bolero template just now. Then I created a solution containing the Bolero starter project from that.

I installed the latest VS 2022 Preview that was made available today. It's version 17.5.0 Preview 1.0

I was able to compile and run the project with no errors and no warnings.

Then I changed the target from net6.0 to net7.0, and got these errors and warnings. (picture)

So again FS2030 Invalid use of emitting a reference assembly, do not use '--staticlink', or '--refonly' and '--refout' together.

And again I added the ProduceReferenceAssembly setting to the client's project file. Notice that it is false and not true.

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <ProduceReferenceAssembly>false</ProduceReferenceAssembly>

This seems to work somehow. However, I still don't see what should have appeared. On the other hand, it's not a blank page. Here's another screenshot.

I now very strongly suspect that I didn't notice in my earlier testing that indeed there was something on that page - it wasn't blank. I further suspect that we're dealing with two issues, one of which is resolved through the use of the setting in the project file, and the other is something else - missing stuff on the page - that needs research.

Finally I deleted the .vs, bin and obj folders, and loaded the solution into the latest VS 2022 release version, which I also received and installed today. It is version 17.4.0. The results are the same, but I used the Firefox browser this time.

[vzarytovskii]

Updating to net 7.0 causes the F sharp compiler to start emitting reference assemblies, which are a new feature. Maybe some of the bolero tooling doesn't understand reference assemblies yet?

Refassemblies don't work with static linking. By design. And static linking is implicit in case of type providers.

[BentTranberg]

I set breakpoints in the client project, and they are hit. In particular, fetching the home page happens. Makes me think this second issue is a simple issue to fix. But I am so much not an expert here - I'd waste a lot of my time just learning for no good reason - so I prefer leaving the rest to somebody else.

[Tarmil]

For the reference assembly issue, I can reproduce it and confirm that setting the MSBuild property ProduceReferenceAssembly to false fixes it. I could add that to the .targets file in Bolero.Build, that should fix the issue for everyone.

I can't reproduce the blank page issue however; I upgraded https://github.com/fsbolero/TodoMVC to net7.0, added ProduceReferenceAssembly, and it is running correctly. Maybe there's some specific F# code in your project that it doesn't like, you can try to remove bits to narrow it down.

[r-dahlstedt-linux-guy]

I similarly have been having an issue trying to start using Bolero with .NET 7.0 for which the following is the error I first received when attempting to run the HelloWorld.Server for the first time:

PS C:\Users\rdahlste\projects\HelloWorld> dotnet run --project .\src\HelloWorld.Server
C:\Program Files\dotnet\sdk\7.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(238,5): error N
ETSDK1032: The RuntimeIdentifier platform 'browser-wasm' and the PlatformTarget 'x64' must be compatible. [C:\Users\rdahlste\projec
ts\HelloWorld\src\HelloWorld.Client\HelloWorld.Client.fsproj]

The build failed. Fix the build errors and run again.

I tried finding a solution to that but came up blank. Alternatively I figured that perhaps setting the PlatformTarget=browser-wasm would do the trick for which along with that I changed the net6.0 references to net7.0 and got the exact same issue of the above error message. If you put back the net6.0 and re-install a .NET 6.0 runtime (if you were as stupid as I was in removing the now older runtime) and still add a PlatformTarget=browser-wasm it finally builds and runs populating all the needed content when you nagivate to the proper URL:

PS C:\Users\rdahlste\projects\HelloWorld> dotnet run --property PlatformTarget=browser-wasm --project .\src\HelloWorld.Server
info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[63]
User profile is available. Using 'C:\Users\rdahlste\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
Hosting environment: Production
Content root path: C:\Users\rdahlste\projects\HelloWorld\src\HelloWorld.Server
Now listening on: http://localhost:5000
Now listening on: https://localhost:5001
Application started. Press Ctrl+C to shut down.
...

Not sure precisely what is going on but as a workaround that seems to do the trick.

[BentTranberg]

@r-dahlstedt-linux-guy, what does this has to do with the issue I have reported?

[BentTranberg]

Here I'm uploading the source of the HelloWorld Bolero application made straight from the Bolero template and updated to net7.0. I have removed folders .vs, bin and obj before zipping, so there should be no binaries.

HelloWorld.zip

I can zip with binaries if it helps to study the compiler output.

I will try the TodoMVC, and report back. Will also have a closer look at the binaries of HelloWorld myself, to see if perhaps there's something too old in there.

[r-dahlstedt-linux-guy]

The error you started the issue with relates to using net7.0 as the target framework. If you simply revert the target framework back to net6.0 (which is the default when creating a new Bolero project) using the .NET 7.0 toolchain as well as the .NET 6.0 runtime it works just as it always did under .NET 6.0.
The desire to generate or not generate a reference assembly by default only seems to be an issue if the target framework is net7.0. Whether this is a nuance of using .NET 7.0 or something needs to be changed in Bolero is more capably handled by others but if either yourself or others want to use .NET 7.0 it can be used but you likely should not yet target the .NET 7.0 runtime for Bolero even if the TodoMVC might work as something may not work precisely the way it had.

[BentTranberg]

I have learned that type providers cause reference assemblies to be produced. I started a discussion in F# Slack where this was brought up. There isn't anything technical there to add here. Anyway, the only remaining problem now is why I can't see content in the page. That's actually a different issue, I'm reasonably sure, and should perhaps be added in this repo, but I have hopes we'll figure it out really quickly now anyway.

[BentTranberg]

I discovered something that perhaps narrows it down a bit, and is also helpful for me in a workaround solution. In the HelloWorld solution I uploaded, I can update the server to net7.0, while leaving the client on net6.0, and then it runs successfully and shows the entire page, and not just the contents from what appears to be the Index.fs in the server project.

The TodoMVC also ran successfully from VS on my machine.

[BentTranberg]

Just to recap, the server in HelloWorld can run at net7.0, but the client must remain on net6.0 for the client's part of the page data to be displayed. In the client, this breakpoint is hit:

So what about the logs? When the client uses net6.0, there are more things happening at the end of the logging when opening the page in a browser. Using the http port, not https.

lognet7b.txt
lognet6b.txt

I hope these logs give a good clue as to what's wrong, but this is quite far beyond my current level of competence in this area. And I'm done for the day.

[BentTranberg]

I did some more research, and created a new issue for the remaining second ... issue! Follow the link right above this post.

@Tarmil, perhaps you want to keep this open, as a reminder for the possible changes you mentioned? I'll leave it to you to close this whenever appropriate.

[ZeroBomb]

I was able to get the page to render correctly with both the client and server targeting net7.0 by using

<ProduceReferenceAssembly>false</ProduceReferenceAssembly>

Then using dotnet to update the project's packages:

dotnet add .\YourAppName.Client\ package FSharp.SystemTextJson --version 1.0.*
dotnet add .\YourAppName.Client\ package Microsoft.AspNetCore.Components.WebAssembly.DevServer --version 7.0.*
dotnet add .\YourAppName.Client\ package microsoft.aspnetcore.components.webassembly --version 7.0.*

Afterwards, my package references looked like:

   [net7.0]:
   Top-level Package                                            Requested   Resolved
   > Bolero                                                     0.*         0.20.18
   > Bolero.Build                                               0.*         0.20.18
   > Bolero.HotReload                                           0.*         0.20.4
   > FSharp.Core                                                7.0.0       7.0.0
   > FSharp.SystemTextJson                                      1.0.*       1.0.7
   > microsoft.aspnetcore.components.webassembly                7.0.*       7.0.0
   > Microsoft.AspNetCore.Components.WebAssembly.DevServer      7.0.*       7.0.0

[BentTranberg]

It finally works on my machines too. Not sure if I made a mistake while testing or if something else changed. But there's still some other Microsoft.AspNetCore.* libraries on 6.* rather than 7. I guess I have to reference them explicitly for now, or perhaps learn something about the NuGet stuff in VS. I don't want to use Paket.

[Tarmil]

The ProduceReferenceAssembly fix is released in v0.21.

[xperiandri]

@Tarmil but I still see it is disabled in 0.23

Can we remove <ProduceReferenceAssembly>false</ProduceReferenceAssembly> for .NET 8?

[xperiandri]

@Tarmil ping

[xperiandri]

@Tarmil this is very important for build time. Can that setting be removed?

[Tarmil]

Based on local tests, it does seem like we can get rid of this now, yes. PR coming up

[xperiandri]

@Tarmil will you release that?

[xperiandri]

@Tarmil can you release the new version of Bolero.Build?

[Tarmil]

It is published as v0.24-beta.