Monthly Archives: January 2009

.NET Interop and InstallShield

Filed under .NET, Installations

I’ve got a VSTO Com Addin for Word that I’m building an installation for. In the past, the addin had been handled via a DOT file, which is effective, but isn’t really the best way to build addins for Word, especially not now with VSTO.

At any rate, the product is working great, so I was putting an installation together.

I marked the particular assembly as .NET Interop, and when I built, IS complained that it couldn’t get the interop info from the assembly.


Huh? After some digging, turns out that InstallShield runs REGASM.EXE with the /REGFILE: switch to extract the COM registry information from the assembly, and then saves that in the MSI.

So, I tried running REGASM on my dev machine with the assembly.

REGASM MyName.MyAsm.dll /REGFILE:TestFile.reg

Worked perfectly.

So I tried it on my IS2009 box with the same assembly.

RegAsm : error RA0000 : Could not load file or assembly ‘Extensibility, Version=
7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its depe
ndencies. The system cannot find the file specified.


After scratching my head for a bit, I realized that my assemblies were compiled with .NET Framework 3.5, and that they definitely use some of the 3.5 specific features. It’d make sense that not having .NET 3.5 on the IS box could cause this.

So, a painstakingly lengthy .NET 3.5 install later, and I try the same regasm on my IS box.

No joy. Grrr.

So, I do what I should have done in the first place, open the project in Visual Studio and check the references. Sure enough, it points to an Extensibility.dll from the VSTO installation. Duh.

So, I go and install VSTO (to the InstallShield box, another grrr…)

No problems there, but still no joy.

Another look in the project and this Extensibility.dll lives with the VSTO V9.0 stuff. If I’m not mistaken, that means it’s an Office 2007 thing, not 2003 (which just happens to be the version of Office on the IS box).

Ok, maybe if I install the Office 2007 Primary Interop Assemblies?


More Grrr…

At this point, things are just irritating. I don’t want to install Office 2007 on what should ideally remain a more or less pristine dev box for doing install builds, so what next.

I know where this Extensibility.dll lives on my dev machine, I’m just not sure how REGASM looks for it, the GAC maybe, a search path (not likely), or some other arcana?

Screw it, I grab a copy of Extensibility.dll off my dev machine and copy it to the same folder as the DLL I’m trying to run regasm on.

RegAsm : error RA0000 : Could not load file or assembly ‘Microsoft.VisualStudio.
Tools.Applications.Runtime.v9.0, Version=, Culture=neutral, PublicKeyToke
n=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file

Aha! Similar message, different DLL! Now we’re getting somewhere.

Grab a copy of this “‘Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll” file off my dev machine, copy it to the same place and regasm again.

Repeat for another two dlls and REGASM will finally run through with no errors.

I’ve already had to pull TLBs and OLBs from Office installs for reference purposes in the application (for use on some dev boxes that don’t have either Office 2003 or 2007 installed), so grabbing a few more dlls for referencing purposes isn’t a big deal; they don’t have to be shipped with the application (they come with either VSTO or Office itself), and they can be checked into version control just like anything else.

In the end, I’m still not entirely convinced VSTO is a good way to build commercial addins for Office applications. It’s fine for quick and dirty internal projects, but it just seems to add a lot of additional complexity to releasing a commercial app. It’s harder to build a non-VSTO addin, but the end results may justify the extra effort.

Your mileage may vary.

WinIPAC controller software isn’t quite right

Filed under Arcade, Hardware, Troubleshooting

image Here’s an example of the “When software doesn’t work right, it can cost loads and load of time” type bug.

I’m using an Ultimarc WinIPAC controller board for a project I’m working on. This is an awesome little controller board that looks like a USB keyboard, and supports mapping of up to 56 switch inputs to any normal keyboard key. It also has LED outputs for driving LED’s or other applicable circuits.

Anyway, the IPAC comes with a simple keyboard mapper/programmer that you use to layout your buttons, then assign which key to which button and finally to upload the mapping to the IPAC (It saves the mapping in non-volatile ram on the board, which is even more fantastic).

Anyway, I’d mapped a particular key to the ENTER key, as shown here.


But when I was testing all my mappings out, it didn’t work. Actually, it’d flash sometimes but not consistently. Every other key worked flawlessly.

I spent the better part of 3 hours trying to debug what the heck was happening, swapping wires, using a test meter to verify connections, switch operation, etc.

I even pulled the latest version of their website, but still no joy.

In the end, I discovered that it’s the WinIPAC software  that doesn’t quite handle ENTER keypresses properly. I opened up NOTEPAD and just started pressing buttons and all of them, including the switch I had mapped to ENTER, worked perfectly.


<UPDATE> I emailed with Andy at Ultimarc (these guys get back to you quickly! Very nice support). Anyway, his comment was that the WinIPAC software isn’t intended as a test application, only for programming.

I pointed out that if that’s the case, there really ought to be a warning somewhere to that effect, especially if you map keys whose actions can’t be displayed properly in the application. My rationale was, well, it DOES properly display keyboard status for virtually all the mappable keys so why wouldn’t any normal person assume it could be used as a test app? But, in the end, it’s easy enough to use notepad for those tested, IF you know enough to realize you need to!

Changing the Windows XP Product Key

Filed under Uncategorized

I was working with a quite old inherited virtual machine today (VMs have a nasty habit of getting old and unpatched), and I needed to have SP2 (actually XP SP3 is out now) on it (to install SQL Express, among other things).

The problem was, this VM had a installation of XP, no service packs, using a product key who’s ancestry was, shall we say, questionable, at best.

Of course, I have several valid product keys from MSDN subscriptions, so I’m completely legit. But I needed to get this VM squared up so I could get products installed on it.

In the past, I’ve used a technique I found online whereby you edit a registry entry to invalidate your current activation (and thus force Windows to want to reactivate itself), then you run the msoobe.exe application with a certain command line to relaunch the activation process. Not to hard, but it didn’t work with my legitimate WinXP product keys. I have no idea why not, and there was nothing in any of the messages to indicate what was wrong.

Then I happened across a link to the Windows Product Key Update Tool.

A quick download and it worked perfectly. It properly accepted the product key for XP from my MSDN subscription, updated Windows and reactivated it straight away.

Certainly, a very handy tool to have in the stable!

Don’t Forget About the Task Scheduler

Filed under Utilities

A little known facet of Windows that’s been there since the early days of NT is the Task Scheduler (I seem to recall actually using the AT scheduler it under NT4, but my memory is sketchy back that far<g>).


It’s part of the Control Panel, and it essentially lets you schedule applications, scripts, etc to be run automatically, using a particular set of login credentials, at particular times.

Many applications out there can be run as Services, which means they run all the time, in the background, even before anyone has logged into the system.

But for many types of applications, running as a service isn’t necessary and just takes up memory and processor time from other applications that do need to run all the time.

I happen to use a backup utility called FileBack PC. They have a service module that allows it to run as a service, complete with scheduling etc. But they charge extra for that module.

I was really wanting to schedule my backups to run late at night, and I really wanted them to happen regardless of whether I’d logged into my server or not.

That’s when I remembered the Task Scheduler. Here’s an example screen of a configuration to run a backup job called “NearLine Backups” every morning at 7:00am.


In order to setup a scheduled task, you double click on “Add Scheduled Task” and walk through the wizard that follows:

First, the introductions screen:


Next, select the application you want to run, in my case, it’ll be FileBack.exe.


Choose to run it daily:


Set the time:


And finally, set the user name and password for the account that this task will be run as:


It’s quite important to get the account and password right, since the task that is run will run with those credentials. Also, if the task needs access to certain network resources or drives, that account will have to have access to those resources.

Once you have these bits set, you can always dblclick on the task from the Scheduled Tasks list and edit various details, such as additional command line parameters for the executable being run, etc. In my case, I had to add the name of the backup job I wanted to run, like so:

c:\program files\FileBack PC\FileBack.exe “NearLine Backups”

But every application will be different.

And that’s it.

If you are logged in as the user that the task will run as, and the task is scheduled to run, you’re likely to actually see it start and run.

If no one is logged in, or if you’re logged in as another user, you won’t see anything happening.

As always, you’ll want to test and verify that what you think should be happening actually is. But, using the Task Scheduler is certainly something to keep stashed in the toolkit!

Chained MSIs and Installation Order

Filed under Installations

The new Windows Installer 4.5 has support for chained MSIs, which is fantastic. What that means is that you can finally have your install invoke one or more other MSI installations, and they all get installed as a single transaction, meaning, if any one of them fails for any reason, the entire install can be rolled back seamlessly.

This is a huge step up from the old days, especially for those complex fat client installations that require things like XML, SQL, ADO, VSTO, etc that may or may not be present on older OS’s.

Anyway, one problem I ran into when experimenting with this functionality is that I had both the SQL Native Client Drivers and the SQL Server Management Objects as chained installs, but, when I tested my installation, the SQL SMO ended up getting installed first, and it failed, because it depends on the SQL Native Client Drivers to already be installed.


I thought that maybe the order of the items in the Chained MSI Packages list controlled the order, but no, apparently, that list is just alphabetic.

You can actually only control the order of chained MSIs by using the Direct Table Editor on the ISChainPackage table:


Just enter numbers from 1 to x in the order column to control which chained MSI is installed first, next, etc.

Chained MSI Packages With InstallShield 2009

Filed under Installations

So, I’m attempting to upgrade an installation built with InstallShield 11.5, converting to the latest IS2009.

Things are clicking right along until a try and perform a build.



Yep, that’s the “correct” spelling.

Epic Fail.

Searching online didn’t yield much. Basically, all the posts I could find indicated that the problem was with the length of an Icon name in the ShortCuts table, but that didn’t apply here.

I’d just added several chained MSI packages (that’s just about the only reason to bother upgrading, virtually everything else about IS2009 is identical to 11.5, at least superficially, but that’s another story), so I was guessing that that had something to do with it.


I went back and removed my chained MSI. Recompiled. Worked!

Hmm. So I started re-adding them one by one.

Eventually, I got the the Office2007PIA msi. These are the Programmability Interop Files for Office 2007 (basically they make it easy for .NET apps to talk to the COM interfaces in Office apps).


After some headscratching, on a whim, I renamed the chained item (not the msi file itself, just the name of the item in InstallShield), and… back in business!

I had changed the name from Office2007PIA to O2007PIA.

Hmm, more experimenting and it looks like the limit is 9 characters.

This name appears to only be used internally, so it really doesn’t matter what it is.

I’m guessing this is an MSI bug, but IS should catch this sort of thing and prevent you from making this mistake. After all, that’s why you use it vs Orca, right? <sigh>

Agile Development

Filed under Rants, VB Feng Shui

Billy Hollis has out an interesting article in the latest Visual Studio Magazine about the possible destiny of Agile Development.

(sidenote: what the hell has happened to VBPJ VSM? Am I the only one that remembers the days when that mag was just shy of a phonebook and literally every article was worth the read? This latest issue is barely enough paper to wipe your a$s! Seriously. It’s sad).

Anyway, Hollis calls out Agile Dev fans, sort of. He takes a bit of a middle of the road stance, which, actually, I find quite refreshing. To me, Agile has always seemed more like a tactic to avoid really learning to improve your craft and rather, just plowing forward, balls-to-wall to get something working, dammit! It kind of reminds me of a quote I once read supposedly from Steven King. When asked what his process was for writing books, he said something like “I just keep flailing away at the damn thing till I have something I like.”

Now, don’t get me wrong. Getting something working is important. But the more I look at the tenets of Agile, the more I wonder whether it’s really the consultants recommending it and the experts teaching it for 1000$ a day that stand to gain anything from it. It just sounds like yet another in a long line of silver bullets.

The best line from Hollis’s article is:

Most developers love to write code, and agile does a pretty good job of rationalizing why developers don’t need to do anything else.