Added support to WebApp to be ran directly.

[phillipfisher]

Added support to WebApp to be ran directly without having to deploy to Service Fabric. Set WebApp as StartUp Project and NoFabric as Launch Profile and Run. I've found this to be a useful step for my projects. The compilation and deployment of large projects to service project can be time consuming and slow down severely normal debugging. In this way someone can develop the WebApp very quickly and switch to deploying the full application suite to Service Fabric.

[johnkattenhorn]

Really nice @phillipfisher! we did something similar to this but you version is much tidier.

[cwe1ss]

This only works as long as you don't access any features of Service Fabric (stateful services [reliable dictionaries, reliable queues], Health API, Settings, ...). I guess, SF will throw an exception if a service tries to access one of these APIs without having registered itself first.

If I've seen it correctly, it also complicates the scenario in which you want to deploy the service into your local Service Fabric cluster. Since you rely on the ASPNETCORE_ENVIRONMENT-system (for detecting dev, staging, production) and never register the app with SF if you are in Development, your app also wouldn't register itself with the local Service Fabric cluster unless you specify a different environment in the startup args of your ServiceManifest.xml.

If you have a stateless web app and if you don't use any of the other Service Fabric APIs, you could also use our hosting project or a similar solution which works more transparently.

Another thing that's not nice about this PR is that you now have two Startup classes with a lot of duplication. Everything in ConfigureServices() and the most important part of Configure() [e.g. configuring MVC options] must be kept in sync. If you really need separate Configure() methods, you could also just use ConfigureDevelopment(), ConfigureProduction(), ... in one Startup class. This is described in the last part of Working with multiple Environments in the ASP.NET Core docs.

[cwe1ss]

And there's not much value in enabling IISIntegration - Service Fabric doesn't use IIS to host ASP.NET Core apps.

[phillipfisher]

All good comments @cwe1ss. And yes some of this stuff is duplicated. But for a large project most your time is spent developing the application and not messing around with Startup, and doing something like I've checked in speeds up development significantly IMHO.

As for the Service Fabric resources, you can use them! I know I was shocked the first time it worked. But if you are developing locally all you have to do is first do a full deploy to your local Service Fabric and then end debugging (the application will continue to run). And then run your WebApp locally and access all the endpoints still running on your local fabric. Granted you can't use any stateful objects directly compiled in your WebApp, but for me I keep my Web layer completely stateless and only rely on back end services to maintain state.

So this may not be something everyone would want or need. But I have found it quite helpful quickly building my stateless web layer where unfortunately I spend the majority of my time.

[cwe1ss]

Interesting, didn't know that you can access them if you don't call the fabric runtime.

Being able to work locally without deploying to SF is extremely useful and we do this every day - that's why I posted the link to our hosting project. It allows you to do the same as you've done here, but it also allows you to deploy to your local cluster. The main difference of our project is, that it doesn't rely on the environment key - instead it decides based on a command line argument whether or not it should register with SF. Maybe it's helpful for you as well!

[weidazhao]

@phillipfisher , thanks for sending the pull request.

We're aware of the slowness of web development with Service Fabric and this is one of the top things the team is currently looking into. To better understand your scenarios, I have two questions for you:

1. How does your web front communicate with backend services? Is it using HTTP only or Fabric client APIs?
2. Service Fabric also supports guest executable. If your web front end only uses HTTP to talk to back end, it's an alternative to deploy web front end as a guest executable service. In that case, the front end doesn't need to understand anything about Service Fabric at all, so you can develop your web front without Service Fabric involved (You'd need Service Fabric to run your back end services though). Would that work for you? One of the advantages of guest executable is that it is language/runtime agnostic. You could even use .NET Core for your web front end, which is not currently supported by Service Fabric APIs.