Lifestyle of the MSIdle

How much Virus scanning is enough?

SusanGorman — Thu, 07 May 2009 19:29:00 GMT

As a person responsible for getting software builds from Development out into the 'real world', one of my reponsibilities is to ensure that the software we let out the door is malware-free.Unfortunately, there are a number of points along the development path when the code is potentially vulnerable. When it comes time to build the software, I see a three-part approach to producing a clean software product

The INPUTS to the build must be clean.
The platform on which the build is done must be clean.
The OUTPUT from the build must be clean.

Some of this might seem paranoid or redundant, but then again anything may be worth avoiding a virus in your code that gets sent to customers! A few tactics aimed at having a clean Input, Platform and Output are:

Virus scan (deep scan) the build machine on a daily basis. Rotate virus scanning products and/or scan with more than one product. Ensure that Windows updates are applied on a regular basis. (weekly). And in case of trouble, BACKUP your build machine to reduce down time. These things keep the platform clean.
During the build process, run a virus scan after you've pulled all the needed files to the local box and before you actually compile anything. If something malicious got into the source code repository, this step will catch it.
The build output from my builds is stored on a separate machine from the build machine itself. Before the build output is copied out to the build storage, scan the build output. This ensure that the build output is clean.

Now there's one last area to consider.

My build storage location is pretty locked down -- read-only for most users. But even so, just because the build output was clean when it got put on the storage server, that doesn't guarantee that it's still clean 3 weeks later when we need to cut another CD of the product or want to ship a copy of a build off to a 3rd party vendor for evaluation. So.. before a build is sent outside the building for any reason, it gets scanned again - just to ensure that nothing untoward happened to the code while it sat around on the build storage server.

All of this is in addition to the standard precautions that the IT department should have in place throughout the company.

Good luck!

CVS error - temp directory permission denied

SusanGorman — Sat, 18 Apr 2009 19:48:00 GMT

I blogged about this CVS error a while ago. http://gormanonline.com/blogs/msidle/archive/2008/10/02/what-causes-automated-builds-to-fail.aspx

Bottom line is - CVS sometimes does not clean up temp directory folders that it creates, then at a later time, it attempts to re-use that same temp directory folder name and burps because that folder already exists. To work around this problem, my IT department made me a sweet little script that runs at 3AM every day and deletes any temp folders out of the CVS temp directory.

This helped, for a while. But every once in a while we get a new recurrence of this temp directory problem.

I know! I know! You get what you pay for - Switch to a different source control system, etc.

Yeah, well.. money is tight and CVS is free. I'm sure a number of us are stuck with the same mandate of having to make do with what we've got.

Our newest theory is that the script that cleans up the temp folders isn't always able to delete folders because sometimes CVS leaves a lock open.

Thus our newest solution is that we are going to shut down the CVS service, *then* run the cleanup script, then start back up the CVS service, every night at 3AM. Hopefully this will help!

Meanwhile -- if anybody out there discovers what the actual cause of this situation is, please pass it on.

*Update* The IT department has looked at the temp directory folders that are getting left behind and thinks there is a pattern. It looks like most of the folders are being created under the username of a set of users that are located on a remote site, who are probably using an older version of TortoiseCVS. We are having all those users upgrade to the newest version of Tortoise and we'll see if that makes any difference.

Installing SQL Express - error 110 - system cannot open the device or file specified

SusanGorman — Fri, 17 Apr 2009 18:25:00 GMT

Here's a link to another install developer that ran into much the same problem as I did with the SQL Express 2005 installation.

http://www.darinhiggins.com/2007/10/24/NestingTheSQLExpress2005Install.aspx

Bottom line - when trying to launch Microsoft's redistributable SQLEXPR32.exe you are likely to see an MSI error 110 "the system cannot open the device or file specified".

The Cause - for some bizarre reason this exe unpacks itself into a directory off the c drive that the LocalService doesn't have permissions to access.

Solution - Darin resorted to a little bit different method than I did, so I'll give you my alternative.

I launched SQLEXPR32 on my local box, then while it was running, I went out to the directory in which it had unpacked itself (it's c:\somelongguid on my box) and copied off the entire contents of that folder. (Now you can cancel out of the SQL install)

Then I used winrar to re-zip that directory and used the winrar options to create a self-extracting EXE that automatically launches the setup.exe that is included in the zip.

So now in my installer, during the execute sequence, I can execute my new self-extracting EXE and on the command line send it all the same switches that I want to use with SQLEXPR32.exe.

This seems to work great so far.

Installing .NET and SQL Server Express

SusanGorman — Fri, 17 Apr 2009 15:04:00 GMT

Yee Haw! Now I get the excitement of trying to install .NET Framework 3.5 SP1 and SQL Server 2005 Express as part of an installation.

Big deal, you say. There's prerequisites already created for these things - so what's the problem?

Well..... Couple of things.

First, the prerequisite for .NET Framework 3.5 SP1 seems to act a little oddly -- it *always* requires a reboot at the end of the .NET installation and doesn't seem to apply any of the other options that *should* let you delay rebooting until the end of the whole installation. This creates a startling user experience.

It looks like this:

Add a prerequisite for "Microsoft .NET Framework 3.5 SP1 (Web Download)". Right click that prereq and Edit Prerequisite.
Click the Application to Run tab. Notice that the command line already includes a /norestart option. According to Microsoft - using this option tells the .NET installation not to restart the computer after installation completes. The redistributable installer returns ERROR_SUCCESS_REBOOT_REQUIRED (3010) if a reboot is required.
In the bottom field noticewhat values are listed as reboot-required return codes.Notice it includes 3010.
Now click the Behavior tab. Look at the options for "If the prerequisite appears to need a reboot". By default it is set to Exit and resume on rebooot.

Here's a clip from the InstallShield 2009 Prequisite Editor Behavior Tab Help Article

Specify the behavior that should occur if the InstallShield prerequisite requires that a target machine be restarted.

Exit and resume on reboot—To end the InstallShield prerequisite installation, allow the InstallShield prerequisite to restart the target machine, and then continue the installation, select this option.

Note it, fail to resume if the machine is rebooted, and reboot after the installation—To note that the target machine should be restarted if it is required, to schedule the restart for the end of the main installation, but to exit if the target machine restarts after the InstallShield prerequisite installation, select this option. Thus, if it appears that a restart is required but you want to postpone it until the end of the main installation (or until a subsequent InstallShield prerequisite triggers a restart), select this option. At run time, the value of the Windows Installer property ISSCHEDULEREBOOT is set to 1 in the main installation when a restart is still pending.

Ignore it, and fail to resume if machine is rebooted—To continue the installation but end it if the target machine is restarted, select this option. Thus, if it appears that a restart is required but you want to try to skip it, select this option.

Prompt the user only if no reboot is detected, but always reboot the machine and resume on reboot—To prompt the end user to restart the target machine only if it appears that the target machine does not need to be restarted, select this option. The target machine is restarted if the end user agrees to allow it, and then the installation continues.

Prompt the user to reboot the machine even if nothing is detected, and resume on reboot—To prompt the end user to restart the target machine even if it appears that the target machine does not need to be restarted, select this option. The target machine is restarted if the end user agrees to allow it, and then the installation continues.

Reboot the machine and resume on reboot—To restart the target machine and then continue the installation, select this option.

With the prereq set up this way the behavior I get is that at the end of the .NET installation a dialog displays

If you click yes - it ends the prereq installation and reboots, as expected.

if you click no - it ends the prereq installation. And that's it! No further communication to the user - no warning that the installation is unfinished. It just... stops. Now having said that, when the user does finally reboot, the installation starts back up automatically - which also is startling to the user.

We found this behavior to be a startling and undesirable user experience. So I wanted to change it so that we defer the reboot until after the entire installation is finished.

Looking at the options above, I changed the option to Note it, fail to resume if the machine is rebooted, and reboot after the installation.

Unfortunately, this doesn't work as advertised. Using that option, I get exactly the same behavior: At the end of the .NET install, the user sees the above dialog and unless they say Yes to reboot now, the installation just ends.

At this point I tried each one of the possible options and found that they ALL seem to produce the same behavior with this .NET installation.

YUK!

Followup: Need ideas for setting up build process

SusanGorman — Tue, 13 Jan 2009 20:45:00 GMT

So.. this whole project became a moot point.

We upgraded to InstallShield 2009, and in this version I found a variable "SETUPEXENAME" which contains the name of the setup.exe that launches the installation.

We decided to use this value, at install time, to set a registry key. This registry key then drives the versioning features. So.. if the file is named "VERSION for WILMA.exe", then we turn on the features for Wilma, and if it is named "VERSION for BOB.exe" then the code turns on the features for Bob.

I know this is subject to user modification because the user could rename the EXE very easily, but for our purposes, this isn't a big issue.

NOTE: The variable DISK1SETUPEXE is "supposed" to return the same thing as SETUPEXENAME, but I found that in InstallShield 12, this variable just didn't work. It was always empty. So upgrading to IS 2009 gave me access to a value that DID work (plus I needed to upgrade anyway.) Another option that I considered was reading the LauncherName value out of the setup.ini. I hoped that LauncherName would be dynamically updated when installation runs -- but is it Not. Which means that LauncherName will hold whatever the *original* setup EXE name was, in case that is useful to you.

Bottom line -- we needed a way to make the installation do different things without having to A) build a new version of the installer or B) requiring the user to have to pass switches on the command line. This little solution of using the setup.exe name solved it.

Need ideas for setting up build process

SusanGorman — Mon, 29 Dec 2008 19:26:00 GMT

I have my build process divided up into the building of the binaries (as one CruiseControl project) and the packaging of the binaries into deployable packages (MSI installations) as a separate project.

This is valuable for a couple of reasons, but the main thing is that we can build the binaries once, then package those same binaries in several different ways without having to rebuild the binaries each time.

So, in CruiseControl the build number is determined by the build of the binaries. This is stored in the state file for the project which builds the binaries. Example, build 2500. The results of the build ( a set of binaries) are stored on the network under the build number (a folder named 2500).

The packaging process uses the build number from the build of the binaries (it looks in the state file for the binaries build and grabs the build number from there) and uses that as its own build number. It also uses that build number to generate the path to the binaries so that it knows where to get them from in order to package them up.

This all works great. Now I have a new feature request...

At times we need to RE-package an older build.

Say that the most recent build was 2550, but we have need to go back and repackage 2500. Currently, I have to do this little jury rig to make that work:

shut down the CruseControl service
manually edit the state file for the binaries and change the last successful build number to 2500
restart CruiseControl
Kick off the build of the packaging process (it builds 2500, as desired)
When the build is done, shut down CruiseControl
manually set the state file for binaries back to the correct last build number of 2550
restart CruiseControl

This is inefficient, at best.

I'm looking for a way to restructure the CruiseControl projects so that I can give the packaging process a different build number to use without having to shut down CruiseControl and preferably without having to touch the true build number of the binaries project either.

Anybody have any suggestions?

I'm currently using CruiseControl version 1.2.1.7 (ccservice.exe) and the projects are built using MSBuild.

What causes automated builds to fail? - follow up

SusanGorman — Wed, 12 Nov 2008 19:41:00 GMT

I had IT check the CVS server for any error event in the event log and we found that there were disk I/O errors that often occurred right around the same time as some (all?) of my mysterious CVS errors. IT dropped in some new hardware, but that still hasn't reduced the errors.

Looking in the event viewer, the errors are event (type) 15, category of none, and source is "disk".

The errors happen in 3 second groups...like from 11:21:08 through 11:21:10 there will be about 9 of these errors, a few each second.

Our current theory is that it's some sort of throttling issue where the sheer bulk of activity involved in doing the CVS update and CVS Labelling is just too much for our system. No real idea of a solution to fix it yet, but... there ya go.

We also modified our build schedule so that builds are not occurring at the same time as the daily backups. Again this has improved things to some degree. Another line of attack on that problem is doing some Spring Cleaning on our development servers to reduce the amount of items to be backed up. It's easy to consider disk space as 'cheap' -- and it is -- but there is still overhead to having a lot of disk space in use. So.. it's wise to go ahead and spend some time cleaning up the servers and doing the basics: delete the obsolete, archive the historical but no longer active data off to off-line storage, trash the 'let me just store this here temporarily' stuff, etc.

The roles of IT and Build engineers sometimes overlap, so do whatever you need to to maintain a good relationship with the hardcord IT guys. Me, I make it a point to find out what their favorite food is and bring them a treat every couple months.

Learning to build on Linux and FreeBSD

SusanGorman — Wed, 12 Nov 2008 19:34:00 GMT

Here's a fun new project!

My current build process uses CruiseControl on a (windows) machine to kick off an nant or msbuild build script that also runs on that same windows machine.

For one of my projects I've just been informed that we are branching out to other platforms.

The project is being ported to both Linux and FreeBSD. I know very little to nothing about either of these platforms. Yee haw!

My first thought is that I'll use the same CruiseControl on a windows machine as the 'master' control on the build process, and have that kick off a win32 build on a windows build machine, and remotely kick off a linux build on a linux machine, etc. In this way we could have a single control point from which all flavors of the same build number could be produced.

I have no idea if this is doable, but... that's my starting thought.

First things first -- I've asked for a VM (virtual machine) of a linux machine so that I can start the research process on linux.

What causes automated builds to fail?

SusanGorman — Thu, 02 Oct 2008 13:52:00 GMT

In the past 8-10 weeks I've had a nightmare trying to get a reliable build process. Here's the numbers of what's causing the build to fail *other* than normal coding errors:

30 failures due to CVS temp directory problems
2 failures due to CVS file corruption
2 failures due to unknown CVS error
13 failures due to timeout when doing CVS tagging
4 failures due to email error
2 failures due to internal network problems
11 failures on the build machine due to not enough disk space

To solve the CVS temp directory problems we've resorted to having a script run on the CVS server that periodically deletes any CVS temp folder that is older than 6 hours old. Even so, there are times when the script can't delete the folder because it is locked open. Something is happening in CVS to cause processes on the server to hang around even though the client action is long gone.

The CVS timeouts -- I have no clue on that one yet.

Not enough disk space on the build machine -- that one was deceptive because the errors never actually said "disk space". They were all just unexplained failures or file not found or something of the sort. Now that I realize that's an issue I've set up an alert to warn me when disk space goes below 10% free. Just something to keep in mind!

CVS and CruiseControl.NET and password exposure

SusanGorman — Fri, 19 Sep 2008 17:20:00 GMT

I'm setting up a new build server using these applications:

CVSNT 2.5.03.2382 (open source source control, command line based)
TortoiseCVS 1.10.9 (GUI for interacting with CVS)
CruiseControl.NET 1.4 (service for automating builds)

When using CruiseControl to automate the checkout from CVS of the most recent source code, you have to setup a CVS section in your CruiseControl project.

According to the CruiseControl documentation, you are required to provide the cvsroot, which includes among other things the name of the CVS server, the user name with which to interact with CVS and that user's password. (Caveat: I don't know much about security and connection methods, but I do know that CVS offers several connection methods and I believe part of the reason that a password is required is because I'm using the pserver access method.)

As you can imagine, I wasn't excited about having to have my build user password in plain text in the cruise control project files.

I discovered a way to avoid this requirement.

Go to the build machine on which the cruise control project will run.
At a command prompt run this CVS command: cvs -d :pserver:cvsuser@cvsserver:/cvsrepository login
After hitting Enter, supply the password

Now you've setup a remembered recognition of the cvsuser on that cvs repository and it won't require the password every time you try to run a CVS command.

If you move the CruiseControl project to a different machine, I believe you need to repeat the process of logging in from the new machine.

Common Task: Optionally Cleanup User Data on Uninstall

SusanGorman — Thu, 04 Sep 2008 20:18:00 GMT

This is a common scenario... Your application, when it runs, creates log files, registry entries, and customized data files on the machine. These are files that were not installed by the installer. Therefore when you go to uninstall, these files would not normally be cleaned up.

It ought to be simple to add code to the installer to tackle removing these files. But... how do you handle it if an uninstall is happening because the user is upgrading? In that case, the user probably wants to KEEP those 'hanging chads'.

So you are left with a situation where you want the removal of items to be conditional - under some conditions remove them, under other conditions don't.

This gets tricky. I've worked up a solution to it. I'm not claiming it's ideal or anything.

Deleting Files and Folders

Before I begin, let me say that as I understand it the best practice is for an application NOT to create data files in its INSTALLDIR. Instead, files like this should go under a Documents and Settings folder either for the current user or under All Users. Further, my understanding is that you don't technically have to remove files under Doc n Settings. However, the requirements I'm usually given say "must remove all traces of product on uninstall". So having said all that...

For this example let's say that the product creates a folder called Logs, under INSTALLDIR. You'll need a Directory table entry for this path, such as INSTALLDIR_LOGS. To cause this folder to get removed on uninstall you add 2 entries to the RemoveFile table. One entry with FileName of *.* and DirProperty of INSTALLDIR_LOGS. This entry causes all files under Logs to get deleted. A second entry with FileName blank and DirProperty of INSTALLDIR_LOGS. This entry causes the (now empty) folder to get deleted. Both of these table entries should be associated with a component that will be uninstalled at uninstall time.

Now let's get tricky and make this conditional. Let's assume that by default you want to KEEP this folder. The reason to keep it by default is so that a silent uninstall (such as when upgrading) will keep the folder.

In the Directory table, create an entry for UNINSTALL_INSTALLDIR_LOGS. Directory_Parent is TempFolder. DefaultDir is ThisFolderShouldNotExist. Yeah, that's a weird name, but it is self-explanatory. We are setting the path to a path which we do NOT expect to actually exist on the target machine - a subdirectory of the Temp folder. The point being, we don't intend for any files to actually get removed at this path.

Go back to RemoveFile table and change the DirProperty for both entries so that they point to UNINSTALL_INSTALLDIR_LOGS.

Now.. when uninstall occurs, it looks in RemoveFile table and tries to delete TempFolder\ThisFolderShouldNotExist\*.*. This folder won't exist and there will not be any errors as a result of that. All is well.

Now we go to Custom Actions. Create a Set Directory custom action that will, based on a flag, set UNINSTALL_INSTALLDIR_LOGS to the REAL path where the log files exist. For example, my cusotm action is called Uninstall_SetLogsDir. The Directory value is [INSTALLDIR_LOGS]. This goes in the Install Exec sequence with a condition of FULLCLEANUP="yes".

So if the FULLCLEANUP property is set to "yes", then our fake path will get reset to the real path, and as a result the log files will get deleted.

Now all you need is a method of setting FULLCLEANUP to yes. In the Property table, create FULLCLEANUP and set it to no, by default. Using whatever method you want, cause a dialog to pop up during uninstall that asks the user if they want to do a full cleanup and if they say yes, then set FULLCLEANUP to yes.

NOTE: When the user uninstalls from Add/Remove Programs using the Remove button, it launches the uninstall with reduced UI, so any custom dialog you write will NOT appear. Therefore, you have to either A) disable the Remove button and force them to use Change button instead or B) display your full cleanup question dialog using some other method via a custom action (InstallScript?).

Deleting Registry Keys

You can apply the same basic methods to conditionally removing a registry key using the Property table (instead of the Directory table) and the Registry table (instead of the RemoveFile table).

Create a Property that holds the path to the registry key. By default set the Property to something that will not exist, for example, a Property called MyRegKey which is set to "Software\ThisKeyWillNotExist".

In the Registry table, create an entry for the key you want to conditionally remove. The fields for this entry are:

Key = "[MyRegKey]"
Name="-"
Value=""

And set the Component to whatever component makes sense. It is the minus sign in the Name column that tells MSI to remove the reg key on uninstall.

In the Custom Actions, create an action that will set the MyRegKey property to the *real* path when FULLCLEANUP="yes". The real path might be something like: "Software\[CompanyName]\[ProductName]\MyCustomRegKey".

NOTE: This only works with whole reg keys, you cannot remove a registry VALUE using this method. In fact, there is not a clean way to remove only a registry value, as far as I know. I find this odd, but true.

There ya go. It appears to work, and it isn't too clunky. Have fun!

I'm a slacker!

SusanGorman — Tue, 02 Sep 2008 16:26:00 GMT

I was reminded that I haven't posted in a while and that I've been a slacker. I profusely apologize and hereby seek to remedy that situation.

So here's what I've been up to...

Why should you avoid using the TypeLib table ?

I have a customer trying to consume a merge module that we produce. The customer is creating his installer using Wise.

I created the merge module using InstallShield 12. The merge module includes a COM dll that is self-registered. In my merge module I set the DLL to extract COM data at build time. This is so that the registration data stays up to date in the installer. Unfortunately, the way that InstallShield works, this causes it to create the registry entries in the TypeLib, AppId, Class and ProgID tables instead of lumping it all in the Registry table.

The Wise system refuses to consume a merge module with entries in the TypeLib table and errors out. Why?

See the Remarks in this MSDN article about the TypeLib table http://msdn.microsoft.com/en-us/library/aa372092(VS.85).aspx.

So... I'm left wondering at this point, how am I supposed to use InstallShield to dynamically update the COM registration information at build time and yet still produce an 'acceptable' MSI/MSM? I haven't resolved this issue yet. So far I've had to manually modify the MSM for that one customer who's using Wise. Customers using InstallShield don't have a problem.

CVS is problematic and my builds aren't reliable

I've been having problems with builds failing on an irregular, but annoyingly often basis. I use CruiseControl.NET and CVS at the moment, because these are open source (free!) tools. I'm NOT on the most up to date version of these tools due to the fact that I need to test out these tools in a non-production environment before I can implement the newer versions and I don't have access to a non-production environment yet. It's in process though! The problems I'm having with the builds are these main issues:

CVS "cannot change permissions on temporary directory" errors. This error appears multiple times a week. I haven't been able to find any solution or explanation for this error in all my googling. All I can find is "yeah, this happens, we don't know why, just try again and it will work". This is true, in that if you immediately do another build it does succeed. But that doesn't make it acceptable to have builds failing. This is an unresolved problem for me at this time.
CVS times out when trying to apply a label/tag. CruiseControl is using its internal APIs (?) to effect the CVS tagging so I can't get a good detailed log of what's going on during this process of why it's freezing up. Since tagging doesn't happen until after the build is finished and successful, this is really annoying to have it fail at the very end. One potential handling is to stop using CruiseControl to do the tagging, but I hate to so obviously bypass the built-in functionality.I'll probably try this technique soon. Unresolved at this time though I do have this technique to try out.
Network briefly blips and loses access to the network device on which files are being copied. Using MSBuild to do a copy task which copies dozens to hundeds of files. If there's a momentary blip and it can't copy a single file -- this causes the entire build to fail. The network shouldn't be blipping in the first place, but.. until that is solved, it would be ideal to have a copy function that is more robust which could try copying - if it fails, wait a sec and try again, and don't fail out unless more than one copy attempt fails. I could do this pretty easily in nAnt, but this particular build is in MSBuild and I'm not very familiar with MSBuild yet. The suggestion that was given me was that I need a custom MSBuild task written in a DLL. (sigh! More DLL writing) Haven't tackled this one as yet because we'd prefer to fix the network instead.

InstallScript custom actions fail due to ISBE.dll not registering on Windows Server 2008

Lastly, in a big installer I started working on converting all the VBScripts to InstallScript because management prefers InstallScript to writing new DLLs for custom actions. Unfortunately, The test machine for this installer is a Windows Server 2008 OS and we immediately started gettting install failures due to the InstallScript CA engine (ISBE.dll) failing to register on the machine. I made a test installer and tried it out on other 64-bit machines (XP and Vista) and it works fine, but it fails on this one Windows Server 2008 machine. Currently working with InstallShield to see if they can help get rid of this error. Until this is solved, I can't work any further on converting scripts to InstallScript because it creates a perception in management that InstallScript is unreliable.

What to do when there's nothing to do?

SusanGorman — Tue, 01 Jul 2008 13:25:00 GMT

I'm in one of this situations where the product is in Beta, stable but not yet actually released. Therefore the codebase is locked down such that only the most pressing code changes are allowed to get checked in. In the ideal situation we'd have a branch of the code and a set of tasks to work on for the *next* release. For various reasons we don't have that at the moment. So.. it means unless a critical bug comes in in my code, then I'm locked out from doing any coding work at the moment.

*twiddle thumbs*

Here's my recommendation on what to do in this situation: Document!

I know most programmers hate writing any sort of documentation, but someone working on installers and configuration management tasks is dealing with an area that even more urgently requires documentation. Most sorts of code you can write comments into it to give some explanation of why it is done that way. Some new programmer walking in off the street has a reasonable opportunity to grasp the basic flow and policies that went into how the code works.

Because MSI installers are table-driven, there isn't any good way to comment like this. Not only does a new install developer have to fumble around blindly, but I even forget why I did things the way I did if I'm away from the installer for a couple months.

The solution here is to document, at least in a basic form, the thinking behind why the install does what it does. I do this by making the document feature-based. For example, I have a feature where I want to validate the path a user has entered on a dialog. In order to support this feature there are entries in about 5 different tables (ControlEvent, Property, CustomAction, AppSearch, Etc.)

In my document I make a heading for this feature, explain what the feature is supposed to accomplish (in plain English), then list the 5 table entries that are required to provide this feature and explain in simple english how those entries relate to each other. For most features this takes a small paragraph and a 4 to 8 item bulleted list. Simple. I keep the document going, adding features to it as I add them into the installer. I guess you might call this a technical spec - I don't know the official term for it. I also go ahead and check this document into source control right alongside the installer project so that the two are easily located together.

A great benefit of writing this kind of documentation is that if you ever need to add this feature to another installer, you already have the pattern for how to do it. Similarly, if you ever need to remove that feature, you know all the little pieces that go with it and can remove it cleanly.

This is the type of documentation that often gets left out, but can really make a difference in providing long-term quality of code. Also, managers love it!

Hope you are enjoying living the Lifestyle of the MSIdle!

Susan

Vacation's Over!

SusanGorman — Tue, 01 Jul 2008 13:24:00 GMT

Vacation was longer than I expected, but now it's over and it's back to work!

On Vacation

SusanGorman — Tue, 03 Jun 2008 14:23:00 GMT

School's out and it's officially summer!

I'm on vacation for 2 weeks. I'll be back and posting more MSI, InstallShield and Configuration Management related items in mid-June.

Enjoy your summer!

Susan