Mine Field of Excel Development Tools – Part 5

Deployment – or as far as I got with it

So let’s recap: You have managed code. You have a shim to execute the managed code. Now you need to get this to another system.

18. Create another project: Other Project Types, Setup and Deployment, Setup Project.
19. For the File System setup, add the Primary Output from all three of the other projects: ManagedAggregator, the shim, and the shared addin (MyClass).
20. You may need to manually add other DLL assemblies required to support MyClass because it doesn’t seem like the setup detects all dependencies. As an example, and a real surprise, the Extensibility.DLL file is not automatically added to the setup package. Is this a bug? That file can be found in:
                C:\Program Files\Common Files\
                Microsoft Shared\MSEnv\PublicAssemblies
21. In many articles you’ll see questions about how these Primary Output packages should be registered. If you look at Properties for each of the output packages you’ll see vsdrpCOM for the managed assemblies. Surprisingly to me, the shim is set to vsdrpDoNotRegister. Is this a deployment issue? Note that other options are vsdrpCOM and vsdrpCOMSelfReg. When adding assemblies to this list manually rather than using the Primary Output, you will also see vsdraCOM. A lot has been written in blogs about what these settings are and what they should be – and a lot of the info out there is conflicting. Caveat emptor.
22. Finally on this topic, you’ll see office.dll and mscorlib.tlb have been added to the Application Folder. I have no idea what the Type Library file is there for. The office.dll is obviously the link into Microsoft Office apps.
23. Build everything. It will take a while even on a fast system. When it’s done you’ll have an MSI file and a Setup.exe in bin\Release for the setup project. Again, much has been said about whether to use the MSI or Setup.exe for deployment. My recommendation based on a lot of reading is to put both files on the deployment system and use the Setup file to install. It (probably) can’t hurt.

As I’ve said, if you install on a development system, the stuff works as expected. Is that due to VS2005? .NET Framework SDK rather than the redistributable? I have no clue.

The deployment system will certainly need the Office 2003 Primary Interop Assembly Redistributable. After installation the shim is in the Automation Server list but not in the Function Wizard (fx) and the functions don’t work.

Experimentation time!

I thought maybe the assemblies weren’t properly registered so I created a BAT file to regasm everything:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
                                             regasm /codebase Extensibility.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
                                             regasm /codebase Office.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
                                             regasm /codebase ManagedAggregator.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
                                             regasm /codebase Shared.dll

Notice the full path to regasm because the .NET path isn’t in the PATH. Also notice the order of the instructions, with Extensibility first to ensure that it’s registered before any of the others try to register. Surprisingly to me the Shared.dll (containing MyClass) failed to register unless Extensibility was registered first. Notice the shim isn’t there – remember it’s a COM component, not managed .NET.

Err, none of that helped.

Maybe the COM shim wasn’t registered. "regsvr32 ShimName.dll". This does "something" on the deployment workstation. In my code I added logging functions to everything I could in MyClass and the ManagedAggregator, etc.. I instantiate a logger that registers whenever any method is executed. When the COM shim is registered the COMRegisterFunction method is executed! This doesn’t happen on the development system and yet the code works there anyway. When this is done the ‘Connect Class’ registration shows up in the list of registered addins. That’s nice, something changed, but still none of the functions work. In my development system my logs are updated by method invocations but those attribute-decorated methods are never executed.

I thought security was the issue so I created another BAT file:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\
                   caspol -u -ag 1 -url "C:\path.to.assemblies\*" FullTrust

No joy.

As to the benefits of shimming….

Oh yeah, when I execute the =GetAppDomain() formula it returns "Default Domain". This is concerning because I thought the code was supposed to be running in a separate app domain. Any hints?

Summary of all summaries

I’d be happy to fire up a GoToMeeting session for someone from Microsoft to look at this, or to try recommendations based on the information provided above. If nothing else I hope this helps someone else to at least get to this same point – LOL, and hopefully get all the way to deployment.