-
Notifications
You must be signed in to change notification settings - Fork 312
Update Hosting API and TestServer API #525
Comments
Follow up items tracked in #530 |
This change does not affect DNX. |
When do we make the changes? Obviously, I'm confused. |
@guardrex you need to add a public static void Main(string[] args) {
var application = new WebApplicationBuilder()
.UseConfiguration(WebApplicationConfiguration.GetDefault(args))
.UseStartup<Startup>()
.Build();
application.Run();
} "web": "Microsoft.AspNet.Server.Kestrel" -> "web": "PlatformIssue" |
@PinpointTownes Gotcha ... thx ... Adding the |
Yes, this is a change that's there today in the RC1 templates as well (though it's not wired up properly). Your application now controls the entry point. |
I got it ... It works. Thanks! I'm good now. |
Sounds like another regression, IMHO. But I guess it's the price to pay to embrace the new CLI world? 😄 |
Oh, and FWIW, I preferred the tiny version of the entry point: |
It's actually pretty nice in some ways. The application gets to control all aspects of startup.
It's great until you need to customize anything. That's why we did this refactoring. People wanted to add overloads to |
This was my Christmas present from the team 🎄 ... a If we're going to break with dotnet CLI changes in either VS or on the server, please give us a shoutout warning to "freeze" our runtime and packages so we can ride it out to |
|
We did, that's by we designed the new API this way. We heard complaints about the amount of overloads WebApplication.Start had and I actually agreed. It got out of hand pretty quickly. Not to mention we have more things you can customize in this new world.
We met and decided against that because the cliff you fall off when you need to customize anything is too big. We're sticking with this API and we'll make it easy to do the simple things so that it scales from 0 to 100. |
For projects with multiple commands, Do we declare multiple entry points (entry points with names other than |
Running IIS Express through Visual Studio changes project.json from
back to Microsoft.AspNet.Server.Kestrel |
@JunTaoLuo For Item 4 Startup assembly name ...
... it looks like my test app is running without an explicit Startup and not throwing any exception or misbehaving AFAIK. The test code I'm working with can be seen here: dotnet/AspNetCore.Docs#825 (comment). Your intention is that |
Your linked code calls Configure which is an alternative for UseStartup. |
@Tratcher |
After this update, I can't run it on VS2015, I got this : |
@jeffiy did you change your application to account for the new APIs? |
@davidfowl Yeah, I did changed. |
Put a sample somewhere with repro steps |
@davidfowl You can see the sample here, thanks. |
Is there a sample that is set up to run in an azure web app? I can run on my local box (and kestrel defaults to localhost:5000), but on azure I'm not sure of the right way to hook it up to IIS. The generated web.config from dnu publish is different than the ones back I have from the KRE days. |
@timmydo Did you update to the latest ASP.NET 5? Are you using visual studio? It'll "do the right thing". Trying to update a project from KRE days will be hard, too much has changed. |
@davidfowl Using VS 2015 (but publishing separately from command line) with 1.0.0-rc2-16357 clr x64 and https://www.myget.org/F/aspnetvnext . dnu publish creates a web.config like
I can run the cmd file by itself and everything works on port 5000. With the move to the httpplatformhandler, I was looking for examples on setting up kestrel to listen under httpplatformhandler (which would need to use HTTP_PLATFORM_PORT, right?) and how the program entry point should look. I got it working on azure with the code below after a bunch of tries, but I didn't see any samples running under httpplatformhandler in the samples @JunTaoLuo posted.
|
Why aren't you using RC1? RC2 isn't done yet and as @guardrex said, there are changes that are still is flight (as RC2 is still under development). Anyways, you don't need to manually read the port from the environment variable, the default hosting configuration already handles that. |
Ah you're right that the default hosting config does that. My bug was that I was doing something like:
...and azure/IIS probably closed stdin causing my app to exit early. The way I see it, I'll have to migrate the code when rc2 comes out anyways, so I might as well do it now. I think there was something from rc2 I wanted so I moved early. The github announcements of breaking changes really makes it easier to migrate when names change. |
Quick question. I am working on a console application that has Asp.Net MVC embedded in it (for health checks and to receive notifications), and I have been struggling to figure out how to share the IoC container between the console portion and Asp.Net portion without using a static/global container property in RC1 ( with Is it correct to assume that this API change in RC2 will allow this by passing in a specific delegate into |
That doesn't let you override the IServiceProvider, it merely lets you add more services that the Startup's ConfigureServices will see. Not sure if that's what you want. |
I did want to override the IServiceProvider, but if that delegate would allow me to pull out the Unless there is a better way to deal with this situation that I am unaware of? I really don't want to maintain two separate IoC containers for the different portions of the application and hope that any changes I make in resolution strategies is consistent between them (especially when it comes to singleton and instance resolutions). |
That's possible, once you build the application you can access |
Looking again I guess that's also possible with RC1 via |
So what you're saying is that you do want to do this. |
This conversation might go more smoothly if you wrote a code samples showing exactly what you want to do. A sample repository on github showing what that looks like would be even better. |
Sorry for the confusion. I will work on getting a sample project of what I'm trying to do up on Github after lunch (current prototype is entangled a bit in a proprietary solution so I can't upload it as is). Essentially my primary goal is to utilize the exact same ioc container instance for both console and asp.net portions of my Console application that embeds Asp.Net. I do not want each portion to have a different ioc container because i want to make sure that anything that resolves anywhere in the application is consistent from where it resolves in any other part of the application (especially critical for singletons and instanced lifetime objects). My initial thinking was to wrap my ioc logic in an implementation of With that seemingly not being a viable solution the only other solution that's apparent to me is to create code that creates an I'm not a fan of the latter idea because it relies on my primarily console application to rely on Asp.Net for dependency injection. I am not aware of a cleaner way to really keep dependency injection consistent throughout my app (I could very well be missing something since this is all being done via exploratory testing and not much documentation). |
Sorry for the delay. An example of my scenario is at https://github.com/KallDrexx/ConsoleAspNetExample/tree/master/src/ConsoleAspNetExample. This is the only solution I can figure out to get dependency injection to work the same in and out of Asp.Net, which is especially useful when singletons are involved. I might be missing something stupid here and I'm open to that criticism. The problem with this is that my core application is now reliant on getting the ioc container from Asp.Net, and due to the To me, in an ideal world, I could create my ioc container in the Hopefully that makes more sense. |
You can't add to an already constructed container. What IOC container are you using? Does it have an adapter for asp.net 5? I think you can do what you want but I need some more details filled in |
I don't have a preferred ioc container in mind as the ones I usually use don't have good .net core support yet. I was planning on just using Autofac since it seems to have good .net core support (and is referenced in the Asp.net 5 documentation) but in the end I don't really care what ioc container I use, i just need one that works and makes me not have to worry about dependency injection. |
It matters what IOC container you use because most of them don't allow you to modify the container itself after it's been built. The only place you can get at the container registrations is the startup class. You have to use ConfigureServices in the startup class then use that instance in the rest of your application. public IServiceProvider ConfigureServices(IServiceCollection services)
{
_containerBuilder.Populate(services);
_container = _containerBuilder.Build();
return _container.Resolve<IServiceProvider>();
} The problem though is that you need to flow out the IOC container you built in ConfigureServices. There's no way around that. |
Ok so I guess I've been jaded by my recent use of Ninject and TinyIOC that's allowed me to add resolutions to an existing container, and forgot that However, it seems to me that this makes Asp.Net very non-composable. If we say that Asp.net must always be in charge of creating your ioc container (no matter how small a part asp.net may actually be in your infrastructure) what's to say that I don't need another piece of infrastructure that's making the same assumption. Then I have zero possibility of having sane IOC in my project at this point because two totally unrelated (and marginal in my use case) pieces of infrastructure have made global and conflicting assumptions about how my application should be designed.
Honestly, I almost wish
Then (theoretically) the This allows clients to manage the creation of service providers instead of forcing Asp.Net to always be responsible for that. |
Something like that might be possible with some big changes (we'd have to shuffle some things around a bit) but we're not making anymore big API changes at this point. Can you file another issue so we can track this work to do something about it post RTM? There's likely a bunch of things that would need to change and be considered to make this work well end to end with other containers. |
Created #550. Thanks for the responses! |
Several issues and requests for API changes are being addressed in this PR #521.
This addresses: #518 #504 #357 #298 .
The text was updated successfully, but these errors were encountered: