Ken Kopczyk

Hurdles in .NET Development

Archive for December, 2010

Installing SVN on Windows is Easy!

Posted by Ken on December 21, 2010

I shouldn’t have to go into the importance of a good source control system. It allows you to do the following great things:

  • track code changes over time
  • rebuild old versions for technical support purposes
  • discover the original author of the software so you can playfully fingerpoint when it breaks
  • document features and bug fixes in a particular release
  • it’s a giant “undo” button!  (as described in The Pragmatic Programmer)

Installing an SVN server as a windows service is painless:

  1. Download and install the CollabNet SVN server and command-line client package on your server.
    • At the time of writing this, the latest stable version was 1.6.15.
    • Since we are installing this to run as a Windows Service, you can uncheck Apache in the “Choose Components” step. (Figure 1)
    • By default, SVN uses port 3690 and a default repository path of c:\svn_repository. (Figure 2)
  2. To set up a repository, run the following command:  
    svnadmin create "c:\svn_repository"
  3. Uncomment the following lines from c:\svn_repository\conf\svnserve.conf
    anon-access = read
    auth-access = write
    password-db = passwd
    
  4. Add users to c:\svn_repository\conf\passwd
    [users]
    # harry = harryssecret
    # sally = sallyssecret
    user = password
    
  5. Make sure port 3690 is open on your server if you have a firewall.
  6. Start the “CollabNet Subversion svnserve” windows service and you’re server is good to go!

Next, we need to install some client components that can access the server:

  1. Download and install TortoiseSVN on your client machine.
    • Allows you to access the SVN server and integrates into the windows shell.
    • At the time of writing, the latest version is 1.6.12, which is designed to work with SVN server 1.6.15
    • All default options are fine.
    • Requires restart.
  2. Download and install WinMerge on your client machine.
    • Default options are fine, but ensure that “Integrate with TortoiseSVN” is checked. (Figure 3)
    • The TortoiseSVN integration allows WinMerge to handle diff’ing of code history.

Figure 1

Figure 2

Figure 3

Posted in Source Control | Tagged: , | Leave a Comment »

MSI Upgrade Removes Necessary Registry Entries! Help!

Posted by Ken on December 13, 2010

Using a Visual Studio “Setup Project” is a quick and easy way to create a simple MSI installation package. Creating a basic installation package is as easy as selecting the items you want to package (exe/dll within your solution, Assemblies, miscellaneous files, etc), choosing their location (system directory, GAC, Desktop, etc) and flipping a couple of options within the Properties window. You can even have it automatically register assemblies if necessary. This is very helpful if you have to deal with older COM components.

Properties window for a Visual Studio Setup Project

After releasing an initial MSI version 1.0, I started running into issues with my 2.0 upgrade MSI. My intent was to have the new MSI remove all components/files installed by the 1.0 MSI, and then install the 2.0 components. I thought this would be accomplished by flipping the “RemovePreviousVersions” property to true, incrementing the “Version” property and changing the “ProductCode.”  However, I’ve experienced issues where registry entries were getting removed and files were not getting updated as they should. Turns out the MSI needed additional TLC which the “Setup Project” GUI within Visual Studio could not provide. Enter Orca.

Orca is a database table editor that gives you full access to all the settings within the MSI.  It provides much more granule control than what Visual Studio gives you.  It is available as part of the Windows SDK Components for Windows Installer Developers.  To fix all my upgrading issues, I used the following steps:

  1. In the Properties table, I’ve added the key/value pair: REINSTALLMODE = amus.  See MSDN for more info on this property.
  2. In the InstallExecuteSequence table, I modified the Sequence of the RemoveExistingProducts Action to come just before the InstallValidate Action. This is per the advice of Adrian Accinelli from the following thread: MSDN MSI Forum
  3. Finally, I checked to make sure the rows in the Upgrade table were correct. I modified it so that the row with ActionProperty = PREVIOUSVERSIONSINSTALLED had the version min set to 1.0.0.0, version max set to the version number of the previous version, and the Attributes set to 768. I modified the row with ActionProperty = NEWERPRODUCTFOUND to have version min set to the version number of your upgrade, version max set to blank, and Attributes set to 258. See here for details of the Attributes column.

Step 3: The upgrade table of an MSI

One thing to note:  Any of those three steps can be automated using Post-Build events, Cscript (built into Windows) and WiRunSQL.vbs, a VBscript included in the Windows SDK Components for Windows Installer Developers.  Here is an example using step #1 from above:

Cscript WiRunSQL.vbs foo.msi “INSERT INTO Property (Property.Property, Property.Value) VALUES (‘REINSTALLMODE’,’amus’)”

The moral of this story is:  A Visual Studio Setup Project is a quick and dirty way to create an MSI.  However, better tools are required if your installation becomes slightly more complicated.  Orca, WiRunSQL, and WiX are all helpful tools for building and maintaining MSIs.

Posted in Installer | Leave a Comment »