While I’ll have to admit that I haven’t had an opportunity to do a lot of major work on MarcEdit this summer, I have had the opportunity to make some very targeted changes. One of those changes was long past due, but has been causing a little bit of trouble when upgrading so I thought I’d quickly jot down what’s happened, why it was done, and how to correct the issue if you are one of the handful that it’s affected.
Summary:
So, here’s what happened in a nutshell. As more and more libraries move to a centralized IT model where desktops are primarily being managed through group policies and centralized management, more and more requests have come in to make MarcEdit’s installer more enterprise friendly (or, I should say, make the installer package more Microsoft enterprise friendly). Earlier this year, I’d moved MarcEdit’s installer away from the custom executable format to the Windows Installer technology. That went a long way in making enterprise installs possible. However, I’ve since found that one of the things that is quite common in an enterprise environment is the customization of MSI packages. MarcEdit’s previous MSI package was very difficult for administrators to customize, in part because the package utilized a bootloader. This meant that many of the registration processes were hidden from view. As I’ve heard from many administrators, this is something that they’d like to see changed to make managing the application within a large enterprise setting much easier.
Changes:
So the solution was really a simple one. Basically, I redid the MSI package so I could remove the presence of the bootloader. All registration processes have been moved into the MSI tables, so now installation actions are transparent and customizable (if you know how). This should simplify installation for managers needing to make small changes to the MSI package prior to pushing out to their groups.
Issues:
Unfortunately, when there are significant installer changes, there has also been updating issues, and this change was no different. Part of the change involved moving many of the .NET libraries from the application program directory to the GAC (global assembly cache). This is actually best practice, but I preferred to keep the assemblies together so I could more easily evaluate the component versions when the application was running.
When the new MSI package is run (via update), the program automatically will unregister the prior components, delete them, and then relocate the new assemblies to the GAC. For a small minority of users, this part of the process does not always occur. It’s really hard to say why this process doesn’t fire. When it doesn’t, the program may not be functional after update. Essentially, when the user runs the program for the first time, it will crash and notify the user of a problem.
Solution:
Correcting the problem is easy. For the small minority that run into this issue, simply uninstall MarcEdit. If you like, you can take the extra step of removing the MarcEdit 5.0 directory from your Program Files (or Program Files (x86)) directory. This shouldn’t be necessary, but it does make for a cleaner installation the second time around. If you have custom settings or changes, don’t worry. All custom data is saved in your local user profile. However, if you’d like to ensure that the data is captured, you can export your settings using the MarcEdit export settings tool.
Anyway, I apologize for the inconvenience that this has caused a few people. I spent a lot of time trying to make sure that the update would be transparent and by and large it is — but apparently, a few minor annoyances still snuck into the process.
–TR