Uncaught SyntaxError: import.meta may only appear in a module

[BentTranberg]

When a server-client project created from the Bolero template (latest) is updated from net6.0 to net7.0, the following error appears in browsers. The Bolero page is also blank, except for the dark Bulma bar with logo at the top which is served by the server-side early, I believe before WebAssembly kicks in.

Firefox:
Uncaught SyntaxError: import.meta may only appear in a module
source: dotnet.7.0.0.amub20uvka.js

Chrome and Edge:
Uncaught SyntaxError: Cannot use 'import.meta' outside a module
source: some other js-file with a cryptic name

It's actually the same error, just with slightly different wording, and Firefox is also kind enough to hint about the platform version, which is important here.

How to reproduce:

Run the following web application generated with the latest Bolero template in Visual Studio 17.4.0, currently latest. Also fails in latest Preview version.

HelloWorld.zip

Note that the page is blank, except for the dark Bulma bar with logo at the top.

In a Firefox browser, inspect the page errors using the browser's developer tools. Note that the name of the failing file indicates this is dotnet7.0.0

To verify that it works with net6.0, change the target in the client to net6.0. That's all that is needed for success, though the Microsoft assembly can also be downgraded for good measure. Now run with Firefox again, and note that now there is a javascript file name containing dotnet6.0.11, or whichever version of 6.0.x is on the machine.

Observed on two out of two developer machines so far.

This is a continuation of the problem solving in #279, related to updating to .NET 7. This is a second issue. The first issue was resolved through the use of ProduceReferenceAssembly with value false in client project files.

Additional information. These two log files are the outputs from the console when running net6 and net7. I am not much of an expert here, but I'm guessing there's not much to gain from studying these, except that net7 doesn't deliver the missing content.

lognet7b.txt
lognet6b.txt

Of course you can test with browsers other than Firefox, but you'll miss the nice version indication in the WebAssembly javascript filename.

[Tarmil]

In this issue, they seem to have fixed their issue by updating NuGet packages. Checking the project in your archive, it seems indeed that Microsoft.AspNetCore.Components.WebAssembly v6.0.0 is still being referenced instead of v7.0.0. I got the project running by explicitly upgrading it in Client.fsproj:

        <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.0" />

It's quite annoying to have to do that explicitly though. I think it'll be better if I add the above line in the project template when I upgrade it to net7.0 (I'd rather not raise the requirement in the Bolero package itself).

[BentTranberg]

Thank you. That finally solves it. Strange I didn't connect things, though I've been thinking about checking the assembly versions next.

I thought the system - dotnet that is - was better than this, in this area. I know there are shortcomings, but I can see now that most of AspNetCore assemblies are not version 7.0.0! I need a lot of explicit references for that. But System.* seems to be ok. I noticed yesterday that HtmlAgilityPack.dll is not the latest. Possibly also not FSharp.SystemTextJson.dll.

Maybe I need to consider using Paket after all, even though I feel it's such an incredible hassle.

[Bananas-Are-Yellow]

There is one more thing to note. The sample produces this for the client project file:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.*" />

If you just change 6.0.* to be 7.0.* the problem still occurs. It seems that you also have to remove the .DevServer piece.

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.*" />

Then it works.

[Tarmil]

That's odd, in my attempt on the TodoMVC project, I updated DevServer to 7.0.0 and it worked.

[BentTranberg]

@Bananas-Are-Yellow, I don't understand your point.

If you "remove the .DevServer piece", you are no longer referencing Microsoft.AspNetCore.Components.WebAssembly.DevServer, but instead referencing Microsoft.AspNetCore.Components.WebAssembly, version 7.0.0, and that's exactly the solution @Tarmil suggested.

But the Microsoft.AspNetCore.Components.WebAssembly.DevServer is no longer brought in. The application still runs successfully, but I guess there's a reason the DevServer should be there.

[BentTranberg]

Hmm... maybe I'm beginning to understand your point. I don't see a *.DevServer.dll when trying to get it back. Perhaps it's just a namespace in *.WebAssembly.dll ? Sorry, don't have time to figure this out now, but just thought I'd let you know how this ended here.

[Bananas-Are-Yellow]

It seems that a package reference to Microsoft.AspNetCore.Components.WebAssembly is required to fix the import.data error in the browser console.

It also seems that Microsoft.AspNetCore.Components.WebAssembly.DevServer is not required for the HelloWorld client project (or for my own project), but it might be that it is required for certain server options that I do not have set.

So my conclusion is that both references should be present in the client project file.

(Remember to do a dotnet clean if you remove a package reference, otherwise, it is still present in the output folder, or at least that seems to be the case for me.)

[Tarmil]

DevServer isn't actually a package that adds any dll references; it contains msbuild scripting to run a client project directly with dotnet run. So you don't need it if you have a server project. Maybe we should make its inclusion in the project template conditional, and only add it with --server=false.

[Tarmil]

There is now an explicit reference to Microsoft.AspNetCore.Components.WebAssembly 7.0.* in v0.21 of the project template.

[Bananas-Are-Yellow]

If I remove the explicit reference

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="7.0.*" />

from the client project file, then the problem import.meta may only appear in a module is still there. Do I need to do something else?

[Tarmil]

Actually, I realize that I could make the dependency on Components.WebAssembly change based on the framework in the Bolero package itself. That would make things simpler than having to keep the right version in the project file.

[Tarmil]

Bolero 0.21.25 should now be working without an explicit dependency on Microsoft.AspNetCore.Components.WebAssembly.

[Bananas-Are-Yellow]

Works now.
Thanks.