Incorrect framework in worker runtime config on publish

[VoidMonk]

Hi, I came across this strange issue when publishing StackExchange.Exceptional as part of a .NET Core Worker service, making it fail to run.

When a worker project references the StackExchange.Exceptional.AspNetCore package (as in docs), its published project.runtimeconfig.json file includes the framework name as Microsoft.AspNetCore.App instead of Microsoft.NETCore.App.

Actual error message when worker is run on a machine with .NET Core runtime (worker project shouldn't need the ASP.NET Core runtime):

It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=ubuntu.18.04-x64

Any idea why this happens, and how to fix it?

Environment:

• .NET Core 3.1 and SDK 3.1.100
• StackExchange.Exceptional v2.1.0 (latest)
• Tested on Windows 10 64bit and Ubuntu Server 18.04 64bit

Steps to reproduce:

1. Create new worker project:

   dotnet new sln
   dotnet new Worker -n MyWorker
   dotnet sln add MyWorker

2. Add the Exceptional package reference to the MyWorker.csproj project file:

   <ItemGroup>
   <PackageReference Include="StackExchange.Exceptional.AspNetCore" Version="2.1.0" />
   </ItemGroup>

3. Build and publish the project:

   dotnet build --configuration Release
   dotnet publish MyWorker -c Release -o publish\worker

4. Open the publish\worker\MyWorker.runtimeconfig.json file, which will show the incorrect framework name as Microsoft.AspNetCore.App:

   {
   "runtimeOptions": {
   "tfm": "netcoreapp3.1",
   "framework": {
     "name": "Microsoft.AspNetCore.App",
     "version": "3.1.0"
   }
   }
   }

Without the Exceptional package reference, the build and publish step generate a valid runtime config (with framework name as Microsoft.NETCore.App).

[NickCraver]

I'm not sure I understand the issue here - you're including the AspNetCore package - and it references the ASP.NET Core bits, that looks correct to me.

If you're only using shared pieces, you are free to reference only the StackExchange.Exceptional.Shared package if only needing the common bits - is that the confusion? Apologies if that's not helpful...I'm trying to understand what the issue is here.

Can you please elaborate on what should be happening if the above doesn't help?

[VoidMonk]

@NickCraver Thank you for your reply.

This isn't a ASP.NET Core project, but still referencing the StackExchange.Exceptional.AspNetCore package (as suggested in the docs), so maybe that's causing the confusion.

The problem is that a .NET Core Worker project, like a .NET Core Console app, that needs StackExchange.Exceptional through one package or another, should generate the framework name as Microsoft.NETCore.App in its published project.runtimeconfig.json file, instead of Microsoft.AspNetCore.App which causes the worker to fail when run.

I'll try using the StackExchange.Exceptional.Shared package instead.

[VoidMonk]

Tried using StackExchange.Exceptional.Shared package instead of StackExchange.Exceptional.AspNetCore in the Worker project, but then ExceptionalSettings is not available for configuration:

var exceptionalSettings = configuration.GetSection("Exceptional").Get<ExceptionalSettings>();
Exceptional.Configure(exceptionalSettings);

[NickCraver]

Ah, you can make your own - this is mostly around the Core/not split. For example:

public class ExceptionalSettings : ExceptionalSettingsBase { }

...since you're not actually adding any bits specific to ASP.NET Core.

[VoidMonk]

Cool, but Exceptional isn't available too, for Exceptional.Configure().

[VoidMonk]

Seems like Exceptional doesn't have a Configure method when using the StackExchange.Exceptional.Shared package. Any other way to use Exceptional in a .NET Core Worker project?

[VoidMonk]

Figured out a workaround, by using the StackExchange.Exceptional.Shared package, and creating a wrapper class for Exceptional based on StackExchange.Exceptional/src/StackExchange.Exceptional.AspNetCore/Exceptional.cs