This project has moved and is read-only. For the latest updates, please go here.


Jan 7, 2012 at 8:38 PM


I'm from Argentina. I'm an engineer and for several years I have developed analysis tools using Excel and VBA. Last year I decided it was time to change and now I'm slowly developing my tools in .NET (C#)
I've been exploring your fantastic project for about three weeks. I was able to combine DNA/NetOfficefollow your examples for developing COM Add-ins using only NetOffice (I prefer this approach because I did not find similar tools for Word or PowerPoint DNA), etc..
And now I have the following concerns: Many authors recommend Shimming:  avoid  MSCOREE.DLL Hell (eg Andrew Whitechapel).
Your examples finish a step before, registering the dll as they have been compiled.
What are your recommendations?
Have you tried shimming the solution?
You have developed an example we can follow?



Jan 8, 2012 at 8:17 PM

hello marco,

the following workarround works with NetOffice and the MS Interop Assemblies as well.

1.) Make sure you have VC++ installed in Visual Studio
2.) Install the COM Shim Wizard for VS2010
3.) Create a Addin project with NetOffice or Interop assemblies
4.) don register this addin project for COM Interop
5.) add a COM Shim project to the solution, follow the wizard and read
6.) now you have a native Shim proxy for your addin(need a register with regsvr32 or install api on other systems)

i create an excel addin sample and add the project to the download section

*best regards to Argentina

Jan 8, 2012 at 11:01 PM

Thank you very much,

It's amazing you can respond so quickly!

I downloaded your example and I will try your recommendations this week.
As I am a user of # Develop, I'm downloading Visual C + + Express to test COM Shim Wizard and analyze your example. (I hope can use this version of VS)

I'll let you know my progress.
Thanks again,

Jan 8, 2012 at 11:06 PM

Hi Marco,

If you are using Excel-DNA with NetOffice, and making an Excel-DNA add-in that references the NetOffice assemblies (instead of a COM add-in that is registered in the registry directly), your add-in is effectively shimmed already. The unmanaged part of the Excel-DNA .xll will load the .NET runtime and create a separate AppDomain where your add-in will reside. So you need no other C++ shim in this case.

Of course this only applies to Excel add-ins.



Jan 9, 2012 at 2:34 AM

Hi Govert.

I know,

In fact, while waiting for the response of Sebastian, I read the Discussion

Your final post clarifies the situation.

Then, I tried \ Distribution \ Samples \ ComServer.


Some things I'd like to know more detail are: (Taking the example of ComServer)


* BuildSample.bat: 

What exactly happens when you run regsvr32.exe ComServerPacked.xll?

What are the entries that are included in the registry?

Have you Know any utility that allows capture those entries? (I think something like regasm regfile :...)


* ComServerSample.dna:

What exactly happens when you run ComServer. (un) DllRegisterServer ()?

What are the entries that are included in the registry?

I have analyzed the source code, but as I have never programmed, I can hardly keep your code.


* How are handled dependencies when running ExcelDnaPack.exe?

I understand that, as indicated PackDep.dna, the libraries are included in the xll if specified <Reference Pack="true" AssemblyPath="DepLib.dll" />

What are your recommendations?

NetOffice libraries and other (eg, usually I have my own library of utilities)

It should be packaged or leave them outside? What are the advantages of each method?


thank you very much


Jan 9, 2012 at 7:45 AM

Hi Marco,

The Excel-DNA part of this discussion is probably better to continue on the Excel-DNA Google group:

Registration of the Com Server classes is under HKEY_CURRENT_USER\Software\Classes\. You'll easily see what's going on if you look in the registry, but the code is in ExcelDna.Integration\ComServer.cs. Invoking regsvr32.exe will eventually call ComServer.DllRegisterServer(), so they do exactly the same work.

Entries are basically:


 "HKEY_CURRENT_USER\Software\Classes\" + ProgId
 "HKEY_CURRENT_USER\Software\Classes\" + ClsId + .... (InprocServer32 etc.)


and possibly a TypeLib entry under HKEY_CURRENT_USER\Software\Classes\TypeLib\. The "server" for the COM type is registered as the .xll, which has the correct exports to be a COM Server.

You can have the various NetOffice assemblies packed by adding the <Reference Path="..." Pack="true" /> tags in the .dna file, exactly as you show. It does not work for mixed code (assemblies that contain native code). I packed the files LateBinding.Core.dll, ExcepApi.dll, OfficeApi.dll, DaoApi.dll and a small add-in library into an .xll recently, and the resulting size was 726KB. 

The packing works fine in my experience, and it's pretty nice to have a single-file add-in. Packing does change how those assemblies are loaded by .NET (they are in a different "Load context") which can sometimes cause confusion. It just makes deployment much easier, but is not crucial to the add-in structure or how it works. If you want to have many add-ins in the same directory that share the NetOffice libraries, it might make sense not to pack them.

Packing or not is a decision you can take very late, once everything works.