-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
Support the new top level statements with WebApplicationFactory #33462
Conversation
- This change adds support for the WebApplicationFactory without a CreateHostBuilder method. It uses the new ResolveHostFactory method in combination with a DeferredHostBuilder and DeferredHost to accomplish this.
- Look for both IHostBuilder and IWebHostBuilder before falling back to the new pattern.
{ | ||
return builder.UseEnvironment(Environments.Development); | ||
return new NullWebHostBuilder(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could also change the nullability here but I couldn't figure out how to do that. All of the tooling was fighting me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So changing the method signature to:
protected virtual IWebHostBuilder? CreateWebHostBuilder()
Is not working here? Bummer.
I say that mostly because it tripped me up while reading it. Why are we creating a NullWebHostBuilder
? Well, that doesn't actually matter, we're just saying there's no builder on the target assembly so we need to construct our own deferred one. It would've read better with nullability set correctly here. If it's possible to do that, I think it'll help us with maintainability for this moving forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the tooling was fighting me.
I'm guessing it's the publicapi analyzer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was raging at this last night and I went to bed after outsmarting nullable 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
Get the tests to pass!
{ | ||
// Copy the properties from this builder into the builder | ||
// that we're going to receive | ||
foreach (var pair in Properties) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not do:
b.Properties = new Dictionary<object, object>(Properties)
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b.Properties is read only.
{ | ||
return builder.UseEnvironment(Environments.Development); | ||
return new NullWebHostBuilder(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the tooling was fighting me.
I'm guessing it's the publicapi analyzer?
TODO:
PS: One downside with top level statements is that there's no publicly accessible type to reference the entry point, so application developers need to create a dummy type to reference it at compile time. cc @jaredpar @MadsTorgersen