New ASP.NET Core MVC/Razor-based Web Application Mercury build errors

Creating a new ASP.NET Core MVC/Razor-based Web Application for Mercury using Fire, if I then try to build the project without any changes, I get several build errors which frankly baffle me because I don’t see anything wrong. For example, I see errors “semicolon expected”, but there is already a semicolon. Weird.

Here’s a created project, to see if this is something specific to my environment, which is definitely a possibility.
CPAIWebClient (1.3 MB)

This is Fire version, but I did see it on an earlier version (I’m not sure which one), so I updated in case that would fix it.

It is likely I have something wrong or missing here, but what could it be?


Hmm., this fails here with

E:                   The `Microsoft.AspNetCore.Mvc.Razor.Extensions.dll` library was not found as expected in '/usr/local/share/dotnet/sdk/9.0.100-preview.3.24204.13/Sdks/Microsoft.NET.Sdk.Razor'

I dot really have the tome today to investigate that one, but can you share an example what the code files that have the “expression expected” look like?

I’m wondering of latest Razor generates some C#11/12 syntax we don’t support yet…

Nevermind, it does work for 8.0, just not 9.0 – I guess Microsoft moved shit around again; I;'ll log an issue.

it fails on

    using global::System;
    using global::System.Collections.Generic;

which is new C#, but it thought we have support for already; I’ll check with the team.

.NET Core 6 doesnt seem to generate this syntax, and builds fine; 7.0 and 8.0 fail on global using (and 9.0 fails on the missing Razor .dll)

Logged as bugs://E26954. – .NET 9

Logged as bugs://E26955. – .NET ⅞ global using

Thanks, Marc! I wondered if it was something like that. Unfortunately for me, I’m trying to learn too many new (to me) things at once: ASP.NET Core + MacOS + Elements, so I don’t easily recognize what is going on. Thanks for logging the bug.


Oddly, this seems to not be a new C# feature, just a corner-case syntax we must have missed I(the recent changes to using are all unrelated to this). It kind makes sense that global:: would be supported here.