GFlisch / Arc4u.Guidance.Doc

Other
5 stars 1 forks source link

(Guidance2022.2.1.14 - RC01) BUG: Blazor application refuses to start. #224

Closed vvdb-architecture closed 7 months ago

vvdb-architecture commented 8 months ago

The blazor application refuses to start.

The Visual Studio output message is:

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[7712] dotnet.exe' has exited with code 2147516566 (0x80008096).

The console window shows the following: image

The root cause is a versioning problem. Webassembly applications are very sensitive to this.

The project file now contains wildcard matches to Microsoft assemblies, which will load the latest versions: For example:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="8.*" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="8.*" PrivateAssets="all" />

The problem is that (at least for WebAssembly), the version must match the installed SDK. However, 8.* will match 8.0.1, which corresponds to SDK 8.0.101 released on January 9th 2024. The SDK installed on Development machines is the one installed with VS 2022 17.8.2, which is 8.0.100. Even when global.json contains "rollForward": "latestFeature", this has no effect since the SDK simply doesn't exist.

When running on a PC with the latest 8.0.1 updates, Blazor runs without problems.

The solution is to avoid wildcard versions for Blazor at all costs.

This will probably trigger "Consolidate" entries in the NuGet package manager, because other applications will still contain wildcard versions.

But it's probably a good idea to avoid them in non-blazor applications even though they are not that sensitive. For example, for NSwag, different minor versions are known to sometimes generate slightly different client code, which may or may not be what the developer wants.