Add Seq client Integration into an app with NSwag breaks the app.

[johnkattenhorn]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I'm still investigating this but I thought I'd post to raise awareness that if you add SEQ Aspire integration to an application configured to use NSwag, you can get a compile error from the NSwag built task after adding the client integration.

Nothing reported on the NSwag Issues backlog

Expected Behavior

Adding Aspire.Seq to a Aspire with a ASP.NET Core WebApi and NSwag should compile without errors.

Steps To Reproduce

Generate a sample application using Jason Taylors Clean Archecture Template (https://github.com/jasontaylordev/CleanArchitecture) configured for Aspire.

Build and Run - Everything is working.

Add Aspire.Seq.Hosting to HostApp and Config Seq Host - Everything is working.
Add Aspire.Seq to Web Project (Api) - using builder.AddSeqEndpoint

Build throws an exception generated by NSwag

Exceptions (if any)

System.InvalidOperationException: NSwag requires the assembly TestApp.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null to have either an BuildWebHost or CreateWebHostBuilder/CreateHostBuilder method

.NET Version info

.NET SDK:
Version: 9.0.102
Commit: cb83cd4923
Workload version: 9.0.100-manifests.4a54b1a6
MSBuild version: 17.12.18+ed8c6aec5

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.102\

.NET workloads installed:
[maccatalyst]
Installation Source: VS 17.12.35707.178
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.1.9163\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: VS 17.12.35707.178
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.1.9163\WorkloadManifest.json
Install Type: Msi

[android]
Installation Source: VS 17.12.35707.178
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: VS 17.12.35707.178
Manifest Version: 9.0.14/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.14\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.1
Architecture: x64
Commit: c8acea2262

.NET SDKs installed:
8.0.403 [C:\Program Files\dotnet\sdk]
9.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Anything else?

No response

[johnkattenhorn]

Quick Update:

I've pulled the source code for Aspire.Seq into the code base, if I comment out these lines:

 if (!settings.DisableHealthChecks)
 {
     if (settings.ServerUrl is not null)
     {
         builder.TryAddHealthCheck(new HealthCheckRegistration(
             "Seq",
             _ => new SeqHealthCheck(settings.ServerUrl),
             failureStatus: default,
             tags: default));
     }
     else
     {
     //    throw new InvalidOperationException(
     //        "Unable to add a Seq health check because the 'ServerUrl' setting is missing.");
     }
 }

I don't see why the assembly scanner for NSwag would object to this so I'm going to log an issue over there and see what they say.

Does anyone else see why this code in Aspire.Seq would upset the NSwag build task ?

[johnkattenhorn]

OK another quick update, if I add the following to appsettings.config and uncomment the code then it builds ok, so I'm concluding the NSWAG task is executing the code and hitting the exception:

I'm not keen on setting the Seq Server URL this way, it would be good to get views from others about what we should do here ? I least for now I have a workaround.

  "Aspire": {
    "Seq": {
      "ServerUrl": "http://localhost:5341"
    }
  }

[johnkattenhorn]

This goes deeper than SEQ, because NSwag is running the code from the builder its also trying to connect to the db (which get's it's connection string at runtime) etc.

I've looked through the NSwag documentation and I can't find anything that deals with configuration being set at runtime. I've logged an issue over on NSwag too (RicoSuter/NSwag#5100)

[davidfowl]

This makes sense. This is the same problem that the dotnet-ef tool runs into when you run it where a connection string is required. We go around this by deferring failures until as late as possible. If the application boots up and throws eagerly if the configuration is missing then this class of tool breaks.