Visual Studio 2010: Logging in

I downloaded Visual Studio 2010 CTP a week ago. I fiddled around with it for about 30 minutes, trying to login to the accounts provided by the preview. From the download site:

The following logon accounts and passwords have been preconfigured on the VPC: Administrator: TFSSETUP, password: 1Setuptfs (use this account to explore the CTP) Administrator: Administrator,password: P2ssw0rd User: TFSREPORTS, password: 1Reports User: TFSSERVICE, password: 1Service

The passwords weren't working for me, so I mixed them up. Finally, I gave up. Today, I took a break from reading for my Winter Intercession course, and decided to run the Visual Studio 2010 image again. I realized Virtual PC had start it up with numlock on. Because I'm using a notebook PC, it's easy to forget that the right half of the keyboard doubles as a numeric keypad with numlock. So, I turned numlock off, and I was able to log in. I can't wait for Visual Studio 2010 to be released. I especially like the WiX integration. Sure, WiX offers the same integration for Visual Studio 2008, but it's nice to see Microsoft attempting to make installers less of a hassle for developers. It took me about a week of researching different installers to finally settle on WiX. When I get a chance, I'm going to look into custom actions using Powershell to retrieve version numbers and edit localization files with updated versions. Now, I guess it's back to coursework.

Visual Studio error, debugger can't start

"The components for the 64-bit debugger are not registered. Please repair your Visual Studio 2008 Remote Debugger installation via ‘Add or Remove Programs’ in Control Panel" So, I uninstalled EVERYTHING related to Visual Studio. I assume it was a problem with SP1 and my XP 64-bit operating system. The reason I think this is the case: when I tried running the installer for the remote debugger from the VS2008 dvd, it had the options for repair and remove. Running either option gave me this message: "Error 1324: The folder path folder name contains an invalid character." Could that be 'Program Files (x86)' by any chance? Why Microsoft would choose to name a system folder with a character the windows installer considers invalid is beyond me. Anyway, the way I thought I'd share how I fixed the issue. -Download Microsoft's Windows Install Clean Up utility from: http://support.microsoft.com/kb/290301/ -Run the utility and remove ONLY Microsoft Visual Studio Remote Debugger -Run the debugger setup from the dvd Hopefully that will save someone a headache.

WiX Installer Update

One thing that has caused me quite a few problems with my WiX installer was optionally displaying a dialog to enter SQL information when the database is installed.

I may change the database to be a critical element of the intall, but I thought this would be a good share.

Based on:

http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx

and

http://geekswithblogs.net/jwatson/archive/2006/11/03/96052.aspx

To set the next button to display based on features chosen in the feature tree, you can do someting like this:

< publish dialog="CustomizeDlg" control="Next" event="NewDialog" value="SqlSetupDlg"> 1 </publish> Where "Database" is the name of the feature you want to install.

other access prefixes are:

1. (none) Installer property:  Value of property (Property) table.
2. % Environment variable:  Value of environment variable.
3. $  Component table key:  Action state of the component.
4. ?  Component table key:  Installed state of the component.
5. &  Feature table key:  Action state of the feature.
6. !   Feature table key:  Installed state of the feature.

WiX: First impressions.

After working with WiX today, I realized that it's not perfect. But, it isn't horrible. Maybe my issues are from following "tutorials" that are written for WiX 2.0, while I'm using WiX 3.0.

Whatever the reason, I have encountered only a few problems so far:

1. < removefolder id="FolderName" on="uninstall" > this caused a lot of errors. I don't know if WiX 3.0 has changed how it handles removal of folders? I noticed when I uninstall without specifying , it actually removes the folder properly. (I'm using this on a folder under ProgramMenuFolder)

2. Creating a new UI and adding dialogs was a pain. Referencing my dialog with DialogRef="NewDialogName" kept throwing errors. Quite a few google searches later, I still couldn't find a fix or a reason for the errors. The resolution: instead of creating the dialog in a different file as a Fragment, I just added it to the file modeled after WixUI_Mondo. After doing this, the dialog worked. Maybe fragments are broken? Or, maybe I wasn't compiling and linking the library properly.

3. Many tutorials refer to a tool called tallow to create a Fragment of Components/Files. But, the tool is now called Heat. It's a useful tool, but I'm still having problems getting Fragments that I create to work right. That's about it, I will write up some solutions to these problems if I find them.

Windows Installer Dilemma

My current task is to create an installer. The dilemma: Visual Studio doesn't provide a very robust Setup and Deployment project. The options? 1. Create a WiX Project 2. Write a bootstrapper/custom GUI/etc. and P/Invoke msi.dll 3. InstallShield ($$$) 4. Wise ($$$) 5. Nullsoft Scriptable Install System Here's what I've run into. WiX is pretty straight-forward and configurable. It is also open source, so you are able to rewrite the user-interfaces to fit your needs. The only thing is that the whole project is in XML, which means creating a dialog means setting values for buttons, labels, and textboxes manually. I've thought about writing a short program to create the dialogs for me, which I may still do. The problem I've found with WiX: I can't figure out how to refer to code (Assembly Info). I have found two possibilities: replace WiX version via PowerShell script and using MSBuild tasks. However, my development team wants to make the project as simple as possible. Using WiX already means that everyone will have to install WiX in order to build the file properly. This will only be a problem until the next version of Visual Studio, which is supposed to ship with WiX installed. Option 2 is one that I got from Rick Brewster, of Paint.NET fame. Well, not directly from him. Scott Hanselman has an excellent podcast which details the Paint.NET installer. It is beautiful in it's simplicity. I'll leave a few things out, to tailor it to my discussion. I'll start from the outside-in.

1. The installer comes as an executable created by NSIS (#5 above). This installer basically acts as a zip file, which extracts the contents to the user's application folder and runs the bootstrapper.
2. The bootstrapper checks for the proper version of Windows, and .NET
3. If the requirements .NET aren't met, the .NET redistributable installer can be run from the directory.
4. When everything is good, a custom GUI setup program runs.
5. The program gathers necessary information, injecting it into the MSI installer which is actually the same one created by Visual Studio.
6. Then, any number of MSI installers can be run.

This method of staging, bootstrapping, gathering, and then running seems the most efficient. The problem is that the whole MSI interoperability means having a full understanding of Windows Installer technology. It is possible, however, to simplify this even further. On the progress form, use msiexec and switches. Because I'm not that interested in fully understanding the Windows Installer technology at the moment, this option is a little more than I want to get into. But, I have actually started a project that uses a very similar method. InstallShield and Wise cost money, so they are not options for me. NSIS is another excellent option. The only problem I see with it is that it's like learning another scripting language. Although it is very simple, it doesn't particularly appeal to me. XML, however, does. So, it looks like I'm going to go with WiX as my choice to create an installer.

.NET development

I consider myself a .NET developer. I don't consider myself good at it. There are always things to learn, and new facets of development that I didn't realize existed. I plan on keeping this blog as a way to keep tabs on what I've been doing. I am currently working at Agility Healthcare Solutions, on a Rich Internet Application used to track patients, staff, equipment, and beds in a hospital environment using RFID. The language of choice is C#. Be sure to check back regularly, maybe you'll find something of use.