7/28/18

ASP.NET MVC Apps on Virtual Directory with IIS Express

On previous articles, we learned how to deploy multiple ASP.NET MVC Apps on the same Azure Web App by using virtual applications.  We also learned that for some cases when more than one application defines the same routes, this may lead to an ambiguous routing request if not configured properly.

Previous Articles





In this article, we learn how to configure our development environment with a virtual directory and have a second app run on the same process which should simulate the environment on Azure.

IIS Express Configuration

Visual Studio Solutions contain a .vs folder with solution configuration information. In that folder, we can find a config folder with an applicationhost.config file.  This is the file that enables us to configure IIS Express when running apps from Visual Studio.

When we open the file, we should look for the sites node (xml node). This is where the sites/apps definitions can be found for a solution. In the case of a solution with two ASP.NET projects, we can find a setting similar to this:


<site name="ozkary.azure.vdir.main" id="2">

    <application path="/" applicationPool="ozkary.azure.vldir.main AppPool">

        <virtualDirectory path="/" physicalPath="d:\repos\ozkary.vdir\main" />

    </application>

    <bindings>

        <binding protocol="http" bindingInformation="*:61823:localhost" />

    </bindings>
</site>

<site name="ozkary.azure.vdir.admin" id="3">

    <application path="/" applicationPool="ozkary.azure.vdir.admin AppPool">

        <virtualDirectory path="/" physicalPath="d:\repos\ozkary.vdir\admin" />

    </application>

    <bindings>

        <binding protocol="http" bindingInformation="*:62029:localhost" />

    </bindings>
</site>



In the settings, there are two sites, main and admin.  Both of those sites run from a different local folder and a different port. If we translate this to an Azure deployment, we will need to deploy to two different web apps.

Our goal is to change to using only one app, and deploy the admin site as a virtual app under the main site.  To do this using IIS Express, we need to configure the main app setting to read the following:


<site name="ozkary.azure.vdir.main" id="2">

<application path="/" applicationPool="Clr4IntegratedAppPool">
           <virtualDirectory path="/"    physicalPath="d:\repos\ozkary.vdir\main" />

</application>

<application path="/admin" applicationPool="Clr4IntegratedAppPool">
          <virtualDirectory path="/" physicalPath="d:\repos\ozkary.vdir\admin" />

</application>

<bindings>
        <binding protocol="http" bindingInformation="*:61823:localhost" />

</bindings>

</site>


To review, we just add another application setting under the same site configuration. We are careful in setting the path information otherwise this can lead to errors. We set the new application node path attribute to the virtual directory name (admin). We then set the virtualDirectory node attribute path to the root of the second project which should have a different physical path.  This essentially is the same as if we would do this on an IIS Server.

Validate the configuration:

To validate that our configuration is working properly, we can take a look at the process that IIS Express is creating for us. We first take a snapshot of the process prior to making the virtual directory entry. If we run the projects, we would see that both projects are running with a different process ids,  PID. This is shown on this image below which is taken from the IIS Express admin app which is available from the system tray.


We can then stop the applications and add the additional application node under the main site.  We are now ready to lunch the applications again and take another snapshot.  We should now see that both applications are running under the same process id PID 25860.




After validating this locally, you can deploy to Azure and validate that this is working with no conflicts. To learn how to deploy to Azure using a virtual directory, review the article below:


  


Hope this is helpful and thanks for reading.

Originally published by ozkary.com

7/14/18

ASP.NET MVC Routing Error Multiple Controller Types on Azure Virtual Directory

In a previous article, I wrote about hosting an ASP.NET MVC app on a virtual directory on Azure.  You can find the article in the link below.  The main goal of that article was to show how to hosts other sites within the same Azure Web app.



There are cases when the multiple sites have similar routes and controllers, and the application find this ambiguous and does not know how to handle a request showing this error:



[InvalidOperationException: Multiple types were found that match the controller named 'Home'. This can happen if the route that services this request ('{controller}/{action}/{id}') does not specify namespaces to search for a controller that matches the request. If this is the case, register this route by calling an overload of the 'MapRoute' method that takes a 'namespaces' parameter.

The request for 'Home' has found the following matching controllers:
Admin.Controllers.HomeController
Main.Controllers.HomeController]
               
This error is somewhat odd because a deployment to a virtual directory should isolate the routes per application and there should not be this ambiguity.

Review Deployment and Configuration

When facing such error, we need to check the following possible problems:

1) When doing the deployment, we need to make sure the destination URL includes the virtual directory folder
For example:   www.mysite.com/admin    where admin is the virtual directory folder.

2) Make sure the virtual directory root folder is not the same as the main site
This is a common mistake. When doing the configuration for a virtual directory we must make sure to set the correct physical path as shown next:


The image shows how the main application and virtual path use different physical paths. If both are set to the same physical path, then the routes will be processed from both apps with the same route but different controller types which causes the ambiguity.

Before doing the deployment to Azure make sure to test this configuration on your development environment. For those using Visual Studio with IIS Express, you may find this article useful:
I hope this is helpful.

Originally published by ozkary.com