Van Kichline's WebLog

Web Application Projects Add-On Installation Issue/Solution

vank — Sat, 11 Nov 2006 02:18:00 GMT

Issue: A small set of users installing the Visual Studio 2005 Web Application Projects Add-On experience the following installation error:

Unable to get installer types in the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Microsoft.VisualStudio.Web.Application.dll assembly. --> Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

When this occurs on a given machine, it will re-occur every time the user attempts to re-install. Users have attempted uninstalling Visual Studio 2005, Visual Studio 2003, and other applications and patches without having any effect. Other machines in the same office will install fine from the same MSI file.

Cause: The root cause of this problem has not been found. It is rare and we have not been able to reproduce it locally. Information gathered about affected machines do not indicate any outstanding common factors. The effective cause if the failure of a Custom Action at the end of the installation sequence which is intended to invoke Visual Studio with a command switch which will set up the templates which were just installed.

Work-Around: Since this is the last action in the installation sequence, and there are no Custom Actions triggered by “commit”, it is possible to work around this error by disabling installation rollback. At this point of the installation all code and data has been installed, and all registration is complete. The trick is simply to skip the rollback caused by the failure of the Custom Action, and then to execute the equivalent manually.

Note: only use this workaround for the exact issue describe above. Disabling rollback of installations is not generally recommended! It is acceptable in this case because the error occurs as the last action in the installation.

Install the update from the command line:
msiexec /i WebApplicationProjectSetup.msi DISABLEROLLBACK=1
(Note that the case of DISABLEROLLBACK is significant.)
Reboot the computer.
Open a command window and execute:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe /setup
(Adjust as necessary for your installation location.)
Start Visual Studio and verify that the menu command New|Project.. displays a Web node under both the Visual Basic and CSharp nodes in the left-hand pane. Create an ASP.Net Web Application and ensure that it will compile and run.

Let me know if you experience any problems with this approach, or have any information that might help lead to the root cause.

DHTML Editing Control for Applications (Windows Vista Version) Installer Update

vank — Tue, 26 Sep 2006 00:09:00 GMT

A while back I posted that there were some minor problems with the DHTML Editor Control for Windows Vista (which we've finally abbreviated as DECA-V internally.) We've corrected these and updated the download in-place.

The changes include:

Full UI sequence for Administrative Install
Administrative Install will run on any NT system. Package install will only run on Windows Vista or later systems.
Full Windows Vista Logo compliance

It's not much, but if it's what you need, it's tested and available now.
Since the file name is the same, if you've downloaded DhtmlEd.msi before you should clear your cache to ensure that you get the newest version. You can verify that you have the correct version by displaying the MSI's properties, clicking on the "Digital Signatures" tab, and verifying that the file was signed on September 18, 2006.

Setting scriptmaps: automation

vank — Wed, 13 Sep 2006 19:04:00 GMT

The articles below describe how a Web Setup Project can be modified to set scriptmaps for the website it installs. This article describes the script used to automate this modification. The script is attached to "How to set scriptmaps in a Web Setup Project" in "Scripts.zip" and is named "AddSetScriptMaps.wsf."

This began as a simple JScript for experimenting with the Installer Automation Interface and was later adapted to add MSI entries to a short-term project. When I prepared to add it to this posting, it looked like one of those awful examples which leave error handling as an "exercise," so I spent some time fleshing it out and making it more versatile. The result is a script that can easily be modified to make additions to any MSI file. Deletions and modifications are error conditions, but if you refer to the Automation Interface Documentation these would be easy to add. Be careful; removing an entry from an MSI should be done only with great care.

If you examine AddSetScriptMaps.wsf, you'll see that it's a JScript file packaged in Windows Scripting Host format. I've ID'd each section of the script primarily to make it easier to talk about; this provides an unambiguous means of referring to a segment of a script without having to break it up into multiple files.

The first section, <runtime>, is simply documentation. If you run the script with a "/?" parameter this information will be neatly printed. Any script included in a build process should implement "/?"; it provides a quick check to ensure that the tool does what you think it will.

The first script section, ErrorCodes simply defines the different values that could be returned in the command shell's "errorlevel" by running the script. Each failure point returns a unique error code to make it simple to detect what went wrong. Documenting these errors at the top of the script is logical since it's the one thing users are likely to be searching for after initial configuration is complete.

The Constants script section is just a hold-over from C/C++ coding style. Unfortunately JScript does not support constants, but the section ID helps clarify the intent.

The "UtilityFunctions" script section is also self-explanatory. It provides two routines for reporting errors and exiting the script, and one for returning the path to the directory the script resides in. This is similar to the "%~f" parameter modifier in batch files.

The TableUpdater script section defines a JScript object which is instantiated with an MSI table name, a list of field names, and an Array of Arrays of strings defining the rows to be added. (If you didn't know, or had forgotten, that JScript can be object oriented, check the docs. It's not Ruby, but it's better than VBScript.) The Table Updater includes two member functions; QueryString (which would be protected if JScript supported this) and UpdateTable, which adds each row defined in the Additions Array to the specified table. While the parameter which describes the fields could have been eliminated, I decided to leave it in place. Updating is done through a View, and it's entirely possible that future uses of this script might include updating a table with many fields, most of which are left empty. Specifying the fields to use in the view makes this much simpler. Let me know if you find that this was a poor choice.

The QueryString function simply constructs the query required for the call to OpenView. Windows Installer uses a syntax similar, but not identical, to SQL. It's documented in the Automation Interface Reference. The format of a typical query would be similar to:


INSERT INTO 'AppSearch` (`Property_`, `Signature`) VALUES (?, ?)

UpdateTable opens a View with the query constructed above. Then for each addition defined in its Array it creates a record with the appropriate number of fields, sets the value of each field, and calls Execute on the View with the record as a parameter. This executes the parameterized query used in opening the View and inserts the record into the current transaction; it's not written to the MSI until committed later in the process. After the last record is added, the View is closed.

The BinaryUpdater script section handles additions to the Binary table, so no table designation is required. The value of the Name field and a name of a file containing the binary data are required for each addition. The path name is considered to be relative to the location of the script itself, so if they are both in the same directory this field would be only the file name. The UpdateBinaryTable method pushes the addition to the MSI.

UpdateBinaryTable creates a record with a single field and then calls SetStream on this field with the full path to the file name provided. Note that the ScriptPath utility function was used in the constructor to generate this. A View is opened on the binary table with the query:


INSERT INTO `Binary` (`Name`, `Data`) VALUES (this.Name, ?)

View.Execute is called with the record created above, which reads the stream from the file into to MSI file's pending transaction. Finally the View is closed.

The MsiUpdater script section implements the main worker object. It's constructed with the MSI name, and the single "public" method PerformUpdate takes an Array of TableUpdaters and Array of BinaryUpdaters, opens the MSI, calls each TableUpdater and BinaryUpdater to add their changes, and then commits the changes.

Opening the MSI requires creating a WindowsInstaller.Installer ActiveX object. We open the database by calling the OpenDatabase method on this object, passing the path to the MSI and the mode parameter; in this case "transaction mode," which permits write access and transaction batching. After the additions have been processed, database.Commit writes them to the MSI. Strangely, there is no database.Close in the API, but the MSI is closed when the ActiveX object is released.

The UpdateDataSection contains only data, and is of particular interest because this is the section you'd change to modify the script's behavior. I've broken out the Component GUID for aspnet_regiis.exe because you might be interested in updating to a different set of script maps in the future, requiring a different GUID. I've also define the sequence #s of the three Custom Actions in the InstallExecuteSequence because these are dependant on how the default InstallExecuteSequence is produced by the Web Setup Project, and it's conceivable that this could require modification under some circumstances or in future releases. The rest of the section is simply the definition of a tableUpdates Array and a binaryUpdates Array. Each is an Array of the appropriate constructors. The example provided should make it simple to define additional tables if you have similar but different needs.

Finally, the MainSection script section checks the script parameter, creates an MsiUpdater, calls PerformUpdate on it passing the data we defined in the previous section, then prints a completion message and returns a non-error result.

As stated in the first article in this series, if you add something like:


CScript "..\scripts\AddSetScriptMaps.wsf" "$(BuiltOuputPath)".

...to the PostBuildEvent property of your Web Setup Project, you'll have your MSI modified to install scriptmaps automatically when built. You can also modify the script to make other additions. If you're considering making additional modifications to Web Install Projects, I'd be interested in hearing about them (and whether this approach is helpful in making them.)

Setting scriptmaps: step three

vank — Wed, 13 Sep 2006 01:15:00 GMT

We've set two installer properties: REGIISPATH contains the full path name of aspnet_regiis.exe, and SRVRPATH contains the IIS metabase path to the new virtual directory. If any failures occurred, then REGIISPATH is empty.

With this data in hand, it's simple to set the scriptmaps for the site. We add one more standard Custom Action:

Action	Type	Source	Target
SSMCA_SetScriptMaps	50	REGIISPATH	/S [SRVRPATH]

... which tells the installer to execute the already installed exe specified by REGIISPATH and pass it the command line specified by the formatted string in the Target field; the "/S" switch followed by our server path. We ensure that this will be executed in the right sequence and under the proper conditions by adding the following to the InstallExecuteSequence table:

Action	Condition	Sequence
SSMCA_SetScriptMaps	REGIISPATH	6500

...which again effectively re-applies the conditions from the earlier sequence entry which set the REGIISPATH property:


REGIISDIR AND NOT (REMOVE OR (ACTION~="ADMIN"))

...indicating that the desired version of aspnet_regiis.exe was found, the installer is not uninstalling, and an administrative install is not being performed. If you watch carefully when you run your modified MSI, you'll see a command interpreter window pop up and display the aspnet_regiis command for a moment near the end of your installation. If you're concerned about suppressing this display, it's possible and is left as an exercise for the reader (try 'start /?' to begin with) but your customers are web server administrators and may not be as disturbed by the command window's brief appearance as a typical user might be.

Now your Web Site Installer project will set ASP.Net v2.0 scriptmaps automatically when the website is installed, and you not only understand how its done but how to troubleshoot any problems which may crop up by gathering verbose installation logs and comparing them to your baseline log file. Errors should be pretty obvious. Please let me know if you find something which needs to be changed.

Next we'll look at the script which performs this modification.

Setting scriptmaps: step two and a half

vank — Tue, 12 Sep 2006 22:17:00 GMT

To register the scriptmaps for our new web site in the Web Setup Project's MSI, we need to convert the available strings "/LM/W3SVC/1" and "WebSite1Setup" into the form "W3SVC/1/ROOT/WebSite1Setup". As simple as it sounds, we need to write a custom action to remove something from an existing string. There are a number of Custom Action Types that we could use to accomplish this:

Type	Description
1	CA in a binary DLL stored in Binary table
2	CA is an exe store in Binary table
5	CA is JScript stored in the Binary table
6	CA is VBScript stored in the Binary table
17	CA in a binary DLL installed with product
18	CA is exe installed with the product
21	CA is a JScript installed with the product
22	CA is a VBScript installed with the product
37	CA is a JScript with the content in the Target field
38	CA is a VBScript with the content in the Target field
50	CA is an existing exe already on the machine
53	CA is a JScript with the content in a Property value
54	CA is a VBScript with the content in a Property value

While Custom Actions written in script are not generally recommended, the specific requirement for this case is so simplistic that it seems appropriate to use JScript instead of C++. Script is actually better suited to manipulating strings than is C++, and this is not a case where we need to do any more than trivial error handling. If we were instantiating a COM object or doing any more processing than called for here, we'd use C++ or C#, but in this case the right tool for the job looks like JScript.

While we have a number of ways to store the script code in the MSI, using the Binary table (type 5) was the simplest to implement with the script employed later by the PostBuildEvent to update the MSI. Data stored in the Binary table is generally not installed on the target machine; it's for internal use by the MSI. The same code could easily have been employed in type 37 or type 53 Custom Actions.

Here's the script used to build the parameter we need for aspnet_regiis:


Log("Entering CA_SetServerPath");
var strLM = Session.Property("TARGETSITE");
var strVDir = Session.Property("TARGETVDIR");
Log("TARGETSITE = " + strLM);
Log("TARGETVDIR = " + strVDir);
if(0 == strLM.indexOf("/LM/"))
{
 strSrvrPath =  TerminateWith(strLM.substr(4), "/");
 strSrvrPath += "ROOT/" + strVDir;
 Session.Property("SRVRPATH") = strSrvrPath;
}
else
{
 Session.Property("SRVRPATH") = TerminateWith(strLM, "/") + strVDir;
}
Log("SRVRPATH = " + strSrvrPath);
Log("Exiting CA_SetServerPath");

function Log(str)
{
 var rec = Session.Installer.CreateRecord(2);
 rec.StringData(1) = str;
 Session.Message(0x04000000, rec);
}
function TerminateWith(str, termChar)
{
 if(str.charAt(str.length-1) != termChar)
  str += termChar;
 return str;
}

We access the properties with Session.Property and employ a function to ensure that there's a trailing "/" on the TARGETSITE property. While our sampling of the log file indicated that we need not expect this, it's highly advisable to make few assumptions and play it safe in a Custom Action. If our TARGETSITE string doesn't match the format we expect at all, we fall back on just combining the two strings.

Note that we also log enough detail to verify our assumptions and explain our results. If something goes wrong with our registration of scriptmaps it's likely to go wrong here, and without explicit logging we get very little information to help us troubleshoot. With the calls included we get output which is easy to locate in the log file, and which includes information that ensures this CA worked as expected, or reveals where errors occurred.

On completion this CA creates the property SRVRPATH and sets its value. Note that the property did not need to be declared in advance or initialized in the Properties table. To set up this step in the installation process, we need to add the Custom Action:

Action	Type	Source	Target
SSMCA_SetServerPath	5	SetSrvrPath

The Binary table entry:

Name	Data
SetSrvrPath	[Table Data] *

* More on this later in the section describing the script

And the InstallExecuteSequence entry:

Action	Condition	Sequence
SSMCA_SetServerPath	REGIISPATH	6475

This schedules the action after the SSMCA_CreateRegIISPath Custom Action described in part 1 and executes it only on the condition that REGIISPATH was set by that Custom Action, effectively duplicating the conditions of the earlier CA.

Now, if we're installing, and it's not an Administrative Install, and Remove is not being executed, we finally have a property containing the location of the utility application which will set the scriptmaps, and another property which contains the path to the website to be registered. We're ready at last.

Setting scriptmaps: step two

vank — Tue, 12 Sep 2006 18:10:00 GMT

Now that we know how to call aspnet_iisreg.exe all we need is its parameters. Executing aspnet_regiis /? indicates that we want:


-s <path>
Install scriptmaps for this version at the specified path, recursively.
E.g. aspnet_regiis.exe -s W3SVC/1/ROOT/SampleApp1

By this point in the install process, we already have properties set for us from the UI or the command line for TARGETSITE and TARGETVDIR. TARGETSITE takes a form like "/LM/W3SVC/1", and TARGETVDIR is something like "WebSite1Setup". How do we know that? All you have to do is run the original installer with verbose logging, and then examine the log file:

msiexec /i WebSite1Setup.msi /l*v LogFile.txt

This will write tons of information to the log file, and you'll find lines like:

MSI (c) (48:A4) [13:44:02:685]: Switching to server: TARGETDIR="C:\inetpub\wwwroot\WebSite1Setup\" TARGETVDIR="WebSite1Setup" _CFA818CA6DA647A5AF4DFFEA95FD19C1="C:\inetpub\wwwroot\WebSite1Setup\bin\" IISVERSION="#5" ALLUSERS="1" TARGETSITE="/LM/W3SVC/1" _F363883C8B9A46F08810E19D4D9A7B27="C:\inetpub\wwwroot\WebSite1Setup\App_Code\" REGIISDIR="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\" CURRENTDIRECTORY="C:\Documents and Settings\vank\My Documents\Visual Studio 2005\Research-WebSetup" CLIENTUILEVEL="0" CLIENTPROCESSID="2376" USERNAME="VanK" COMPANYNAME="Microsoft" SOURCEDIR="C:\Documents and Settings\vank\My Documents\Visual Studio 2005\Research-WebSetup\" ACTION="INSTALL" EXECUTEACTION="INSTALL" ROOTDRIVE="C:\" INSTALLLEVEL="1" SECONDSEQUENCE="1"  ADDLOCAL=DefaultFeature

This is effectively a dump of all the public properties at this state in the installation, and is a quick and handy way to find out what we have to work with. Note that TARGETSITE is set when the user selects from the "Site" dropdown in the UI (assuming that we have more than one "web site" running on our web server) and TARGETVDIR is the Virtual Directory which the user entered in the text box of the dialog. So, all we have to do is combine the two with a slash in between, and we have our parameter!

Try it on the command line first:

aspnet_regiis /s /LM/W3SVC/1/WebSite1Setup

...and you get:

Start registering ASP.NET scriptmap (2.0.50727) recursively at /LM/W3SVC/1/WwebSite1Setup. Installation stopped because the specified path(/LM/W3SVC/1/WebSite1Setup) is invalid.

What? Refer back to the /? output and we see the example includes /ROOT/; maybe that's it! Try:

aspnet_regiis /s /LM/W3SVC/1/ROOT/WebSite1Setup

...and we get the same unfortunate result. To make a long story short, it's the leading "/LM/", which stands for Local Machine. What we require is:

aspnet_regiis /s W3SVC/1/ROOT/WebSite1Setup

It would have been very nice for our purposes if aspnet_regiis ignored the leading "/LM/", but instead it returns an error. To register the scriptmaps we need to strip part of this string off, but unfortunately there's no built-in Custom Action that performs this kind of service for us. We have to write our own.

Setting scriptmaps: step one

vank — Tue, 12 Sep 2006 00:38:00 GMT

The first step in setting the proper scriptmaps is to decide what method we'll use to set them on the target machine at install time. While there might be several ways to do this, the simplest and most direct is to execute the tool aspnet_regiis.exe which was installed with the .Net 2.0 Framework, and the simplest and most direct method is always best with installation. Each framework has its own version of aspnet_regiis.exe, and there may be several frameworks installed, so it's critical that we find the right one. Windows Installer provides an AppSearch function for doing this.

We need to add a new AppSearch entry to the MSI. If you crack open your unmodified MSI with Orca, you'll see that there's already one AppSearch entry:

Property	Signature_
IISVERSION	__EBAF7BE89E354100ACD2C1841DCBEEEC

This searches the registry for the value of the installed Internet Information Server's major version number, then assigns that number to the installer property IISVERSION. It uses a RegLocator table entry to accomplish this; the key is the value of the Signature_ field, and the registry neatly contains the major version number of the installed IIS:

Signature_	Root	Key	Name	Type
__EBAF7BE89E354100ACD2C1841DCBEEEC	2	SYSTEM\CurrentControlSet\Services\W3SVC\Parameters	MajorVersion	2

We don't have a handy registry key to locate the file we're interested in, and guessing the path to the correct version could be quite tricky, so we use an AppSearch referencing a CompLocator table entry instead by adding this row to the AppLocator table:

Property	Signature_
REGIISDIR	REGIIS_COMPLOC

...and this row to the CompLocator table:

Signature_	ComponentId	Type
REGIIS_COMPLOC	{72D0920F-8758-4EF8-A415-E6E44332AF49}	1

The ComponentId is the GUID which was associated with the file aspnet_regiis.exe in the v2.0.50727 installer, and type "1" means "return the path to the directory that the file was installed in." To find this GUID I had to crack open the vs_setup.msi which installed Visual Studio 8.0 and search for things like "aspnet_regiis," which really didn't take long (although it might not be obvious.) This sets the value of the REGIISDIR property to the path of the exact version of the utility that we want, or leaves the property undefined if the file is not found.

Then, to get the file spec of the utility which we intend to run we have to add the file name to the path. In an MSI we need to use a built-in Custom Action to accomplish this. We add the following row to the Custom Action Table:

Action	Type	Source	Target
SSMCA_CreateRegIISPath	51	REGIISPATH	[REGIISDIR]aspnet_regiis.exe

Type 51 means "take the formatted string in the Target field and evaluate it to set the value of the property named in the Source field. Here evaluating the formatted text means replacing [REGIISDIR] with the value of the property, which we set with the AppSearch entry. Once this Custom Action is performed, we have the full path file spec of the appropriate version of aspnet_regiis.exe in the property REGIISPATH.

But what if the appropriate aspnet_regiis.exe wasn't found? And how is this action performed in the proper sequence? The InstallExecuteSequence table is the key. It lists every standard action and custom action to be performed in the order they're performed, with optional conditions for each step. AppSearch is the very first step in the sequence, so the AppSearch table is evaluated at the beginning of the install and REGIISDIR is set (or not) at this time. We add the following entry to the InstallExecuteSequence table:

Action	Condition	Sequence
AppSearch		100
...
SSMCA_CreateRegIISPath	REGIISDIR AND NOT (REMOVE OR (ACTION~="ADMIN"))	6450

...and our named Custom Action is performed right near the end of the sequence, but only if the property REGIISDIR has a value, if we're not performing a "remove" function (why register scriptmaps while we're removing?) and if we're not performing an administrative installation, which is actually a deployment for later installation rather than an actual product installation.

That's four of our eight changes, and all we've got so far is the path to the utility that we want to run. But it's the right path and we haven't had to do anything risky or unreliable to get it. The rest of the process should all be downhill.

Almost...

Inside the MSI

vank — Mon, 11 Sep 2006 18:27:00 GMT

If you're following this article, you must be interested in modifying how an MSI produced by a Visual Studio Installer project works. Although I began by encapsulating the change in a black box, the Windows Installer Team Blog cautions in rule #1 of the Tao of the Windows Installer to "Learn the Windows Installer Technology." There's a lot to learn here. MSDN contains a wealth of technical information, but it's arraigned as a reference, not a text book. I found Phil Wilson's "The Definitive Guide to Windows Installer" tremendously helpful, and it's actually aimed directly at Visual Studio Installer projects. It goes well beyond what's available in the stock VSI project. If you don't know what the various tables in an MSI are for, you'd be well advised to study up before making any changes.

That said, MSIs are remarkably open. Administrators are free to make modifications in the installations their users will see. Transforms can be applied to modify an installation. The tool Orca lays the installer tables wide open for inspection and modification. In fact, I used Orca to manually modify an MSI for testing before writing a single line of the script.

How setting scriptmaps works

vank — Sun, 10 Sep 2006 07:24:00 GMT

An MSI contains a database which directs the installation, uninstallation, rollback and repair of a set of files and registry entries. The database contains a number of tables, and the AddSetScriptMaps script adds entries to five of them:

The AppSearch table gets an entry which looks for the appropriate aspnet_regiis.exe.
The CompLocator table gets an entry describing how to find aspnet_regiis.exe.
The CustomAction table gets three new Custom Actions:
- One creates the full path to aspnet_regiis.exe.
- One reformats a string from something like "/LM/W3SVC/1" to W3SRC/1/ROOT/"
- And the workhorse, which runs the appropriate aspnet_regiis.exe with the proper parameter.
The Binary table gets an entry containing a simple Custom Action written in JScript.
The InstallExecuteSequence gets three entries (with conditions) which select and sequence the three Custom Actions.

Once these rows are added to the tables, aspnet_regiis is executed and sets the scriptmaps for the newly created website each time the MSI is executes to perform an installation. Normally Custom Actions need to be careful to undo their work on rollback and uninstall, but in this case these actions remove the virtual directory that the scriptmaps are set for, thus effectively undoing this action for us.

Next we'll go into some detail about each entry, and finally we'll cover how the script modifies the MSI and why it's organized the way it is.

How to set scriptmaps in a Web Setup Project

vank — Sun, 10 Sep 2006 04:44:00 GMT

Web Setup Projects make it simple to package and deliver a web application, but they have some drawbacks. One often mentioned is that the new website's scriptmaps are not necessarily set to ASP.Net 2.0, rendering the website unusable. Setting the scriptmaps from the command line or the IIS UI is not difficult if you know how, but it's not simple to discover or to remember. The behavior seems inconsistent; on some machines you never have to perform this step, on others you do. Why not have the installation MSI file set the scriptmaps for you?

The Web Setup Project doesn't seem to give the user much control over Custom Actions or the InstallExecuteSequence, and no one want to introduce manual steps to setup production. Yet there's a simple solution. The Windows Installer API includes a comprehensive object model for the MSI file, and the Web Setup Project features a project property named PostBuildEvent. This makes it simple to execute a script on completion of a build, and the script can insert all the MSI elements required to set the scriptmaps when the installer runs.

There's a lot to explain about this process, so I'll begin by just posting the scripts and telling you how to use them, and then I'll go on to explain the details in future posts. Perhaps your feedback will help improve the process before I'm far down the road.

Quick Start

Download the attachment Scripts.zip and extract the files AddSetScriptMaps.wsf and SetSrvrPathCA.js.
Place the two files in the same directory located anywhere; in your project or, say, on a share like \\FileServer\Development\Scripts\WebAppSetup\ScriptMaps\.
Open your existing Web Setup Project, select the project node, and right-click-select "Properties."
Select the PostBuildEvent property and set its value to:
CScript "\\FileServer\Development\Scripts\WebAppSetup\ScriptMaps\AddSetScriptMaps.wsf" "$(BuiltOuputPath)".
Build your Web Setup Project.
View the Output window and verify that the build output ends with "MSI successfully updated for registering scriptmaps."

That's it! When you run your new MSI to install your web application on a server, it will set the new web application's scriptmaps to v2.0.50727.

It's going to take a bit of effort to explains how the script works. Instead of writing one marathon posting, I'll cover this in the next few installments. I'm definitely interested in your feedback, as well as any other Web Setup Project wishes you might have.

Minor problems with the DHTML Editing Control for Applications installer

vank — Sun, 10 Sep 2006 03:48:00 GMT

A helpful customer contacted us with some concerns about the installer for the Windows Vista version of the DHTML Editing Control for Applications.
While I had run the ICE verification for Logo Compliance in Orca (the MSI inspector/editor) I had failed to upgrade to the Windows Vista version of Orca first. As a result, we missed the fact that some UI elements in the AdminUISequence which were required for Windows Vista Logo Compliance were missing.
This was easily fixed, but I spotted another problem while working on this; the launch condition which required Windows Vista in order to run the installer applied the administrative install as well as the ordinary install. Administrative installs don't actually install the product on a computer; they deploy an installable image to a network location. There's no reason to require an administrator to be running Windows Vista just to deploy an administrative image, so this is being corrected as well. The user installing from the administrative image will still need to be running Windows Vista, of course.
This installer modification is in testing now and will be released soon. The binaries installed by it are unchanged. If you have any questions, contact me or post a comment.

The End of an Era

vank — Thu, 24 Aug 2006 22:46:00 GMT

As you may have heard by now, the DHTML Editing Control is not shipping as a part of the Windows Vista operating system. You can read the announcement here. I know a lot of people are going to be impacted by this change, and I'll help to the extent possible.

While we've made a version of the non-safe-for-scripting control, or the DHTML Editing Control for Applications, available for Windows Vista, it is not a part of the operating system and must be shipped with your products. Furthermore, the safe-for-scripting version of the control will not be made available for Windows Vista, and there are plans to kill-bit it in XP at some unspecified future date. (Kill-bitting means that IE will not load the control under any circumstances.) Web applications using the control will need to be modified.

The download of the Windows Vista version is here, and a white paper with some helpful information is here. Let me know if you have any questions about the white paper or related topics. I'll try to provide help here for people who need to implement changes to adapt to the loss of the control.

Straight to Video

vank — Thu, 17 Mar 2005 21:50:00 GMT

(More history of the DHTML Editing Control)

Once the thrill of packaging up some cool technology and releasing it to the public gave way to the gruesome reality of servicing an operation system component, the youthful bloom was off the DHTML Editing Control. Feature enhancements were not to be approved. I think we had one very minor added feature (although I don't remember what it was) as we moved from private distribution to OS distribution. Bug fixes did continue, however.

Jeff took over as Program Manager and did a good job of keeping up the community effort. I remember having an online conference once with quite a few attendees, and he was a prolific communicator. Expanding usage turned up a few functional bugs, mostly related to Far Eastern scripts, which we got taken care of--I believe by the time IE 5.0 shipped.

Our team got to work on Visual Studio 7 and I remember missing almost the entire first milestone because of work on the control. It got pretty disconcerting, because I had a few features I wanted to get to work on; frameset editing and absolute positioning. We finally got through our bug list and shipped a functionally solid version of the control. I wish I had the exact version number, but I purged most of my email some time ago. I shifted focus to Visual Studio, we lost Jeff, and focus shifted off the control.

One internal partner that adopted the control and kept us well aware of any problems which came up during OS upgrades and patches was the OWA team (Outlook Web Access.) Their test automation was extensive and well crafted; a few problems did crop up as IE tightened security and we had to make tandem changes in the control. We got a lot of great input fro their QA team and we owe them a lot. Thanks, ya'll! OWA rocks.

Getting it for Free

vank — Wed, 16 Mar 2005 22:55:00 GMT

Everything was going great back in 1997. I'd come into the VID project late and was finally about to ship my first product at Microsoft after earning a few "skip its" in the graphics division. (An imaginary award you get for having your project cancelled. Like a "ship it" but completely different.) I'd added a few DTCs (Design Time Controls) to VID (do you remember the Sequencer?) and was working on this pretty cool HTML Designer control. Then a funny thing happened.

I walked into Steve's office, the PM who had driven the creation of the control, a couple minutes late for a meeting. He was just winding up an excited exposition on the whiteboard, saying "...and then we can mark the control Safe for Scripting, and we get it for FREE." The idea was to add a second control to the OCX which eliminated a couple of methods, such as Save and BrowseMode, and then people could use the editing features in a web app as well as a client app.
I whined. I didn't think that Safe for Scripting really came for free. I thought there might be security risks that we hadn't considered. But I was challenged to be specific, to identify an actual problem, and I couldn't.

It turned out over the years that I was smarter than I could have ever imagined, but that's a rather small comfort. We made the dual control and released it to the web. I've got a copy of the release CD right here. We just moved offices and I found it while unpacking. The build date was March 27, 1998. We got the control posted to the ActiveX Toolbox so that it could be automatically downloaded via a codeBase attribute in an OBJECT tag. IE 4.01 was on the disk

Remember when IE used to change fast? And at this point IE revisions required DHTML Editing Control revisions as well. After a couple of revs our codeBase installation system began to get complex. It got so complex that there was a full time contractor on it, Yuri, and I remember one meeting where there were about 15 of us in a room for over an hour discussing installation issues. At the end of the meeting even Steve agreed that "free" wasn't the best way to describe the Safe for Scripting aspect of the control.

Then we did a smart thing. We met with the IE team (I don't remember who was involved on their end) and explained that we couldn't continue to maintain separate, compatible builds of the control and its nightmarishly complicated installer. We talked them into our moving the source to their code tree and shipping revisions of the control with revisions of IE. This way it would always be installed and would always be compatible, and we could eliminate our setup efforts completely. We (the Developer Tools Division at the time) agreed to maintain the code while they would maintain the build. I'm not sure exactly when this agreement went into force, but this is still the arrangement today.

I have to tell this story over again every single time I go to a Windows War meeting to get approval for checking in a bug fix. Now, at last, I can just provide a URL.

Anatomy of DHTMLEd

vank — Wed, 16 Mar 2005 21:37:00 GMT

The DHTML Editing Component is three things in two packages:

TriEdit.dll is installed in \Program Files\Common Files\Microsoft Shared\Triedit\. It implements an IOleDocument which aggregates Trident, the document object displayed by Internet Explorer. I don't know of anyone CoCreating ITriEditDocument directly. If you have, let me know and I'll send you a token of my respect.
DhtmlEd.ocx is co-located with triedit.dll and implements two ActiveX controls:

The Safe-for-Scripting version of the DHTML Editing Control, DHTMLSafe, which is useful when hosted in an HTML page.
The Unsafe version of the control, DHTMLEdit, which is useful in client apps build in VB, etc.

Technically, there are also a couple of other helper objects wrapped up in the package which are used as parameters for methods of the DHTML Editing Controls; a DEInsertTablePram and a DEGetBlockFmtNamesParam.

TriEdit.dll was developed for VID and was used extensively by the HTML Designer. The control was developed initially by a contractor and handed off to me for completion and shipping (80% done, 80% to go, you know.) The idea was to bring the nice HTML designer features of VID to Visual Basic in a nicely packaged control.