-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Consider making more types internal #2805
Comments
This was referenced Apr 16, 2024
This issue is stale because it has been open for 60 days with no activity. It will be automatically closed in 14 days if no further updates are made. |
You can also specify InternalsVisibleTo inside the .csproj file which doesn't require any funny business with assemblies: <ItemGroup>
<InternalsVisibleTo Include='Swashbuckle.AspNetCore.SomeTestProject' />
</ItemGroup |
Good point, we do that here already: Lines 14 to 17 in 28128eb
|
martincostello
added
the
version-major
A change suitable for release in a major version
label
Sep 30, 2024
martincostello
added a commit
that referenced
this issue
Sep 30, 2024
Make all the middleware classes internal as they have no useful public-facing functionality (e.g. virtual members). Resolves #2805.
Merged
martincostello
added a commit
that referenced
this issue
Oct 9, 2024
Make all the middleware classes internal as they have no useful public-facing functionality (e.g. virtual members). Resolves #2805.
martincostello
added a commit
that referenced
this issue
Oct 15, 2024
Make all the middleware classes internal as they have no useful public-facing functionality (e.g. virtual members). Resolves #2805.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Review the public API and see if there's any types that are public that don't need to be, such as
SwaggerMiddleware
. That gives us more agility to change implementation details, like adding new constructor overloads (see #2801).It may be that some types don't need to be public and are only done so through oversight or to be accessible to unit tests. In the case of tests, it might be too tricky to do with the way that some assemblies are strong named and others aren't, as
[InternalsVisibleTo]
requires IVT'd assemblies to also be strong named, and all dependencies of a project need to be strong named for it to be, which creates issues where a test project depends on one project that is signed and another that isn't.Context: #2418 (comment)
The text was updated successfully, but these errors were encountered: