MindManager 7 ToDoList AddIn development Part 4: Fixing the Registry Settings in the Setup Project

The MM VS2005 AddIn wizard created a set of Registry settings for my project, and the friendly folks at Mindjet’s Dev Support team helped me fix a problem with my project (and in the process had to remove most of those Registry settings). Well, now we’re taking it back [anyone else remember Bono’s intro to Helter Skelter?].

It took me a bit of time to track down the hidden place where Visual Studio “hides” the Registry settings for a Setup project: right-click the Setup Project (“AddInSetup_en” in this case), choose View, Registry. There’s a stub for each hive, but not all of them contain actual Registry Keys or Values.

For my project, the only Key with any entries was HKLM\Software\Mindjet\MindManager\7\AddIns, with the Values (though different settings) that I’d noted earlier. The ProgID that it’s setting is ParanoidMike.ToDoListBuilder.AddIn which isn’t really representative of what I’m intending to release – ToDoListBuilder is just one portion of the functionality I want to provide (i.e. I’ve also spec’d out a ToDoListManager class that’ll be a peer to ToDoListBuilder).

Also, if I’m going to define a namespace rooted in ParanoidMike, I figure I should use the application name as the next-level-down, and then describe the actual code/app/add-in as the third-level-down. That gives me the namespace ParanoidMike.MindManager.ToDoListAddIn, so I’ve replaced the existing ProgID with this as the new ProgID (and .NET namespace for my source code). I deleted the old Registry entries that reference this ProgID, added the new ProgID and its entries, and also added the HKCR settings that were still missing when I published this article.

That results in the following Registry entries populated in the AddInSetup_en project:

Complete Set of Registry Entries for MM7 Add-in

HKLM\Software\Mindjet\MindManager\7\AddIns

Value

Data type

Setting

Description REG_SZ MindManager ToDoList AddIn for MM7 – Built by ParanoidMike
FriendlyName REG_SZ MM7ToDoList
LoadBehavior REG_DWORD 2

HKCR\ParanoidMike.MindManager.ToDoListAddIn

Value

Data type

Setting

(Default) REG_SZ ParanoidMike.MindManager.ToDoListAddIn

HKCR\ParanoidMike.MindManager.ToDoListAddIn\CLSID

Value

Data type

Setting

(Default) REG_SZ {33B60353-E8F3-4F38-98B6-41C7E5C6D32B}

Note: this little tip (HowTo: Create a Default Registry Value in Registry Editor) saved me a lot of trouble futzing around with these infrequently-created values.

Note: if you’ve used the MM7 AddIn template for Visual Studio, the CLSID above can be found in the Connect.cs file just under the ///

comment, like so:

GuidAttribute("33B60353-E8F3-4F38-98B6-41C7E5C6D32B")

Open Issue: ProgID versioning

There’s conflicting evidence on whether it’s best to create the ProgID using the “.1” suffix notation, so that the ProgID can be rev’d, or whether it’s just as good to leave it without the “.1” suffix and replace it upon every install (upgrade?). For the moment, until I stumble across anything better, I’m just going to leave it without.

Open Issue: ProgId in AddIn’s source code

After cleaning out the old entries from my computer’s Registry and testing this new set of code, I noticed that there was still the old ProgId referenced in the Connect.cs code:

    /// 
    ///   The object for implementing an Add-in.
    /// 
    ///    
    [
     CLSCompliant(false),
     ComVisible(true),
     GuidAttribute("33B60353-E8F3-4F38-98B6-41C7E5C6D32B"), ProgId("ParanoidMike.ToDoListBuilder.AddIn")
   ]

Since the add-in loaded and executed successfully, I’m now left to wonder what effect this ProgId entry is really supposed to have. Clearly it doesn’t affect the operations of debugging the code (i.e. hitting F5 from within Visual Studio 2008 and waiting for MindManager to launch), but I can’t imagine it’s just there for decoration either. It’s possible that, because I haven’t rebooted since I cleaned out the Registry and updated the AddInSetup_en project settings, there’s still enough of this information cached to allow the Add-in (with the same CLSID) to still work.

I’m taking no chances of a vaguely-specified error down the line, so I’ve updated this ProgId entry to the current value, but if anyone knows how these entries are related, I’d sure love to hear it.

Advertisements

One thought on “MindManager 7 ToDoList AddIn development Part 4: Fixing the Registry Settings in the Setup Project

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s