Create a shared services library #235
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With the current layering, the FrameworkServices and CoreServices libraries have some shared source. This is fine for internal implementations, but for public types, this causes two types to exist. This is not an issue in the main case (i.e. in an application) as they will never depend on each other. However, the problem arises when a user wants to develop an implementation on a shared, public service that would then be consumed by both the framework services and core services. An example is the ISessionKeySerializer, that a user may want to customize for themselves, but the framework and core services have identical interfaces, but in different assemblies. These are logically the same service, and should therefore have the same identity (i.e. same assembly).
twsouthwick
force-pushed
the
tasou/create-services-package
branch
from
e864c4f to
f6ba6ab
Compare
mjrousos
approved these changes
Oct 26, 2022
Member
mjrousos
left a comment
mjrousos
left a comment
There was a problem hiding this comment.
LGTM except that I'm not entirely sold on the name. A couple other comments inline.
src/Services/Microsoft.AspNetCore.SystemWebAdapters.Services.csproj
Outdated
Show resolved
Hide resolved
Tratcher
reviewed
Oct 26, 2022
src/Services/Microsoft.AspNetCore.SystemWebAdapters.Services.csproj
Outdated
Show resolved
Hide resolved
Member
Author
|
Based on feedback, I've updated the package to be This also allows the abstractions to be .NET Standard 2.0 so libraries that extend the types should be even simpler to produce. |
Tratcher
reviewed
Oct 27, 2022
...mWebAdapters.FrameworkServices/SessionState/RemoteSession/RemoteAppSessionStateExtensions.cs
Show resolved
Hide resolved
Tratcher
approved these changes
Oct 27, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the current layering, the FrameworkServices and CoreServices libraries have some shared source. This is fine for internal implementations, but for public types, this causes two types to exist with the same name but different assemblies. This is not an issue in the main case (i.e. in an application) as they will never depend on each other.
However, the problem arises when a user wants to develop an implementation on a shared, public service that would then be consumed by both the framework services and core services. An example is the ISessionKeySerializer, that a user may want to customize for themselves, but the framework and core services have identical interfaces, but in different assemblies. These are logically the same service, and should therefore have the same identity (i.e. same assembly).