-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
API Review for System.Web adapters (Part 2): General Usage #42091
Comments
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
|
API review notes:
I'll try to edit this with the final reviewed API shape and mark it api-approved later today. |
More API review notes:
|
Thanks for contacting us. We're moving this issue to the |
API Review Notes:
|
We also thought that adding data annotations to the options and adding validation to it is unusual for library code. Normally we just validate in the constructors of services taking the options. Maybe this allows for better errors though. We should double check options in the ctor either way. |
Thanks for responding to the feedback. I'm going to copy the proposed API at this point in time for easier tracking of any potential future updates.
I think this looks good. @Tratcher Do you agree? If so, I think we can mark this approved. @dotnet/aspnet-api-review |
Given that there has been no more feedback in the last two days, I'm labeling this |
This is no longer relevant as it was for 1.0 release of system.web adapters. |
Background and Motivation
We've been developing some adapters to help with migrating from ASP.NET Framework that adapter the
System.Web.HttpContext
to theMicrosoft.AspNetCore.Http.HttpContext
. We've released Preview 1 and would like to review the API shape.This issue focuses on the APIs that will be used on the ASP.NET Core/ASP.NET Framework applications to add functionality in.
Related API Designs:
Proposed API (ASP.NET Core)
Package: Microsoft.AspNetCore.SystemWebAdapters.CoreServices
Usage Examples:
Scenario: Using remote app for auth and session
Scenario: Using built-in session manager behind
System.Web.HttpContext.Session
Proposed API (ASP.NET Framework)
On ASP.NET Framework, we insert a single module (
SystemWebAdaptersModule
) that then will load additional modules if required. This is done in a fluent syntax that tries to mimic the setup of ASP.NET Core. Users can register their ownIHttpModule
types that will be run (in order of registration) bySystemWebAdaptersModule
.Package: Microsoft.AspNetCore.SystemWebAdapters.FrameworkServices
Usage Examples:
Scenario: Set up remote app for session and auth. Also configures support for proxy headers
Alternative Designs
Client
/Server
for the ASP.NET Core application and the ASP.NET Framework application was the best we could come up with. However, it doesn't quite feel right, and we've had feedback that it's confusing since they're both servers. We're consistent at this point in what we've named them, just want to settle on the correct termsISessionKeySerializer
act onbyte[]
or onIMemory<byte>
?The text was updated successfully, but these errors were encountered: