Visual Studio .NET 2003, ASP.NET v1.1, and Windows Vista

I recently needed to make a .NET Framework v1.1 application work on Windows Vista, which meant debugging it and running the development environment on a Windows Vista Business machine.

While quite possible, it did give me some headaches.

Enable the IIS 7 Product Feature

Obviously, if you need to work with ASP.NET applications, you need IIS. Windows Vista comes with IIS 7, which is vastly different from the IIS 6 architecture.

You can install IIS 7 from the "Programs and Features" control panel, under "Turn Windows features on or off." I recommend choosing all the items under "Internet Information Services" : "Web Management Tools" : "IIS 6 Management Compatibility" when you install the rest of IIS.

Install Microsoft .NET Framework v1.1

Windows Vista does not come with v1.1 of the framework pre-installed. Instead, you need to download and install these packages:

• Microsoft .NET Framework v1.1
• Microsoft .NET Framework v1.1 SP1

When installing, be sure to right-click on the install package and select "Run as administrator."

After you're done installing these packages, run the command prompt as administrator, and then CD to C:\Windows\Microsoft.NET\Framework\v1.1.4322. Run the following command:

aspnet_regiis -ir -enable

Install Visual Studio .NET 2003

This is the easy part. Visual Studio .NET 2003 will work on Windows Vista, but it's a bit quirky. First off, the installer won't be able to install all of the prerequisites (specifically FrontPage Extensions). I was able to skip that part and install just fine, however. Make sure when you install, you right-click on the installer package and select "Run as administrator." Install Visual Studio .NET 2003 Service Pack 1 as well.

After it's installed, Visual Studio .NET 2003 will fail to run in its default state. Unfortunately, you have to run it with elevated privileges. In order to do this every time without right-clicking and selecting "Run as administrator," follow these steps.

• Right-click on the "Microsoft Visual Studio .NET 2003" shortcut and select "Properties."
• On the "Shortcut" tab, click "Advanced..."
• Check the box that says "Run as administrator."
• Click "OK" until you're out of the shortcut properties.

Change IIS Settings to Accommodate ASP.NET v1.1 Applications

This is the part I got hung up on. I kept getting strange errors when trying to open web applications under Microsoft Visual Studio .NET 2003, mostly it thinking that the virtual directory was a v1.0 application. To enable ASP.NET v1.1, you need to do the following:

• Open Internet Information Services (IIS) Manager.
• Highlight your local server. In the Features View, locate the IIS section and double-click "ISAPI and CGI Restrictions."
• Right-click item "ASP.NET v1.1.4322" and click "Allow."
• Highlight the virtual directory for your ASP.NET v1.1 application or the entire web site it's under.
• Right-click on the highlighted item and choose "Advanced Settings..."
• Under "Behavior", change the item "Application Pool" from "DefaultAppPool" to "ASP.NET 1.1."

At this point, you should be good to go.

"The project you are trying to open is a Web project. You need to open it by specifying its URL path."

I hate it when I get this error even when I am opening the project from a URL. Luckily, there's a simple solution.

In the same folder as the project file (.csproj or .vbproj) of the web project you are trying to open, make a new file with the same name as the project file with .webinfo tacked on the end.

Thus, if you have a project called MyWebProject.csproj, you create a new file called MyWebProject.csproj.webinfo. In that file, it needs a short XML snippet:

<VisualStudioUNCWeb>
    <Web URLPath="http://localhost/MyWebProject/MyWebProject.csproj" />
</VisualStudioUNCWeb>

Obviously, you need to replace the URLPath value with the actual value for your web project file. Once you have this hint in place, Visual Studio should be able to load your web project without a hitch.

This seems to be Visual Studio .NET 2003 problem. I've not seen it manifest itself in Visual Studio .NET 2005 yet.

Merge Modules

In my previous post, I mentioned a method for automating the addition of features (specifically properties) to a Windows Installer package generated by Visual Studio. After doing some more research, I encountered the wonderful land of merge modules.

Merge modules are just what they sound like; they allow you to merge features into a Windows Installer package that you are creating. Among other things, you can set default properties by including a Property table in the merge module.

Creating a merge module is not difficult but requires a bit of knowledge. Once again, you need the lovely Orca tool from the Windows Platform SDK.

Orca, from what I found, doesn't seem to be able to create a blank merge module template. So I had to do it by hand. Starting with a blank new file, you will need to add the following schema:

Table	Column	PK	Type	Nullable
Component	Component	X	String (72)	N
	ComponentId		String (38)	Y
	Directory		String (72)	N
	Attributes		Short Int	N
	Condition		String (255)	Y
	Key Path		String (72)	Y
Directory	Directory	X	String (72)	N
	Directory_Parent		String (72)	Y
	Default_Dir		Local String (255)	N
FeatureComponents	Feature_	X	String (38)	N
	Component_		String (72)	N
ModuleComponents	Component	X	String (72)	N
	ModuleID	X	String (72)	N
	Language	X	Short Int	N
ModuleSignature	ModuleID	X	String (72)	N
	Language	X	Short Int	N
	Version		String (32)	N

Some of these tables are predefined in Orca, so you won't need to enter all of them by hand. Most of the tables don't actually have to have data, they just need to exist for the file to be considered a valid merge module.

The only table that requires data is the ModuleSignature table. It must contain at least one row identifying the merge module. The format for the ModuleID is a GUID separated by underscores (_). The Language is 1033 for US English; you will need to look this code up if you are using other locales. Version is the typical Windows Installer version format: n.nn.nnnn.

Once you have that basic structure in place, you can enter your additions into the merge module. The merge module can have pretty much anything a full install package can have. Once you're done, save the file with a .msm extension. You can then go in to Visual Studio and add the merge module to your deployment project.

Technically, there is one more thing you really should have in your merge module: a _Validation table. While not strictly necessary for use, this table is used by Orca to run validation against the merge module.

One caveat I did find with using a merge module to preset properties in deployment project builds: you can't use a merge module to override existing entries in the Property table. You can only create new properties. I was able to get the majority of the setup I wanted done automatically, I still have to go in a manually edit my final .msi file to accommodate all of my requirements.

Working with Setup projects

One thing I don't have much experience with is the Setup project type in Visual Studio. Most of my previous experience comes from writing web applications, so there was no real need to write an installer package.

But now that I've been tasked over the past 6 months or so with writing a desktop application, I've had to learn a lot of new tricks. The Windows Installer is one of those tricks. Unfortunately, the documentation for the actual Setup project type itself is rather abysmal and mostly just links into documentation for the Windows Installer SDK.

So today I was trying to figure out how to set default values for my custom properties. Unfortunately, the interface inside Visual Studio has no means for doing this. I did some reading, and I found that the tool I want is called Orca.

Orca is part of the Windows Platform SDK. It's no small download, but it contains lots of useful tools and documentation, of which the Windows Installer SDK is a part. Orca is a handy little editor that lets you modify the tables inside a .MSI package (among other things).

To set defaults for my properties, I just compile my .MSI package as normal within Visual Studio. Then I can open it with Orca, go to the "Property" table, and create the properties I need.

One thing to note as well: the case of properties makes a difference. A property that is in all uppercase (like PROPERTYNAME) is considered a "public" property; public properties can be adjusted at install-time using command line switches, like follows:

msiexec /i Example.msi PROPERTYNAME=VALUE 

A property with at least one lower case letter (like PropertyName) is considered "private" and cannot be modified at install-time by the user.

There's also another type of property you might find useful, called "restricted public." These are just like public properties, except that their values can only be modified by a system administrator. To make a restricted public property, just define it as a public property. Then, create a new property called SecureCustomProperties (or edit it if it exists). Set the value of this property to the names of the public properties you want to restrict, separated by semicolons if there is more than one.

Anyways, thats' the basic run-down. In the future I'm going to look into ways to automate this process.