MarcEdit 5.0 & COM II

By reeset / On / In MarcEdit

So it looks like I’ve gotten this working.  I’m going to be sending a private build out to a few testers tomorrow to see if they can confirm that it’s working outside of my controlled environment.  The solution ended up being one that I wasn’t all that wild about, but there wasn’t much I could do about it since Microsoft setup the model as to how .NET and COM interact. 

So here’s the solution…within .NET, there is something called the GAC (Global Assembly Cache).  The GAC is where system wide assemblies get installed.  It’s a special location that requires administrator rights to install into.  It’s also a place that requires assemblies to have strong names, which means that every library linked to the library must have a strong name…ie., more work for me.  Anyway, what it comes down to is that to implement COM, a new library: MARCEngine.dll and MARCEngine.tlb were created to wrap the .NET functionality being exposed.  On installation, the MARCEngine.dll library is installed into the GAC…but so are the mengine60.dll, the marc82utf8.dll and the meUTF2MARC.dll libraries because they are directly referenced to the MARCEngine.dll library. 

I had hoped that I would be able to avoid dealing with the GAC and simply register the generated TypeLib if possible — but there were a number of issues with that — the primary one being that the TypeLibrary in .NET only provides early-binding functionality, something not allowed in scripting languages like VBscript, hence the necessary of COM (for power users) made working with the GAC unavoidable.  Right now, I am testing three things:

  1. On install/reinstall, the libraries and GAC are being refreshed rather than having objects installed side-by-side (Think DLL-Hell without the fun)
  2. That if a guest user installs the program, that just the COM functionality is simply disabled — and the rest of the program installs normally (I personally am running the program off a USB key most of the time, so this is important to me)
  3. That the Object is just being registered once it gets outside my controlled enviroment. 

The nice thing is, if a user installs without the necessary permissions to install the COM, the bootloader that does the registration will be in the program directory so COM setup can be done at a later time.

Anyway, lots of work yet todo.  I’m hoping that I’ll get the OK from my testers in the next day or two, and given no problems, I’ll be looking at posting the revision on Tuesday or Wed.