Skip to content

Introduce IBindableFromHttpContext<TSelf> #41100

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

Merged
merged 13 commits into from
Jun 10, 2022

Conversation

DamianEdwards
Copy link
Member

@DamianEdwards DamianEdwards commented Apr 8, 2022

Introduces the new IBindableFromHttpContext<TSelf> where TSelf : IBindableFromHttpContext<TSelf> interface that defines a static abstract BindAsync method.

Fixes #40927

@DamianEdwards
Copy link
Member Author

@jmarolf after updating to Microsoft.CodeAnalysis.PublicApiAnalyzers 3.3.3 (from 3.3.0) we're getting a lot of new errors for existing APIs. Is this expected for a patch-level update?

@Pilchie Pilchie added the old-area-web-frameworks-do-not-use *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels label Apr 8, 2022
@DamianEdwards DamianEdwards force-pushed the damianedwards/ibindablefromhttpcontext branch from 29ddebf to 77bc86e Compare April 8, 2022 17:01
@jmarolf
Copy link
Contributor

jmarolf commented Apr 8, 2022

@jmarolf after updating to Microsoft.CodeAnalysis.PublicApiAnalyzers 3.3.3 (from 3.3.0) we're getting a lot of new errors for existing APIs. Is this expected for a patch-level update?

whoops responded to you privately but should have just done so here. The change you are seeing was originally made in this PR six years ago: dotnet/roslyn-analyzers#984. At the time we considered this a bugfix on the grounds of "There are public APIs that we are not tracking that we need to track". We have taken a similar approach with the SDK analyzers in that bugfix releases are allowed to fail the build if the diagnostic should have always been reported.

@BrennanConroy
Copy link
Member

We're also seeing other issues:

  • Forwarded types changed drastically, you now need to declare the entire surface area as forwarded, and likely even new APIs on the types would need to be copied here. Additionally, you have to have the correct generic name whereas before we didn't even need one, and there was no ctrl-. in VS for this.
-~Microsoft.AspNetCore.Http.Features.FeatureReference<> (forwarded, contained in Microsoft.Extensions.Features)
-~Microsoft.AspNetCore.Http.Features.FeatureReferences<> (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReference<T> (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Fetch(Microsoft.AspNetCore.Http.Features.IFeatureCollection! features) -> T? (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Update(Microsoft.AspNetCore.Http.Features.IFeatureCollection! features, T feature) -> T (forwarded, contained in Microsoft.Extensions.Features)
+static readonly Microsoft.AspNetCore.Http.Features.FeatureReference<T>.Default -> Microsoft.AspNetCore.Http.Features.FeatureReference<T> (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReference<T>.FeatureReference() -> void (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache> (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Cache -> TCache? (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Collection.get -> Microsoft.AspNetCore.Http.Features.IFeatureCollection! (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.FeatureReferences(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection) -> void (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Fetch<TFeature, TState>(ref TFeature? cached, TState state, System.Func<TState, TFeature?>! factory) -> TFeature? (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Fetch<TFeature>(ref TFeature? cached, System.Func<Microsoft.AspNetCore.Http.Features.IFeatureCollection!, TFeature?>! factory) -> TFeature? (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Initalize(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection) -> void (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Initalize(Microsoft.AspNetCore.Http.Features.IFeatureCollection! collection, int revision) -> void (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.FeatureReferences() -> void (forwarded, contained in Microsoft.Extensions.Features)
+Microsoft.AspNetCore.Http.Features.FeatureReferences<TCache>.Revision.get -> int (forwarded, contained in Microsoft.Extensions.Features)
  • REMOVED doesn't seem to be working anymore, or not as previously expected
    • Before, nullable changes were added to unshipped and REMOVED was used for the previous API. Now it complains about the same API being defined already
  • Having both ~abstract Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPart.Name.get -> string
    and abstract Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPart.Name.get -> string! in the Shipped file complains about the API being defined already. This one I'm actually sort of ok with because it cleans the file up, but still annoying when dealing with dozens of files that are now erroring.

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

The change you are seeing was originally made in this PR six years ago: dotnet/roslyn-analyzers#984.

I'm also confused by this. We were at Microsoft.CodeAnalysis.PublicApiAnalyzers v3.3.0 before the small bump in this PR to v3.3.3. The dotnet/roslyn-analyzers#984 changes should have been part of every public release of that package (because those releases started in 2019). What led to us hitting the new behaviours at this time❔

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

More generally, can we back up to v3.3.1 or v3.3.2 and get the fix that avoids NREs when parsing the IBindableFromHttpContext<TSelf> interface w/o dealing with these regressions in the analyzer❔

@BrennanConroy
Copy link
Member

Or we could just accept the current changes needed and file issues for future improvements: #41115

@DamianEdwards
Copy link
Member Author

More generally, can we back up to v3.3.1 or v3.3.2 and get the fix that avoids NREs

I tried that and it seems unfortunately only v3.3.3 fixes the stack overflow 😞

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

Or we could just accept the current changes needed and file issues for future improvements: #41115

Except that seems to throw away our intent of keeping the PublicAPI.Shipped.txt files aligned w/ what we shipped in .NET 6.0.0 (modulo nullability) e.g. the additions in src/Http/Http.Features/src/PublicAPI.Shipped.txt. It also leaves us using an analyzer that doesn't seem to grok *REMOVED*, limiting our options going forward.

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

Oh, bad example. That's the forwarded case.

@BrennanConroy
Copy link
Member

e.g. the additions in src/Http/Http.Features/src/PublicAPI.Shipped.txt

What additions? New APIs are still going to be in unshipped.

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

What additions? New APIs are still going to be in unshipped.

That file contains a bunch of +s that I didn't initially relate to your forwarded complaint.

@dougbu
Copy link
Contributor

dougbu commented Apr 8, 2022

But my more important point was that *REMOVED* support is mandatory for how we use these files. Otherwise, might as well put everything in PublicAPI.Unshipped.txt files.

@DamianEdwards
Copy link
Member Author

The code in this PR is ready for review, but is still blocked from merging pending #41115

@DamianEdwards DamianEdwards requested a review from a team April 16, 2022 20:22
@DamianEdwards DamianEdwards added the * NO MERGE * Do not merge this PR as long as this label is present. label Apr 18, 2022
@DamianEdwards
Copy link
Member Author

Blocked by #41115

Copy link
Member

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I hope resolving the merge conflict and build issues won't be too much more effort.

@dougbu
Copy link
Contributor

dougbu commented Jun 9, 2022

@DamianEdwards we just merged #41115 🎉 Resolve conflicts && you should be good to go.

(Many thanks to @BrennanConroy for his perseverance.)

@@ -1188,6 +1242,28 @@ public static void BindAsync(HttpContext context)
=> throw new NotImplementedException();
}

private class BindAsyncFromImplicitStaticAbstractInterface : IBindableFromHttpContext<BindAsyncFromImplicitStaticAbstractInterface>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a test that has both IBindableFromHttpContext and an implemented BindAsync method (without Parameter) to see if it chooses the IBindableFromHttpContext.

@DamianEdwards DamianEdwards requested a review from a team as a code owner June 9, 2022 23:22
@DamianEdwards DamianEdwards force-pushed the damianedwards/ibindablefromhttpcontext branch from dbb8138 to 3e86f30 Compare June 10, 2022 17:28
@DamianEdwards DamianEdwards removed blocked The work on this issue is blocked due to some dependency * NO MERGE * Do not merge this PR as long as this label is present. labels Jun 10, 2022
@DamianEdwards DamianEdwards enabled auto-merge (squash) June 10, 2022 20:58
@DamianEdwards DamianEdwards merged commit 6a8cc0d into main Jun 10, 2022
@DamianEdwards DamianEdwards deleted the damianedwards/ibindablefromhttpcontext branch June 10, 2022 23:33
@ghost ghost added this to the 7.0-preview6 milestone Jun 10, 2022
@dougbu
Copy link
Contributor

dougbu commented Jun 10, 2022

🥳 🎉 🎈 and so on❕

captainsafia pushed a commit to captainsafia/aspnetcore that referenced this pull request Jun 13, 2022
* Added IBindableFromHttpContext<TSelf> interface
* Discover BindAsync via IBindableFromHttpContext interface
* Added tests
Co-authored-by: Stephen Halter <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
old-area-web-frameworks-do-not-use *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Introduce interface with static abstract BindAsync method for custom bound parameters of route handler delegates
6 participants