When running Web applications from within Visual Studio, there have generally been two primary hosts available while developing: a local “development” Web server, or a full version of Internet Information Services (IIS). There has also been a “custom server” option, where a path to a server executable could be entered; however, this was not a widely used option given that most Web applications were built for the ASP.NET pipeline running in some flavor of IIS anyway.
With Visual Studio 2013, ASP.NET will include a new way to compose and host Web applications. In this new model, ASP.NET will shift from a monolithic framework to a set of smaller components put together into a pipeline and hosted in any number of user-selected hosting options. Modularity and flexibility is made possible because all application and hosting components are built on the same core abstraction: OWIN. For more information on OWIN, and the Microsoft OWIN components (known as the “Katana” project), see An Overview of OWIN and Project Katana.
One of the components included in the Microsoft OWIN components is the lightweight, console-based OwinHost.exe. This host finds the user’s startup code and uses it to build an OWIN pipeline; it then uses an HttpListener-based server to receive requests and push them through the OWIN pipeline. OwinHost is a nice, lightweight option for development-time hosting – particularly if the application will ultimately be deployed into a self-hosted environment. And as such, we wanted to improve the experience for connecting it to the Visual Studio experience.
In order to accommodate OwinHost, as well as any additional new hosting frameworks, we made some changes to the way that Web project properties are presented in Visual Studio, and how users select development servers. The new layout shows a drop down for available servers and a property pane which refreshes when a different installed server is selected. By default we continue to include IIS, IIS Express, and External Host (was Custom Server in Visual Studio 2012).
In order to add new servers to the list, we also created an extensible API which users can call either programmatically or via PowerShell. For example, the following code manipulates the custom server API using PowerShell script.
- PM> $serverProvider = $dte.GetObject("CustomWebServerProvider")
- //This gets the custom server object for all of Visual Studio
- PM> $servers = $serverProvider.GetCustomServers("WebApplication2")
- //This gets the custom server list for the passed in project (WebApplication2 in this sample)
- PM> $servers.AddWebServer('foo', 'c:\test\foo.exe', '/{url}', [System.Management.Automation.Language.NullString]::Value, '{solutiondir}')
- //This adds a Custom Server with
- //Name: FOO
- //Location of EXE to Execute and pass parameters into: C:\Test\foo.exe
- //Command Line Arugement: /{URL}
- //URL: Not specified (due to the [System.Management.Automation.Language.NullString]::VALUE
- //And a Working Directory: {SolutionDir}
- //Use of the {URL} and {SolutionDir} means that this server will defer to Visual studio to set those values automatically
Because of the scriptable API, the OwinHost NuGet package can now include a small install.ps1 PowerShell file which registers OwinHost.exe as an available custom server on package installation.
One thing to be aware of is that because of the manner in which the tooling interacts with the underlying project file, a Visual Studio 2013 project which has the OwinHost server registered as a custom server cannot be opened in earlier versions of Visual Studio. This warning is presented before the custom server is registered and it provides an opportunity to cancel the operation.
After installing the OwinHost package, simply open the Web project properties and notice that OwinHost is now a selectable option in the servers dropdown.
Selecting OwinHost reveals several additional configuration options, which can be helpful for tasks such as changing the default port or replacing any of the default infrastructure components (including the server component itself).
As lightweight Web frameworks and hosts become more popular, and as the number of choices continues to grow, we will ensure that the Visual Studio experience remains first class regardless of your chosen component set. So take a look at this new feature, let us know what you think, and let us know how we can continue to improve it and the Visual Studio Web development experience going forward!
- Howard Dierking and Joost de Nijs