I read you webblog about the Office 2003 PIA installed in the GAC. I have found several issues that make this solution extremely problemmatic for developers.

First, I currently compile my Visio 2002 addin on a box that does not have visio on it. I can do this beacuse I reference the Office XP PIA's directly. I have ported my Addin to Visio 2003 and found that I can't install the Visio 2003 PIA without installed visio 2003 on my build box. So no I am forced to install another copy of visio 2003 on my build box so the PIA will show up in GAC.

Secondly, I have to support both versions of Visio for my addin. I have both versions installed on my development box. When switching between the two versions, a configuration process is run. This process only runs when running the opposite verison of Visio from the last version that was run. I have noticed that when I run Visio 2002, and the config process is run, it messes up the Visio 2003 PIA in the GAC. When I go to compile my addin, I have to run RegAsm on the Visio 2003 PIA to get the reference to validate.

Any comments on my issues would be greatly appreciated. Please feel free to repost my comments if you like.

Thanks

Mike


Using the PIA redist without Microsoft Office System 2003 is just not a good idea, which is why we went to some lengths to prevent it. The redist is meant to be a runtime solution for redistributing the PIA's to your clients using the Microsoft Office System 2003. 

For example, if you have a PIA registered for a type libary but you don't have the type library on the system, OLEAUT can get into a bad state.  In the PIA case, let's say you have Microsoft Excel 2002 (version 10) installed and registered on your system.  Your type library is version 1.4.  Let's say the PIA for Office 2003 gets registered and you didn't update Office.  This means you have a PIA for version 1.5, but a type library for 1.4.  While the PIA can be happy (sort-of) OLEAUT isn't.  If you reference the type library from anywhere other than Excel's VBA project (which has some resiliency to this versioning issue), referencing the type library will OLEAUT.  OLEAUT will walk the registry and see versions 1.4 and 1.5.  It doesn't know that 1.5 doesn't really have a type library.  So it tries to get the type library for 1.5.  This then results in a failure because the 1.5 type library isn't present or registered.  (The 1.5 type library BTW lives as a Win32 resource in Excel.exe.)  OLEAUT then does NOT unwind to use an older version (like 1.4, which IS present.)  It just fails. 

To sum up that long explanation: registering a newer PIA than you have a type library for will work, but OLE will fail, and LOTS of things use type libraries.  (I'm not sure here, but embedded objects of Excel may stop working there, or in your case, Microsoft Visio.) 

I am personally unfamiliar with Visio's "side-by-side" running nature, but is sounds like they re-register their type library using standard system calls to make sure that the right version is registered (likely for the same reasons as stated above.)  Perpaps you can respond with who's doing configuration?  Is there some custom code running? 

Anyway, what's probably happening is that the type library is getting re-registered.  When that happens, the call that registers the type library first wipes out all child keys and values from the root of [HKCR]\typelib\[TYPELIB_GUID]\[version]\.  This means the PIA registration goes away!  We've been working with other teams to try to remedy these problems at least at installation time, but something like changing regtlib.exe would be difficult to do, since it's worked this way for over a decade. 

While I know this doesn't really solve the problems, I hope it provides you some insight as to why they exist.  If there's some custom config code you have for switching the Visio versions... we can work with that.  Let me know if it's not custom code that's switching Visio versions. 

Thanks!

- Art


 This posting is provided "AS IS" with no warranties, and confers no rights.