-
-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish for multiple targets #380
Comments
@Regenhardt .NET5.0 is out of service and the library dropped support for the .NET Framework in the 3.0 release cycle. Since since, the library has utilized many features to improve the security, performance, and maintainability of the codebase from .NET CORE (.NET). Are there any specific files reference .NET Framework? These should be removed or updated. |
fido2.targets seems to only exist to tell netstandard users that the lib doesn't work with net46x, as is this doc: https://github.com/passwordless-lib/fido2-net-lib/blob/master/Documentation/NET46X.md . Should i make a PR deleting those two files then? |
Also what about adding net7 to the targets to get those new source generation features for people already using net7? |
@Regenhardt @iamcarbon I assume you have an issue with the I note this issue dotnet/runtime#81709 refers specifically to a comment that "Contexts generated using the v6 source generator are not compatible with contract customization" as per Whilst there appears to be work arounds if you are dealing with the serialization inline, if we want to plug into the middleware, this seem problematic. I've tried combinedResolver = JsonTypeInfoResolver.Combine(FidoSerializerContext.Default, MySerializerContext.Default );
builder.Services
.Configure<Microsoft.AspNetCore.Http.Json.JsonOptions>(options =>
{
options.SerializerOptions.TypeInfoResolver = combinedResolver;
})
... and get the following error:
I've also tried to add the Fido lib types into my local serialization context but get the following error:
As you suggest to would be great if the maintainers could add |
FYI my current workaround, per above, is to change the Whilst this is not ideal (and not AoT'able) - it can provide a stop-gap 'til var combinedResolver = JsonTypeInfoResolver.Combine(MySerializationContext.Default, new DefaultJsonTypeInfoResolver());
builder.Services.ConfigureHttpJsonOptions(options =>
{
options.SerializerOptions.TypeInfoResolver = combinedResolver;
}) |
When the frontend lib is merged, it includes a serializer context that works in a net7 frontend too. I just tried setting the applications (Blazor server + client) to net7 keeping the libs at net6 and it worked without any other modifications. You can see the frontend serializer used here, initialized in line 18 and used e.g. in line 78. |
@Regenhardt - per this reply #371 (comment) we're using the nugget packages not project references! |
Currently,
$SupportedTargetFrameworks
only contains net6.0 - some other files do however contain logic that points to this libs having been available for other framework version too, like net5 or net472 (there are checks failing the build for net46x).So to offer this lib for older applications but also be able to use compiler features of newer versions like source generation (see e.g. dotnet/runtime#81709), can we add other targets to the
$SupportedTargetFrameworks
, or would that jeopardize other features?The text was updated successfully, but these errors were encountered: