Develop Reference

Transparently decomposing an ASP.NET Website hosted in Azure

I maintain a website written in ASP.NET MVC 5, and hosted in Azure. It's a legacy app that is a real nightmare to maintain, and so I've been asked to start migrating to a new codebase and the ASP.NET Core framework.
Our goals are:
Migrate one page at a time
Don't lose the "F5 debugging" experience in Visual Studio
My initial thought was to use a virtual application/directory, which is supported both in Azure and in IIS Express. The idea is to point, for example, the /Shop page to the new website by using a virtual path. Then when we're ready, move the /Team page and so on. I would add a virtual path for each migrated endpoint until the migration is complete.
To accomplish this I created a new ASP.NET Core project, and I've been trying to edit my applicationhost.config file and trying to start multiple projects from Visual Studio, without luck.
I tried configuring two sites with the same port binding, two apps within a <site> tag and also two virtual directories within an <application>, but I always end up with errors. Either I can't start debugging (Can't connect to IIS Express or The object invoked has disconnected from its clients messages) or I get a 502 error.
I don't even know if this is going to work in Azure, but I know we can't go down this path without proper development experience.
Am I missing some other, better solution? If this is a good solution, is there any way to make this work in Visual Studio?

I would consider creating multiple new websites in Azure, one for each section. Then, as I start working with Shop, for example, I'd leave an almost-empty controller in the original solution, redirecting to your new Sales web site. Using this approach, you can efficiently work with one smaller code base at a time and in the future scale the individual pieces of your site as needed. Please note, that you can host multiple sites within the same app service environment (thus not incurring a lot of extra cost by separating into multiple processes).
Best of luck :-)

How to make file references to local disk work in Azure Web Site?

In my Azure Web Site I have in my AppSettings section in Web.Config some references to files on my disk. When deployed to Azure those references doesn't count any more. I know that you can overwrite AppSettings in Web.Config in the Azure environtment. But what is the file structure there?
A couple of examples from my web.config that I have to solve:
<add key="DataMapPath" value="d:\inetpub\MyWebApp\App_Data\map.xml"/>
<add key="CuteWebUI.AjaxUploader.TempDirectory" value="C:\Temp\WebApp\Attachments\UploaderTemp"/>
The first file tells our code to look for the map.xml-file in the App_Data-directory.
The last one tells our upload-controll where to upload files. I maybe should have used Azure Blob Storage here instead but that would need some major refactoring of our code.
Is there som best practices on this topic?
Our WebApp is running in production today, but I want to try out MS Azure. But I doesn't want to do to many code changes to make it work in Azure.
I have also read you can spin up an Virtual Machine (Windows Server) but that is overkill for my needs right now. We may go that way in the end, but for this testing-purpose it should be made simple.
Any suggestions on how this could be solved? Someone done this before? I guess someone has. Indeed.
If I do have read and write access to the file system for my Web Site I maybe could use this:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TheFolder");
This would be appropriate for both on-premise and Azure deployment. But then I have to do some changes in our code.

You have multiple options:
Option 1: Use the App Settings of your web app to set custom settings for your website.
Option 2: Create multiple versions of your web.config (Visual Studio supports this) and deploy different versions to Azure and your local machine
Option 3: Make your path's relative to the paths of Azure Web App's environment variables
There's a HOME environment variable in your Azure Web App that resolves to the equivalent of inetpub for your site. Your app data folder is located at %HOME%\site\wwwroot\AppData.
There's also a TEMP environment both on Azure Web Apps and on your local machine. You can make your second setting relative to the TEMP environment variable value.

Actually you won't have this kind of "control" using azure web sites. To keep your app as it is, use Azure Virtual Machines.

routing not working whilst using iis instead of visual studio 2010's development server

I have to deal with a legacy asp.net mvc web app (.net 4). It uses some customized routing, which works fine when I use visual studio 2010's development server. However, when I use iis instead (during debugging) it does not seem to work (never used iis during debugging before).
The answer provided here does not seem to help. I already use:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Is there any other reason why the routing may not work? Thanks!

A generic post, unfortunately Internet Information System can create a slew of configuration issues. This is quite possibly it's largest pitfall. Is when you launch it on a Deployment Server, Local Server, or a Production Server the outcome may never appear to be the same.
I'll use Internet Information System Six, because it is similar to Seven and Eight but it just lacks certain features.
Inside of your project for ASP.NET MVC Web Application you'll want to right-click your project and select Properties.
You should see a tab that indicates the word: *Web**
Inside this tab towards the bottom you'll want to ensure that Use IIS Web Server is selected.
You'll want to put a Project URL in there.
This field should look like: *http://localhost/ApplicationName*. What your essentially doing here is mapping your project directory for IIS. You see each IIS Site stores a site inside the:
C:\inetpub\wwwroot
That is your Root Site Folder, where IIS will reference all of your Site Components. ** Keep in mind this Virtual Directory in projects is actually different then your IIS Configuration item listed. **
Now you'll want to open Internet Information System, you'll want to setup your File Extensions. So before doing anything in IIS, you'll want to configure your ASP.NET MVC Installer. You need to configure your mappings (ISAPI) to the .mvc extension to aspnet_isapi.dll. This step is required in order for IIS to hand off Routing Request using the .mvc extension to ASP.NET.
From a good blog post he stated:
If you’re planning to use extension-less URLs, you can skip this
section, but it may be useful to read anyways as it has some
information you’ll need to know when setting up extension-less URLs.
Mapping .mvc to ASP.NET
If you plan to use the .mvc URL extension, and are going to deploy to
IIS 6 on a machine that does not have ASP.NET MVC installed, you’ll
need to create this mapping by performing the following steps.
One nice benefit of using the .aspx extension instead of .mvc is that
you don’t have to worry about mapping the .aspx extension. It should
already be mapped assuming you have ASP.NET installed properly on the
machine.
For the rest of you, start by right clicking on the Virtual
Application node (IIS6DemoWeb in this case) and select Properties. You
should see the following dialog.
Make sure your in the Virtual Directory Tab and select Configuration. This will allow changes to the root website. This should bring up your Application Configuration Dialog. That will allow you to physically map your application. Since your using .mvc that is what you'll select.
If .mvc isn't found in the list, you can point to the Data Link Library here:
c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll
Now before you run the application you need to update the default routes, that way they look for the proper file extension. In your Global.asax.cs you'll want to ensure your using .mvc extension.
You would implement a method such as:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}.mvc/{action}/{id}",
new { action = "Index", id = "" }
);
routes.MapRoute(
"Root",
"",
new { controller = "Home", action = "Index", id = "" }
);
}
That should allow the site to properly display. This is a very, very generic and broad example. But hopefully this points you in a good direction.
Update:
When utilizing Internet Information System Seven you have to be aware of the following:
Site Configuration
Application Pool
Database Configuration
Those three items are common culprits to incorrect configuration.
A really wonderful blog can be found here:
Another nice article can be found here:
However, this article should hit the nail directly on the head for you:
As I stated the above detail should resolve your issue. But, with the introduction of IIS 7 they have two completely different methods to allow request: Integrated and Classic.
The major difference is Integrated will perform better and includes more features. Where Classic is designed for backwards compatibility. Your route request processing method is determined by your Application Pool. With this incorrectly configured; it won't work.
Launch the Internet Information Services Manager
In the Connections window, select an application
In the Actions window, click the Basic Settings link to open the Edit Application dialog box
Take note of the Application pool selected.
By default, IIS is configured to support two application pools:
DefaultAppPool and Classic .NET AppPool. If DefaultAppPool is
selected, then your application is running in integrated request
processing mode. If Classic .NET AppPool is selected, your application
is running in classic request processing mode.
From within that box you'll be able to modify the processing mode within an "Edit Application Dialog Box".
Hopefully this additional information better assist you for your goal. The first two blogs are a avoiding IIS, where the third one focuses specifically on IIS 7. If you have any questions let me know.

How to specify a port for the ASP.NET Configuration Site?

Is there any way to specify a permanent port for ASP.NET Configuration site (Web Site Administration Tool)?
I need to add a link to the ASP.NET Configuration site, but I can't due to the port changing each time it starts.

Its the port for ASP.NET Development server
http://msdn.microsoft.com/en-us/library/ms178109.aspx

I'm not sure that you can.
The Web Site Administration Tool isn't really meant to be "linked" to as such, it's a fairly powerful, unsecured application, that's only really meant to be run by a developer/admin.
The "Considerations" section of the documentation explain why:
The following sections provide some considerations for working with the Web Site Administration Tool.
Restarting the Application When Saving
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. This requires the Web site to which the change applies to be restarted. Because this will cause currently active sessions in the Web site to be lost, you should make configuration changes to a staged or development version of the Web site before publishing these changes to the production server.
Saving Your Settings
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. For settings for which the Web Site Administration Tool interface has a dedicated Save button, leaving the Web Site Administration Tool idle or allowing the Web Site Administration Tool to time out before you click Save will cause your configuration settings changes to be lost.
Time Out
As a security measure, the Web Site Administration Tool times out after a period of inactivity. Any settings that did not take effect immediately and were not saved will be lost. If the Web Site Administration Tool has timed out, close your browser, and then reopen the Web Site Administration Tool in a new window.
The Web Site Administration Tool manages only some of the configuration settings that are available to the Web site. Many other settings require direct modification of configuration files either manually, by using the MMC Snap-In for ASP.NET, or programmatically, by using the ASP.NET Configuration API.
From that you can see that this isn't something that's intended to be kept around.
That said, with a little bit of hacking around, you could probably shoot yourself in the foot achieve what you're after:
If you right click on the ASP.NET Development server task tray item for the admin tool, and select "Show Details", you can see that the virtual directory that the tool runs under is mapped to (something like):
C:\Windows\Microsoft.NET\Framework\v4.0.30319\asp.netwebadminfiles\
If you were to create (and secure) a virtual directory on your application mapped to that path, you might well be able to get this all up and running as you want.
As pseudocoder points out in his comment below, while going down the Virtual Directory route does "work", there are some limitations to the tool that, coupled with the security issues mean that you probably wouldn't want to use it going forward.
If you were to stick with the Development Server option, the tool won't respond to non-local requests, and once you've deployed the site to a proper web server (IIS) for users to access the Admin site won't be running anyway.
It would probably be better if you could explain why you want to use this permanently so we can advise you on some better options - for example the Membership, Profile and Role providers both provide nice APIs for managing user details that can be easily built into a custom admin area.
Tricky one, however I think to get this working correctly, you're going to have to spend some time doing something, and it's probably better for you in the long run to spend that time doing the right thing rather than hacking in the wrong option.
The Development server can be started from a command line, using a commands along the lines of:
call "C:\Program Files\Microsoft Visual Studio 9.0\vc\vcvarsall.bat"
"C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.exe" /port:3900 /path:"PATHSITE" /vpath:"PathSite"
The first line sets up the CMD instance to use the variables and path settings needed to run most of the Dev tooling
You'll want to change the path to the DevServer as appropriate for your environment (mine's in \10.0\ for example, and has a 2.0 and 4.0 version).
Armed with this information, you could do something along the lines of:
Add a link to your site to a page called /StartAdmin.aspx or similar.
In that page, you would then need to have the logic to:
Check through the running processes for the instance of the DevServer that was previously used to host the Admin site.
Close that process down.
Spool up another instance of the DevServer with a known port, pointing to the path for the WebAdmin Site.
Redirect the user to this new site.
All of which is possible, but it's not trivial, and you'll find you'll need to be doing odd things with the process your starting, and you'll need to be very careful you don't shut down the instance of the DevServer that's actually running your site by mistake.
However, this would probably take as long as it would to knock up a quick set of user admin screens, and you'd learn something more useful along the way*
* Which isn't to say that learning how to start and leave running a process isn't useful, it's more to say that I'm guessing its not what you're supposed to be learning at the moment, and you should probably be focusing on that ;)

Assemblies, Web.config and App.Config -- Building failover logic

How do I engineer failover logic properly if an Assembly (.dll) cannot find a web.config file?
Background: I've got our website code nicely modularized into two different .dlls. For simplicity's sake, let's call them:
website.dll
commonengine.dll
The website code and .aspx / .ascx files calls upon the commonengine library for all data layer stuff. For connection strings, the commonengine in turn looks not to the app.config but to the website's web.config file (that's my own preference -- I prefer to have our production constants all in one place). The website code occasionally (very rarely) needs to access stuff in that web.config file. All good so far (even though not entirely pure).
Here's the trouble. I've written a third module. It's a Windows Service (specifically, it's a POP3 checker/processor -- processing mailbox requests and using the commonengine.dll for some data layer stuff).
The problem is the Windows Service calls upon the commonengine.dll, and the commonengine.dll cannot find web.config anywhere because, after all, it's a Windows service (.exe) and doesn't live in a website directory.
What's the proper test/logic here to use app.config when a web.config file cannot be found? Can any ASP.NET configuration gurus give me some guidance here? Thanks much if so.

I never read Web.config explicitly, I use the System.Configuration class to read it (e.g. System.Configuration.ConfigurationStrings["conn name"]). It will automatically go to Web.config in an ASP.NET app and app.config in an EXE.
Of course, you still have to take into account the fact that the config section might be missing.