If you’ve ever had to do the "rename .Xap to .Zip" routine while doing Silverlight development, then you’ll enjoy this fix. The entry also sets the MIME type of .Xaps to "application/x-silverlight-app", so it relates to my earlier post about the MIME type, too.

I’ve been using this on my Windows Vista and Windows Server 2008 workstation, but have not tried it on XP.

XNA users: Jeff Klawiter pointed out in the comments that part of the XNA Framework uses .xap for its project file extension. So, beware. Sucks that there is overlap.

Disclaimer: Use this registry file at your own risk. I am not responsible in any way for the results. As developers like to say, "it works great on my machine!"

Download and run this registry patch: Xap.reg

Here’s the contents of the registry patch:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.xap]
"PerceivedType"="compressed"
"Content Type"="application/x-silverlight-app"
@="CompressedFolder"

[HKEY_CLASSES_ROOT\.xap\CompressedFolder]

[HKEY_CLASSES_ROOT\.xap\OpenWithProgids]
"CompressedFolder"=""

[HKEY_CLASSES_ROOT\.xap\PersistentHandler]
@="{098f2470-bae0-11cd-b579-08002b30bfeb}"

The experience before the patch:

And after:

Hope this helps!

The main method to the program; if the URL is passed in as a parameter, it will be sent to IE.

class Program
{
    static int Main(string[] args)
    {
        string url = args.Length > 0 ? args[0] : null;
        return ProtectedModeHelper.LaunchInternetExplorer(url);
    }
}

Structures that need to be defined:

IELAUNCHURLINFO (can be found in the Windows SDK iepmapi.h header file)
PROCESS_INFORMATION (used by CreateProcess, found on PInvoke.net)

Safe native methods:

ieframe.dll: IELaunchURL

Here’s the helper class and native methods that I came up with. The return value of LaunchInternetExplorer is the PID, or 0. If the machine is not running Windows Vista, then you’ll receive a NotSupportedException.

ProtectedModeHelper.cs

using System;
using System.Runtime.InteropServices;

namespace YourNamespaceHere
{
    // Engineered from iepmapi.h in the Windows SDK
    [StructLayout(LayoutKind.Sequential)]
    internal struct IELAUNCHURLINFO
    {
        public int cbSize;
        public int dwCreationFlags;
    }

    // PInvoke.net
    // http://www.pinvoke.net/default.aspx/Structures/PROCESS_INFORMATION.html
    [StructLayout(LayoutKind.Sequential)]
    internal struct PROCESS_INFORMATION
    {
        public IntPtr hProcess;
        public IntPtr hThread;
        public int dwProcessId;
        public int dwThreadId;
    }

    /// <summary>
    /// Native methods class.
    /// </summary>
    internal static class SafeNativeMethods
    {
        /// <summary>
        /// The Internet Explorer UI library.
        /// </summary>
        private const string InternetExplorerUILibrary = "ieframe.dll";

        /// <summary>
        /// Launch a URL with Internet Explorer. Works with IE's protected
        /// mode.
        /// </summary>
        /// <param name="url">The URI to navigate to.</param>
        /// <param name="pProcInfo">Process information struct by reference
        /// that will contain the opened process ID.</param>
        /// <param name="lpInfo">The launch information struct.</param>
        /// <returns>Returns a value indicating whether the native call was
        /// successful.</returns>
        [DllImport(InternetExplorerUILibrary)]
        internal static extern bool IELaunchURL(
            [MarshalAs(UnmanagedType.LPWStr)] string url,
            ref PROCESS_INFORMATION pProcInfo,
            ref IELAUNCHURLINFO lpInfo);
    }

    /// <summary>
    /// Launch a protected mode IE and provide the process ID.
    /// </summary>
    public static class ProtectedModeHelper
    {
        /// <summary>
        /// Launch Internet Explorer and return the PID. Requires Vista; an
        /// Exception will be thrown on platforms prior to it.
        /// </summary>
        /// <param name="url">The url to navigate to. Providing null will
        /// navigate the browser to the user's homepage.</param>
        /// <returns>Returns the IE process ID if successful, or 0.</returns>
        public static int LaunchInternetExplorer(string url)
        {
            if (Environment.OSVersion.Version.Major >= 6)
            {
                PROCESS_INFORMATION pi = new PROCESS_INFORMATION();
                IELAUNCHURLINFO li = new IELAUNCHURLINFO();
                li.cbSize = Marshal.SizeOf(typeof(IELAUNCHURLINFO));
                return SafeNativeMethods.IELaunchURL(url, ref pi, ref li) ?
                    pi.dwProcessId : 0;
            }
            else
            {
                throw new NotSupportedException("Protected Mode requires Windows Vista or later.");
            }
        }

        /// <summary>
        /// Launch Internet Explorer and returns the PID.
        /// </summary>
        /// <returns>Returns the IE process ID if successful, or 0.</returns>
        public static int LaunchInternetExplorer()
        {
            return LaunchInternetExplorer(null);
        }
    }
}

Hope this helps!

Earlier today I put together a super simple app to get me the PID of the protected mode and wanted to share that.

On my team, we have a test harness that handles automating the web browser. To run a test using the Silverlight Unit Test Framework, our console application needs to launch the new browser process, retrieve its process ID (PID), and then wait for completion. During this time, we also poll the process to make sure that it is still alive.

Well, if the test harness is run from an unelevated command prompt (the ideal way to run it), then we were finding that the Internet Explorer process was immediately exiting. The simple pattern was:

• Test harness launches iexplore.exe and retrieves PID 5860.
• iexplore.exe uses launches a Protected Mode process (let’s say PID 9600), and then the initial process ends.
• The test harness thought that the process had ended prematurely, even though iexplore.exe PID 9600 was actually running the test scenarios.

The simple solution was to write a simple C++ shim for Windows Vista that would use the protected mode “IELaunchURL” API (by including iepmapi.h from the Windows SDK) and simply return the protected mode PID as the application’s return value. In a failure state, it would return 0. The harness can then special case the Windows situation and use the return value PID to monitor the state of the protected mode browser.

Here’s the C++ source code that I wrote as a proof of concept. It expects that you provide the URL to navigate to as the single parameter.

#include "stdafx.h"

#include <windows.h>
#include <iepmapi.h>

HRESULT LaunchIE(LPCWSTR pszURL)
{
    PROCESS_INFORMATION processInformation;
    IELAUNCHURLINFO launchInfo;

	launchInfo.cbSize = sizeof(IELAUNCHURLINFO);
    launchInfo.dwCreationFlags = NULL;

	DWORD pid = 0;
    HRESULT hr = IELaunchURL(pszURL, &processInformation, &launchInfo);
    if (SUCCEEDED(hr))
    {
        WaitForInputIdle(processInformation.hProcess, 2000);
		pid = processInformation.dwProcessId;
		CloseHandle(processInformation.hProcess);
        CloseHandle(processInformation.hThread);

		return pid;
    }
    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
	if (argc == 2)
	{
		return LaunchIE(argv[1]);
	}
	return 0;
}

Download the 32-bit StartInternetExplorer.exe application. Note: This is totally unsupported, use at your own risk, all that jazz. This isn’t a utility I’m using any longer, but did want to share since I didn’t find a whole lot of information on the web.

If building in Visual Studio, you should also modify the C++ project properties (under the Linker) to include the additional dependency of iepmapi.lib.

Hope this helps!

Simply open up the date/time settings in the taskbar to add additional clocks.

Last week a lot of my hard work was saved by Windows Vista and its updated System Restore capabilities.  There are a lot of features hiding in Vista that not everyone is aware of, and this is one of those that is a real lifesaver but hidden away with that right mouse click.

While cleaning up an enlistment to some code, I accidentally permanently deleted a very large tree that included some important code changes, representing a few hours of work over two days on refactoring.  “Oops.”  At this point, my first instinct was to run to one of those great undeleted tools such as HandyRecovery… Until Windows actually recovers and overwrites the data on the drive, your deleted data is really still sitting there waiting to be reused.

However, I then remember that Volume Shadow Copy Service (or some form of it) had been meshed together with System Restore, and should be running on the machine.  Thankfully it was, and it is really pretty easy to use—you can restore to a previous version, or simply save the previous version elsewhere.

To use the tool, simply right-click on a file that you would like to examine previous versions of, and select ‘Restore previous versions’.  If you’ve deleted an entire directory or directory tree like I have, right click on the parent directory and start from there. 

Everything was right where I’d remembered it, no data lost, and a big feeling of relief (and thanks to the Windows client guys).

Technical details: http://channel9.msdn.com/ShowPost.aspx?PostID=286303 (Channel 9 video)
Marketing speak: http://www.microsoft.com/windows/products/windowsvista/features/details/shadowcopy.mspx 

[/RAW]

If you have a need to install the full version of IIS 7.0 (all features, options, and modules—including ASP.NET 2.0), you can do this from the command line using the new Package Manager tool as an alternative to the Add/Remove Windows Features interface.

Simply execute the following from an elevated command prompt (it will also output a log file, that’s an optional parameter only):

start /w %windir%\system32\pkgmgr.exe /l:logStep.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

This should work with Windows Vista Business, Enterprise, and Ultimate SKUs.  On x64 machines, you’ll want to make sure to execute this from an elevated 64-bit command prompt.

Background:
A useful new feature of IIS 7 is its componentization; if you don’t need a particular feature of the server, such as CGI, simply exclude it.

Often while performing testing or preparing a development workstation, using pkgmgr.exe can save a little time if you’re looking for all the features.  You can also modify the parameters to leave off specific features.

Update:
Looks like there’s finally a document on this at the IIS web site as well, so if you’re using Home Premium or want to learn more about pkgmgr.exe, check out the article at http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=958.

[/RAW]

There’s a helpful article at the IIS.NET site detailing a lot of what it means to upgrade your developer workstation to Vista, what changes IIS 7.0 brings, and ASP.NET application compatibility.  Direct link to the article.

The most important content in this article, in my opinion, is that which outlines the specific ASP.NET changes.

Here is the list of known changes with IIS 7.0 at this time:

• In Integrated mode, Application_OnError is not called for exceptions that occur in HttpApplication::Init
• Server.ClearError in EndRequest does not clear exception message in Integrated mode
• Integrated mode applications may write to a response in EndRequest after an exception has been formatted and written to the response
• In Integrated mode, ASP.NET no longer suppresses the content type when the response is empty
• Different windows identity in Forms authentication
• Default Authentication_OnAuthenticate event does not raise in Integrated mode
• In Integrated mode Request.RawUrl contains the new query string after RewritePath is called
• Passport Network credentials authentication is not supported in Windows Vista
• PassportAuthentication module is not part of the Integrated pipeline
• Large, valid forms auth tickets (length <= 4096 bytes) present in the query string are rejected by IIS 7.0
• In Integrated mode, the ASP.NET request time-out is applied multiple times during the request, allowing the request to execute longer
• Trace settings are not transferred to Server.Transfer target page
• The method Httpcontext.Current.Response.Write() cannot work in Application_Onstart()
• HttpRequest.LogonUserIdentity throws an exception when accessed before PostAuthenticateRequest
• In Integrated mode, ASP.NET modules will receive the first unauthenticated request to IIS when Anonymous authentication is disabled
• ASP.NET cannot impersonate the client identity until PostAuthenticateRequest
• Content-Type header is not generated when charset and content type are set to empty string
• In Integrated mode, both synchronous and asynchronous events raise for each module before the next module executes
• Response headers are removed in Integrated mode after calling ClearHeader in a custom IHttpModule
• Using Windows and Forms authentication together in Integrated mode is not supported
• In Integrated mode, IIS always rejects new lines in response headers (even if ASP.NET enableHeaderChecking is set to false)
• PreSendRequestHeaders and PreSendRequestContent events will raise together for each module
• The ordering of modules is reversed for PreSendRequestHeaders and PreSendRequestContent when using Integrated mode
• In Integrated mode, threading and queuing settings in are ignored
• If a configuration file error is encountered when using Integrated mode, IIS, not ASP.NET, generates the error message
• In Integrated mode, ASP.NET applications must subscribe to pipeline events during a module’s Init call

[/RAW]

Vista ships with .NET Framework 2.0 in the box, but ASP.NET v1.1 is still fully supported if you need it-and here’s how.

If you’re trying to diagnose this problem, the error message you will receive without allowing v1.1 is a 404.2 – Not Found; the description is “the page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.”

Install .NET Framework v1.1 & v1.1 SP1

Prerequisite: You have installed IIS on the machine already (Control Panel – Add/Remove Windows Features)

• Download and Install .NET Framework v1.1
• Download and install v1.1 Service Pack 1

Enable ASP.NET v1.1 in InetMgr

Run “InetMgr” (even though the Run menu’s not in the Start Menu by default, you can still reach it by pressing [ Windows key ] + [ R ])

Click on your computer name in the tree, not the web site. This should be the top-most tree element. Double-click on “ISAPI and CGI Restrictions,” this is an icon in the center of the screen within the IIS group.

Right-click on the ASP.NET list item entry and “Allow” it. You do not need to reset the web server.

You can also do this from an elevated command prompt using AppCmd.exe:

%windir%\system32\inetsrv\appcmd set config -section:isapiCgiRestriction /+.[path='%windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll',allowed='true']

Creating v1.1 Applications

Another obvious note, within the IIS Manager, you need to specify the application pool of choice when adding a new application. There is no concept of a v1.1 “integrated” mode, so your choices with v1.1 installed are: Integrated Pipeline 2.0, Classic/ISAPI 2.0, and Classic/ISAPI 1.1.

Simply select the v1.1 application pool and you’re good to go!

[/RAW]

With the release of Windows Vista, the next generation Microsoft Platform for web developers looking to explore better integration between their applications and the web server. We’ve logged many hours over the last year making sure that the ASP.NET and IIS 7.0 experience is a success story, and I wanted to open by introducing the new integrated mode and diving into some of what went on for the test team to bring the release to you.

Integrated Mode: ASP.NET + IIS

ASP.NET 2.0 shipped in October 2005 and was full of useful features, but on IIS 6 it still executed like a well-oiled Perl script would have a decade ago. For the most part, it sat on top of the web server, relying on an archaic native interface (ISAPI) to make it all happen. Simply enabling Windows authentication took two steps: One enabling it in the IIS manager, and the other configuring it your web.config file.

With Vista, all this is in the past: Handler mappings, authentication … it’s all a single story. One step to get a task done, a great new administrative interface to go with it. Being familiar with the work that’s gone on to make managed code a first-class citizen with IIS, I intend to use this blog as a place to share that experience.

I don’t intend to duplicate the great resources already online, so as a starting point, if you’re new to all this, please check out:

• Mike Volodarsky’s “server-side” blog
• IIS.Net community site run by Microsoft, specifically the IIS7 technical resources overview
• The IIS discussion forums or ASP.NET forums, the best place to get your questions answered

Testing: Automation updates, new tools, overall process

Testing ASP.NET, IIS, and Windows Vista together was a lot of work. It consisted of automation improvements, using new product features, adding test coverage, fixing test cases, and analyzing hundreds of thousands of automation results. Here’s a little bit of the behind-the-scenes work that happened from my perspective.

We rely on automation so much on the ASP.NET test team that it was critical to get our tests running on the new OS as soon as possible. Being able to kick off tests to run overnight means that I can devote the day to everything else: Resolving and fixing bugs, learning about and providing feedback on the product, and working on other exciting projects. This wouldn’t be possible without the large automation infrastructure we have in place. Scott Guthrie’s testing post a few years ago really provides a great look at what’s involved in our testing.

Integrated and classic application pool types

As you can now place ASP.NET applications in either the IIS7 Integrated application pool or the Classic/ISAPI pool, we expanded the scope of our tests to run in both the integrated and classic modes. The default application pool type is now integrated; however, the classic mode is still around for compatibility, ASP.NET 1.1 SP1 applications, and other scenarios. If you’re impacted by a breaking change in the integrated mode, you can always just flip the application into the classic pool.

Expanding the possible contexts for all our tests to run in both modes meant more test results would be generated for each run, but the cost in additional time for execution is made up for by the presence of historical data and side-by-side results. Having results for the same underlying test, running into both pipeline modes, was really helpful for identifying bugs.

They weren’t all bugs either, some differences were as verifying the new IIS 7 error messages.

User account control

The sweeping security improvements within Windows Vista made automation a little more difficult at first (that’s a good thing). Instead of just modifying some registry values to open the necessary firewall ports, changing a configuration file, or running a set of batch files, we had the fun challenge of interacting with User Account Control (UAC). Even though ASP.NET is a server-side process, our automation system is full of tools that run within the context of an end user session. Elevation to administrative privileges is needed for reimaging machines, configuring the product, and running tests. It took a lot of hard work by many people within the company to get us to where we are today.

New tools like AppCmd

The Microsoft philosophy of testing your products using your products is pretty fun at times. A good example that I have is the ability to take a snapshot of the web server configuration files with IIS 7—I can’t tell you how many times I use an older Windows 2003 machine and wish I could use this feature.

The AppCmd tool, located at %windir%\system32\inetsrv\appcmd.exe, is a great command-line interface to the web server. When we initially install IIS on a Vista machine, the scripts make a backup of the important IIS configuration files by calling “appcmd add backup Initial”. “Initial” is just the unique name for the backup. If you ever destroy the configuration files, you can simply issue an “appcmd restore backup Initial” command and you’re back in business, without having to examine what you did incorrectly.

Testing Process

Finally, there was the actual testing experience that had to happen. Part of the process:

• Creating a new run with a set of tests and the contexts in which they execute
• Cross your fingers, hoping that the machines install Vista, the product, and come back online
• Waiting as thousands of tests execute and log their results
• Spending days investigating fun new Vista changes, improvements, bugs, fixing tests, and fixing the product
• Repeat!

We frequently performed “nightly” tests, which consist of the highest priority automation, along with a combination of Vista SKUs, product types, and languages. Test the SDK one week, and the full Visual Studio the following week; English, Arabic, Japanese, German; AMD64, x86, the list goes on!

Before each significant Vista milestone, we signed off by performing a major full automation test pass on the product. This was a major undertaking: one such test pass lasted a month and really pinpointed the work that needed to be done to finalize ASP.NET on Vista. If you haven’t already given the new IIS a try, run the IIS Manager after installing Vista and the web server, and try the “new” ASP.NET.

In Closing

I’m really proud of the quality of our product and hope that you find the new features and improvements really helpful in your work. Between the union of IIS + ASP.NET and the ASP.NET AJAX story, there are some great reasons to use the Microsoft platform today. And you can still use PHP too!

Please let me know if you found this useful.

[/RAW]