Remove support for ASP.NET Core on full framework in AspNetCoreToOpenApiGenerator

[lahma]

ASP.NET Core hasn't been supported with full framework for a long time and currently causes dependency to ancient and vulnerable ASP.NET Core 2.2 hosting bundle. HostApplication type can now conditionally compiled when !NETFRAMEWORK.

[Numpsy]

Refs #2824 I think (Mend thinks the current v14 preview suffers from https://www.mend.io/vulnerability-database/CVE-2019-1075, whicn alas creates noise whether it actually does or not)

[paulomorgado]

From .NET and .NET Core Support Policy:

ASP.NET Core 2.1 on .NET Framework

Support for ASP.NET Core 2.1 on .NET Framework matches the ASP.NET Support policy for other package-based ASP.NET frameworks. The complete list of packages covered by this policy can be seen in ASP.NET Core 2.1 Supported Packages.

ASP.NET Core 2.1 on supported versions of .NET Framework is supported, but ASP.NET Core 2.2 isn't.

Neither is .NET Core 2.1 runtime.

[olegd-superoffice]

I actually use NSwag with Asp.Net Core 2.1 application on .Net Framework 4 which is a combination supported by Microsoft and will be supported for long time. This problem needs to be solved in a different way, by referencing supported versions of packages instead of deprecated ones.

[Numpsy]

I actually use NSwag with Asp.Net Core 2.1 application on .Net Framework 4 which is a combination supported by Microsoft and will be supported for long time. This problem needs to be solved in a different way, by referencing supported versions of packages instead of deprecated ones.

Are we talking about the server side or a client side?

The security complaints we see are about NSwag.MSBuild being used to generate clients (which have nothing to do with ASP of any flavour) from an openapi spec, not from NSwag.AspNetCore which is used on the server to generate said specifications.

[olegd-superoffice]

Are we talking about the server side or a client side?

Both. And both are supported by Microsoft. This pull request just removes support for .Net Framework instead of fixing it.
And NSwag.MSBuild does depend on some of Microsoft.AspNetCore packages. Look, for example, into tools/Net80 folder.

[paulomorgado]

I actually use NSwag with Asp.Net Core 2.1 application on .Net Framework 4 which is a combination supported by Microsoft and will be supported for long time. This problem needs to be solved in a different way, by referencing supported versions of packages instead of deprecated ones.

Are we talking about the server side or a client side?

The security complaints we see are about NSwag.MSBuild being used to generate clients (which have nothing to do with ASP of any flavour) from an openapi spec, not from NSwag.AspNetCore which is used on the server to generate said specifications.

@Numpsy, what security concerns are those? Are there any issues open on that?

[olegd-superoffice]

#4561 should fix CVE-2019-1075 without removing support for .Net Framework.

[Numpsy]

@Numpsy, what security concerns are those? Are there any issues open on that?

#2824

[Numpsy]

#4561 should fix CVE-2019-1075 without removing support for .Net Framework.

yeah, but those were only updated in 1eae91f and that fixed a couple of other security warnings.

There are newer versions of some of the lower level libs about though, so maybe updating those as well would avoid the complaints.

[RicoSuter]

I'd like to keep the support and fix the problems in a different way...

[lahma]

I'm cool with that 👍🏻