Jerry Orman : ASP.Net

Referencing .js files for the AJAX Control Toolkit

Jorman — Sat, 19 May 2007 00:02:00 GMT

I was recently working with someone that was leveraging the AJAX Extension and the Control Toolkit and they were running into an issue where a customer's environment was causing issues making requests to ScriptResource.axd. Since they couldn't change the environment, they needed to reference the .js files directly. Here's a rundown of the steps in case anyone needs to do this in the future:

1. Create a folder to hold the .js files in your site. In my case I created a "Scripts" folder on the root of my app.

2. Create the following folder structure under the folder from Step 1. The folder that is a version number should match the version of the control toolkit. This can be found on the Releases page for the extension.

        - <Root>
                - Scripts
                        - AjaxControlToolkit
                                - 1.0.10301.0

3. Open the Control Toolkit project and build the solution. This should generate the \obj folder that contains all the .js files.

4. Copy the Script files for the toolkit project to the site

From: <path_to_unzipped_toolkit>\AjaxControlToolkit\obj\Debug

To: 1.0.10301.0 folder from above

5. Copy the Script files for the AJAX Extension:

From: Copy the System.Web.Extensions folder and all it's contents from C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025\MicrosoftAjaxLibrary

To: ~/Script folder. You should have a folder structure similar to:

        - <Root>
                - Scripts
                        - System.Web.Extensions
                                - 1.0.61025.0

6. Set the ScriptPath on the <scriptManager> to "~/Scripts"

7. Make sure the controls are not explicitly setting ScriptPath as that will override the ScriptManager property.

Now when you browse the page, the .js files will be loaded from the ~/Scripts folder instead of via calls to ScriptResource.axd. If you're getting script errors, take a netmon and ensure all the requests to the .js files are returning a status code of 200 or 304.

Fix: Random FileNotFoundException in ASP.Net 2.0 application

Jorman — Mon, 26 Mar 2007 18:17:00 GMT

Issue - Random FileNotFoundException when browsing ASP.Net 2.0 application. An event similar to the following will be logged in the event viewer. The file name in the exception is typically different every time:

Exception message: Could not load file or assembly 'App_Web_-a8debde, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Stack trace:    at ASP.UserControl_ascx.__BuildControlmain()
   at ASP.UserControl_ascx.__BuildControlTree(dynamic_default_ascx __ctrl)
   at ASP.UserControl_ascx.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.UserControl.InitializeAsUserControl(Page page)
   at ASP.default_aspx.__BuildControlhtml_content()
   at ASP.default_aspx.__BuildControlTree(default_aspx __ctrl)
   at ASP.default_aspx.FrameworkInitialize()
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.default_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Workarounds - In some cases, it's necessary to clear the Temporary ASP.Net Files folder and restart the application pool. We've found in some cases that setting batch="false" in the web.config file will resolve the issue as well, however, there are some perf reasons for not doing that long term in production.

Getting the Fix - The KB for this fix is not yet public (I'll link it as soon as it is), however, the fix is available. You will need to contact Microsoft Support (http://support.microsoft.com/) and ask for the fix from KB article 934839.

Getting real-time updates from remote process using the AJAX Extension

Jorman — Fri, 09 Mar 2007 01:06:00 GMT

This sample was a result of an idea from Kent Post at Akamai. He was wanting to be able to launch a process on a remote server and get real-time updates in the browser. In this case, we focused on running WinPE scripts to build ISO's on the server. The WinPE scripts can take a long time to process, and the goal is to launch the process and see what was going on without having to be logged into the server console using the browser. The attached sample provides a way to perform these actions by using System.Diagnostics to launch the process and the AJAX Extension to get updates. Before getting into the sample, let's look at some of the complications of doing this type of work.

Permissions on the server - By default, the application pool running ASP.Net cannot run other processes on the server. The process by default runs as Network Service which typically won't have Read access to the .bat, .cmd, .exe you're trying to run. If you're writing files, it won't have access to write to directories either.
Getting the data back to the client - Once you launch the process, how do you get the data down to a remote browser? HTTP is a disconnected protocol, so once you spin up the process, you need some way of making additional requests and getting the output.
Application can not be interactive - Making sure the application you're running does not have an interface that requires interaction. Keep in mind you are launching a child process from a non-interactive service and there is no way for a remote or local user to actually interact with the program. Batch files are good for this scenario.

The first obstacle is relatively easy to overcome. For the demo, you can use a file based web site in Visual Studio 2005 and the built in web server. In this scenario, the web server and code run as the account you are logged into the box with and assuming this account has appropriate permissions to launch the program and write to any area that the program writes to, the app will work fine. From a server perspective, we ran the Application Pool as Local System. You can setup IIS with a new application pool running under local system and assign the application pool to the specific application to ensure other code is not running with elevated privileges. Another option is to use PInvoke and call CreateProcessAsUser and explicitly set desktop permissions for the application pool account you're using. This is a bit more complicated and won't be covered here. If you're interested in looking into that approach for launching processes, check out Q165194

165194 - INFO: CreateProcessAsUser() Windowstations and Desktops
http://support.microsoft.com/support/kb/articles/Q165/1/94.asp

The second problem of getting the output has a couple of options. One way to go is to pipe the output from the program to a text file and then redirect the browser to the textfile. If you haven't done this before, the following pipes the output of the dir command to the file c:\output.log: dir >c:\ouptut.log This gets you the output after the application has completed execution. However, in order to get the data as it's occurring, you have to make multiple requests to the server and access the StandardOutput stream directly. In this sample, we use the AJAX Extension, the setInterval method in JavaScript, the System.Diagnostics.Process class, and a custom class that's cached on the server to handle this scenario.

Overview of the sample
The attached files provide all the source to run the sample. Here's a rundown of what the app does and what is in the .zip files.

User browses Default.aspx - If the user does not have a cookie called MyGUID, one is created for them. The cookie value is used to uniquely identify the requests when making web service calls and for caching.
User clicks the Launch button

JavaScript posts to the LaunchProcess method of the ProcessLauncher.asmx web service using the AJAX Extension
LaunchProcess method does the following:

Creates an instance of the ProgramWatcher class
Calls the Execute method of ProgramWatcher

Execute method launches a ThreadPool thread
Runs the ReadLog.exe program
Redirects the StandardOutput of the ReadLog.exe program to a Stream property of the ProgramWatcher instance

The ProgramWatcher instance is cached using the MyGUID cookie value from Step 1

When the Async call returns, a timer kicks off that runs the GetStatus JavaScript method after 750 milliseconds.
GetStatus JavaScript method runs

Timer is stopped to prevent async callbacks from getting out of sync. i.e. IE can make 2 calls per server, this prevents 2 requests leaving the client and the 2nd request returning before the first request and messing up the output.
GetStatus method of the ProcessLauncher webservice is called

GetStatus loads the ProgramWatcher method out of cache using the MyGUID cookie value
Calls the ReadOutput method of the ProgramWatcher instance passing it how many bytes to read from the Stream property on ProgramWatcher - in this sample 50 bytes at a time.
Returns the bytes returned from ReadOutput

Client parses the response and handles output that contains \r vs. \r\n. See the Issues section below for why this is important.
Timer started again and Steps 4 - 5 occur again until the GetStatus method returns Null

Included Files
Here's a list of the files included in the .zip files with a summary of what they do. The code is commented thoroughly.

AjaxBatchProcess.zip

App_Code

ProgramWatcher.cs - This class is what drives the process on the server side. It contains an Execute method that launches a program via System.Diagnostics.Process and redirects the StandardOutput to a property on the class. The class is cached so that the browser can get the output from the process in chunks.
ProcessLauncher.cs - Web Service methods that allow the AJAX Extension to generate JavaScript proxy classes that are used to launch the process on the web server and also get the output in chunks.

AjaxBatchProcess.js - JavaScript file that calls the webservice methods and also handles getting and parsing the output.
Default.aspx - Page requested by an end user. Has a ScriptManager that hooks up AjaxBatchProcess.js and ProcessLauncher.asmx
ProcessLauncher.asmx - Web Service requested by the client.
Web.config - Web.config from the AJAX Extension project

ReadLog.zip

ReadLog.exe - Command-line program that reads the build_pe_out.txt file and pushes the output to the console.
build_pe_out.txt - Output from WinPE commands.

ReadLog-Source.zip

Program.cs - source for the ReadLog program. This program reads in a file passed in as an argument and pushes the text to the console.
Default C# console project files

Here are the steps to use the files attached to the blog:

Unzip AjaxBatchProcess.zip to a folder in your file system.
Unzip ReadLog.zip to c:\ReadLog
Open Visual Studio 2005
From the File menu | Select Open Web Site
Select the path from Step 1 (the folder that contains app_code, default.aspx, etc. from the .zip file)
Right-click Default.aspx, select View in Browser
Click the Launch button

Issues
I wanted to highlight a few areas and why we chose to go that route.

Caching the ProgramWatcher and the Stream property

This is an important part of the application and is the piece that allows access to the output from the application in real-time. In this case you have a program that is redirecting the StandardOutput to a Stream. This is essentially writing bytes into memory with a pointer at the end.

These are bytes<StandardOutput Pointer>

The ProgramWatcher class sets the StandardOutput stream to a property called Stream. This gives you another pointer to the same bytes that starts at the beginning.

<ProgramWatcher.Stream pointer>These are bytes<StandardOutput Pointer>

With this setup, you have the System.Diagnostics.Process adding bytes to the end of the stream via StandardOutput and ProgramWatcher.Stream reading the same bytes with a pointer that starts at the beginning. The ProgramWatcher instance is cached so that when you Read bytes off of ProgramWatcher.Stream, you are incrementing the pointer.

These are <ProgramWatcher.Stream pointer> bytes. This is additional data <StandardOutput Pointer>

When the GetStatus method is called again, you are accessing the same instance of the class, so the pointer is where you left it. I was making this way to hard, so thanks to Todd Carter for helping clear this up.

Parsing the \r and \r\n in the output returned by GetStatus

This is important as console applications handle text ending in \r different than \r\n. In the case of WinPE, you get output showing the percentage complete. The text looks like:

      |6.0.6001.16464 | + | WinPE-FontSupport-JA-JP-Package\r\n[==============             25.0%                          ]\r[===========================50.0%                          ]\r[============================75.0%===========               ]\r
[==========================100.0%==========================]\r\nMore Text

In the console, this renders as the following when it is complete:

      |6.0.6001.16464 | + | WinPE-FontSupport-JA-JP-Package
More Text

However, while the process is running, you would see the WinPE-FontSupport-JA-JP-Package line followed by the percentage. When the next line ending in \r is written to the console, the previous line is replaced with the updated percentage. The problem is that the browser doesn't handle \r and \r\n the same way. So you would end up with the following:

       |6.0.6001.16464 | + | WinPE-FontSupport-JA-JP-Package
[==============             25.0%                          ]
[===========================50.0%                          ]
[============================75.0%===========               ]
[==========================100.0%==========================]
More Text

Not real pretty. In the sample, I parse the output and if the output ends in \r, I put the information in the TextBox. If the text ends in \r\n, I clear the textbox and add the line to the TextArea. This gets pretty close to the same output you see in a console and avoids a lot of noise and clutter in the output.

Hopefully this sample and the information provided will help anyone out there trying to solve similar issues.

Viewstate error in mobile ASP.NET app

Jorman — Wed, 10 Jan 2007 22:35:00 GMT

This is my third mobile post this week! This one was tricky to track down so hopefully this will save someone some time. The symptom you see is that users get the following exception. If you're using ASP.NET 2.0, we would log this to the Event Viewer by default thanks to Web Events:

Exception of type 'System.Web.HttpUnhandledException' was thrown. --->

System.Exception: The page requires session state that is no longer available. Either the session has expired, the client did not send a valid session cookie, or the session state history size is too small. Try increasing the history size or session expiry limit.

This error would appear randomly throughout the day in a high throughput site. We were able to track this down using the IIS logs, Network Monitor, and in this case, the exceptions logged in the Event Viewer. The event logging in 2.0 captures a lot of information that is useful for lining up the exception with data gathered. In this instance, we used the client IP linked to the request and then filtered the Network Monitor logs using this IP. This allowed me to track the user's requests to see how they were using the site at the time of the failure.

In this case, we could see the client making requests for a few minutes, then their traffic would go away for longer than the session timeout. Their next request would come in for a page that they weren't browsing prior and would cause the exception. Looking at this data, we determined that users were bookmarking the site on their mobile devices. While this normally isn't a big deal, there are some devices that result in an __viewstate field in the QueryString. When you bookmark this URL, the initial request is now going to cause the mobile page to lookup the viewstate which is stored in Session for mobile forms. Since this is the first request, the session is just now being initialized, the ViewState isn't available, and the exception is thrown.

You can avoid this problem by adding the following code to Session_Start in the global.asax or a HttpModule. You can even get fancier and add some code to only remove the __viewstate QueryString if your pages are looking for other items in the QueryString collection. This code will ensure that when a new session is being created, that the __viewstate QueryString is not part of that request.

    void Session_Start(object sender, EventArgs e)
    {
        // Code that runs when a new session is started
        if (HttpContext.Current.Request.QueryString.Count > 0)
              HttpContext.Current.Response.Redirect(HttpContext.Current.Request.Url.LocalPath.ToString());
    }

You could also track this down by logging the QueryString in the IIS logs and looking for __viewstate in that field. The exception logged in the Event Viewer in 2.0 also log the UTC time to make it easy to line up the IIS entries which use UTC by default with the exception.

Determining what capabilities ASP.NET is using to render pages

Jorman — Tue, 09 Jan 2007 22:26:00 GMT

When you make a request to an ASP.NET based site, the browser's capabilities are determined by the <browserCaps> section in the 1.x Framework and the .browser files in the 2.0 framework. Knowing which capabilites that ASP.NET is using to render the page can be especially important in mobile applications.

You can use the following page to return all the MobileCapabilities for the device by browsing the page:

<%@ Page language="c#" AutoEventWireup="true" Inherits="System.Web.UI.MobileControls.MobilePage" %>
<%@ Import namespace="System.Web.Mobile" %>
<%@ Import namespace="System.Reflection" %>
<script runat="server">
     protected void Page_Load(Object sender, EventArgs e)
     {
          MobileCapabilities capabilities = (MobileCapabilities)Request.Browser;
          Type t = typeof(MobileCapabilities);
          PropertyInfo[] propertyInfos = t.GetProperties();
          foreach(PropertyInfo pi in propertyInfos)
          {
                    System.Web.UI.MobileControls.Label lbl = new
                    System.Web.UI.MobileControls.Label();
                    lbl.Text = pi.Name + " = " + capabilities[pi.Name];
                    Form1.Controls.Add(lbl);
          }
     }
</script>
<mobile:Form id=Form1 runat="server">
</mobile:Form>

The MobileCapabilities are determined by the UserAgent string that ASP.NET receives. You can log the UserAgent string in the IIS logs or you can use a tool like Fiddler or Web Development Helper in IE to get this information. Once you have the UserAgent string, you can use Fiddler to pass the same UserAgent string while browsing in IE. This will give you a larger viewing area for looking at hte list of MobileCapabilities.

Mobile ASP.NET Emulators

Jorman — Mon, 08 Jan 2007 23:44:00 GMT

When developing Mobile ASP.NET apps, it is useful to test the application across a variety of devices if the site is going to be posted to the internet. ASP.NET Mobile controls rely on adapters to handle rendering on the different devices. In order to hit the different adapters to ensure your page will work across the devices, you can use emulators. While troubleshooting mobile issues, I typically use the following emulators:

HTML3.2 - I use Internet Explorer or one of the Pocket PC/Smartphone emulators that ship with Visual Studio. The default rendering for these devices is HTML 3.2 and as a result, the mobile controls will use the HTML32 adapters to render.
WML - I use the OpenWave 7 emulator that comes as part of the OpenWave 7 SDK. ASP.NET picks up this device with a default rendering of WML allowing the mobile controls to use the WML adapters for rendering.
XHTML - I use the OpenWave 6.2.2 emulator. The default rendering for this device is XHTML.

You can also use the <browserCaps> section in machine.config (1.x Framework) or .browser files (2.x Framework) to force the preferredRenderingType property of a device, however, I have found that using the emulators is quicker for testing against.

OpenWave emulators can be found here: http://developer.openwave.com/dvl/tools_and_sdk/phone_simulator/

The Pocket PC/Smartphone emulators are available on the Tools menu, under the Connect to Device option.

If you have a specific device and ASP.NET is not rendering the right content; i.e. your device supports JavaScript, but you're not getting JavaScript; you can use the Device Profiling Tool to generate a profile of the device and generate a <browserCaps> section (1.x) or a .browser file(2.0).

If you need to build a section for <browserCaps>, you can do this online here:
http://www.asp.net/mobile/profile/default.aspx

If you need to generate a .browser file you can download the device profiler and run it locally:
http://www.asp.net/sandbox/app_devprof.aspx?tabid=62

You can find links to training and mobile ASP.NET development here: http://www.asp.net/default.aspx?tabIndex=6&tabId=44

JavaScript Fun!

Jorman — Thu, 23 Nov 2006 01:24:00 GMT

I was recently working with JavaScript and ran into some weird things I hadn't ran into before. While I'm sure the JavaScript masters of the world already know all about this stuff, hopefully this post can keep others from pulling out too much hair. The first one deals with scoping:

If you don’t explicitly var an object, that object is declared globally. The code will typically not fail, however, it will give you odd behavior. This becomes an issue if you have the following:

You would expect the alert to occur 10 times, however, since the x declared in the first for loop does not have var in front of it, the variable is global. When Loop2 is called, the loop increments x to 10 causing the for loop in Loop1 to only occur 1 time. To correct this code, change the for loops to:
for(var x = 0; x < 10; x++)

The other issue deals with naming of objects and functions. If you're developing everything it's no big deal as you will typically know what the ID's will be on the client as well as the names of JavaScript functions, but if you're leveraging someone's JavaScript library, this can become more interesting. The error you get in Internet Explorer is "Object doesn't support this property or method". The following line will reproduce the behavior, but imagine if you had a page with 50 controls and the function name that matches is in a JavaScript file you didn't write:

Custom WebPart Catalog

Jorman — Thu, 05 Oct 2006 23:34:00 GMT

Trying to catch back up on my blogging, I have a list of topics to post on, just haven't had time to get to them. I wrote this article over a month ago...figured I would link it up from here.

The default web part catalogs that are shipped with ASP.Net require you to configure the list of web parts you want to display in your catalog. We've had a few requests for a more dynamic approach and the article has a sample that can get you started on this.

http://support.microsoft.com/kb/910446

The article links up to a sample Solution and lays out the files and what they do. The main piece is a custom web part catalog that uses reflection to populate the list of web parts. The idea is that you drop a .dll into the /bin folder of your app and the catalog will automatically pick out the web part controls in the dll. It caches the list of parts to avoid the cost of looking up the dll's on future requests. This works great since adding a dll to the /bin will recycle the app domain and clear the cache, so all you need to do to add web parts to the catalog is to add the dll to the /bin.

The other piece is a custom WebPart that pulls data from an RSS feed and shows the different types of properties you can implement in the web part.

System.InvalidOperationException: Mutex could not be created.

Jorman — Mon, 24 Jul 2006 16:35:00 GMT

We've seen a few of these issues come through lately andwanted to get something posted so people can find it.

If you created a custom account to run the process that ASP.NET is running in, you may encounter the following exception:

System.InvalidOperationException: Mutex could not be created.

Stack Trace:
[InvalidOperationException: Mutex could not be created.]
System.Web.Compilation.CompilationMutex..ctor(String name, String comment) +3464689
System.Web.Compilation.CompilationLock..cctor() +158

[TypeInitializationException: The type initializer for 'System.Web.Compilation.CompilationLock' threw an exception.]
System.Web.Compilation.CompilationLock.GetLock(Boolean& gotLock) +32
System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled() +114

[HttpException (0x80004005): The type initializer for 'System.Web.Compilation.CompilationLock' threw an exception.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +3426871
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +88
   System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +149
--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42

Note: The error will appear to be random, but once it appears, will remain until a reboot or until the handles to the mutex are closed.

Cause:
======
This occurs because the permissions on the following registry key no longer have your custom account:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\CompilationMutexName

The compilation mutex gets it's permissions from this registry key and with your custom account missing, the process running ASP.NET cannot get a handle to the mutex and fails during compilation.

Resolution:
=========

Run the following to add your custom account to the registry key permissions:
ASPNET_regiis -ga domain\account.
Either restart the server or close the handles to the mutex (see below)

To close the handles to the Mutex:

Download and launch Process Explorer from www.sysinternals.com
From the Find menu, select Find Handle or DLL
In the Handle or DLL substring box, type “mutant” (without quotes) and click Search
Click the Handle or DLL column heading to sort the items and find a mutex that starts with CL. The handle will typically be devenv.exe (the IDE for Visual Studio) and aspnet_wp.exe or w3wp.exe. The handle will look similar to:
\BaseNameObjects\CLbdd6aa8f
Select the handle in the search box and Process Explorer locates the Process and the handle in the main window
Right-click the handle in the main window and select Close Handle

Additional Info:
============
The error may occur anytime you run ASP.NET as a custom account and the above mentioned registry key does not have the account listed in the permissions.

If you receive the error and you are running with a custom account on IIS 6 in worker process mode (code running in w3wp.exe), you can add your custom account to the IIS_WPG group on the server. The IIS_WPG group is granted access to the registry key by default.

Vista + IIS 7 + Local IIS web site = error?

Jorman — Tue, 06 Jun 2006 20:46:00 GMT

Finally got around to getting a clean install of Vista Beta 2 on my laptop and of course the first thing I install is Visual Studio 2005 and IIS 7 to see how the Local IIS option is going to play with the newly revamped IIS. Well, if you choose the default options, this is the message you get when selecting Local IIS in the Open/Create Web Site dialog:

You must be a member of the Administrators group on the local computer to access the IIS metabase. Therefore, you cannot create or open a local IIS Web site. If you have Read, Write, and Modify permissions for the folder where the files are located, you can create a file system Web site that points to the folder in order to edit the files.

Initially I'm thinking this is the User Account Control feature in Vista blocking me from accessing the metabase. So I turned that off in the Local Security Policy and still no go.

I then remembered an IIS 6 option under the Windows Features install dialog under Internet Information Services and found the following option that allows VS 2005 to play with IIS 7....IIS Metabase and IIS 6 configuration compatibility. Here are the steps:

Open Control Panel
Open Programs
Open Windows Features
Expand Internet Information Services
Expand Web Management Tools
Expand IIS 6 Management Compatibility
Check IIS Metabase and IIS 6 configuration compatibility
Click OK

Here is another blog that discusses debugging in this environment:
http://mvolo.com/blogs/serverside/archive/2006/12/28/Fix-problems-with-Visual-Studio-F5-debugging-of-ASP.NET-applications-on-IIS7-Vista.aspx

Hopefully this can save somebody some time when/if they run into it.

ASP.NET tab forces restart of W3SVC

Jorman — Fri, 14 Apr 2006 20:01:00 GMT

If you change the version on the ASP.NET tab that comes with the 2.0 Framework, the entire W3SVC process restarts. If you make this type of change during a maintenance window, the impact may not be too bad, but if you have multiple application pools in IIS and need to make this type of change during the day, all the application pools will recycle.

You can avoid this problem by running the following commands. The first command configures the mappings in IIS and uses the -norestart command to tell aspnet_regiis to not restart the W3SVC service. The second command restarts the IIS Application Pool:

%windir%\Microsoft.Net\Framework\<version>\aspnet_regiis -s <path> -norestart
%windir%\system32\iisapp.vbs /a <app pool> -r

It's important to note that it is not supported to run both 1.1 and 2.0 framework in the same application pool. For example, you can't have /MyApp mapped to the 1.1 framework in an application pool called MyAppPool and also have /AnotherApp mapped to the 2.0 framework in the same application pool. The symptom you will see is a Server Application Unavailable message in the browser. You will also get the following event in the Application Event Log:

Event Type: Error
Event Source: ASP.NET 2.0.50727.0 <could also be 1.1.4322>
Event ID: 1062
Description:
It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process.

This requires that you know the IIS metabase path to the app; something like /w3svc/1/root/myapp if the application is under Default Web Site. You also have to know the application pool which would require you to look it up in IIS.

I've attached a .vbs file that helps to automate this process. Feel free to modify it however you see fit. It takes in the name of the web site; i.e. "Default Web Site", the version of the framework you want to map, and the virtual path to the app you want to configure. It's much easier to remember "Default Web Site" or "Intranet", than it is to remember the instance number of 578954321 :)

Example command lines:

Configure the Default Web Site for ASP.NET 2.0
ASPNETMapping_norestart.vbs website "Default Web Site" version 2.0
Configure the Default Web Site for ASP.NET 1.1
ASPNETMapping_norestart.vbs website "Default Web Site" version 1.1
Configures the /mywebapp application for ASP.NET 2.0
ASPNETMapping_norestart.vbs website "Default Web Site" apppath "/mywebapp" version 2.0
Configures the /anotherapp application on the web site named Intranet for 2.0
ASPNETMapping_norestart.vbs website "Intranet" apppath "/anotherapp" version 2.0

Download the file here

Session loss after migrating to ASP.NET 2.0

Jorman — Mon, 06 Mar 2006 00:20:00 GMT

The HttpOnly attribute has been added to the Session cookie generated by ASP.NET 2.0. This value is hardcoded and cannot be changed via a setting in the application. While this is documented as a breaking change in the breaking changes document (linked below), it's not clear the types of symptoms you will see in your application, nor is the fix clearly stated.

void Application_EndRequest(object sender, EventArgs e)
{
     if (Response.Cookies.Count > 0)
     {
          foreach (string s in Response.Cookies.AllKeys)
          {
               if (s == FormsAuthentication.FormsCookieName || s.ToLower() == "asp.net_sessionid")
               {
                    Response.Cookies[s].HttpOnly = false;
               }
          }
     }
}

You could also roll this into a custom HttpModule to apply it across multiple applications if necessary.

Link to breaking changes document:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/aspnet.aspx

Link to HttpOnly Attribute:
http://msdn2.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx

Link to HttpModule documentation:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhttpmodules.asp

Special thanks to Shai Zohar for helping isolate the issue as well as testing the above solution.

Another SSL Termination/Acceleration gotcha in 2.0

Jorman — Sat, 04 Mar 2006 00:47:00 GMT

In 1.1, we used the requireSSL attribute to ensure that the FormsAuthentication cookie has the secure attribute set. In 2.0, if you have requireSSL set, we'll remove the cookie from the incoming request if the web server receives the cookie over a non-secure connection.

Client --> SSL --> Device --> Http --> Server

Here's the rundown of what goes on:

User logs in successfully. Cookie is created and the .secure attribute is set because requireSSL is true.
Client gets the cookie and sends it on the next request because the client's connection is secure.
The device handling SSL decrypts the traffic and sends clear traffic to the server.
The FormsAuthenticationModule checks for requireSSL being set and the connection being unsecure and removes the cookie.
When the HttpContext gest to the UrlAuthorizationModule to do it's validation based on an anonymous request and sets the response to a 401. The end result is you get redirected to the login page.

The moral of the story...if you use SSL Termination with FormsAuthentication and need to ensure the .secure attribute is set on the FormsAuthentication cookie, you'll have to do it programmatically.

Nonsecure items message using Menu control over SSL

Jorman — Tue, 07 Feb 2006 01:24:00 GMT

If you're using the new menu control that ships with ASP.NET 2.0 and SSL Termination/Acceleration, you will run into this issue. The behavior the end users will see is a warning in the browser stating something similar to:

This page contains both secure and nonsecure items.
Do you want to display the nonsecure items?

The user is browsing using HTTPS, so where is the non-secure item?

This is actually caused by the way the menu control was implemented. When you hover over a menu item, the popup menu is created using frames. For performance reasons, if the URL that the server receives is HTTP, the script that builds the popup menu uses about:blank as the default page. This is done to increase performance since the browser won't have to make another request to the web server just to temporarily populate a frame. If the server receives the URL as HTTPS, the script actually makes a request back to the server to an HTTPS address to populate the frame.

So...if you use SSL termination or SSL acceleration you end up with the following network architecture:

Client --> SSL --> Termination/Acceleration device --> HTTP --> Web Server

Even though the client is using SSL, the web server is getting HTTP traffic. As a result, the menu control does not inject the script to populate the popup using an SSL address. When the client hovers over the menu item, the popup tries to go to about:blank. This is considered a protocol transfer in IE which causes the warning to display.

That was a bit long winded, but it's good to know why your getting an message before trying to change it :)

The easiest way to get the warning to go away is to manually inject the line of script that forces the client to populate the popup using an SSL address. This would look like:

}
</script>

Debug javascript generated by webresource.axd

Jorman — Tue, 24 Jan 2006 07:01:00 GMT

Ran across this the other day and thought someone else may find it useful. Javascript for the ASP.Net 2.0 controls is typically generated by a request to webresource.axd. For example when you add a menu control, you see the following in the page:

If you browse the above URL, you get a .js file as output. If you wanted to debug this script (or other .js files) at runtime, you can use the Script Explorer included with Visual Studio 2005.

Ensure IE is setup for debugging (Internet Options | Advanced tab). After you enable debugging in IE, you must restart the browser.
Attach the debugger to the browser. You can do this by pressing F5 in Visual Studio 2005 or by using Attach to Process on the Debug menu.
From the Debug menu, select Windows, then Script Explorer (keyboard shortcut Ctrl+Alt+N). The page and script files open in the browser are displayed.
Double-click the page to open the HTML output of the page
Double-click the script file
Set breakpoints and perform an action to trigger the script

To debug inline script, you can either move the script to a .js file, use stop commands, or set a function breakpoint.

If Script Explorer is missing for you, you can use the keyboard shortcut (Ctrl+Alt+N), or add it to the IDE. Here's how to add in the Script Explorer to a toolbar or menu:

Tools menu, select Customize
Command Tab
Select Debug on the left, find Script Explorer on the right
Drag Script Explorer to a toolbar or menu