Home |
Search |
Today's Posts |
#1
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
We are developing a managed .NET shimmed COM addin for Excel in Visual Studio
2003. We also have an automation addin project in this solution that does not have its own shim. We recently added the shim for the COM addin. After shimming our COM addin we found that both addin types now unexpectedly run in the same app domain. We are outputting AppDomain.CurrentDomain.FriendlyName in both addins to verify where they run. To our surprise, they both have the same friendly name as we defined in the shim C++ code for the COM addin. We had expected the un-shimmed automation addin to remain in its original, default app domain space. The automation addin does reference other projects in this solution. This doesn't seem likely, but do the references in the automation addin to projects in the COM addin cause it to be loaded by Excel into the COM app domain? Can we expect both addin types to stay in the same app domain when installed on client machines? Does anyone have any idea why both addin types load into the same app domain? Any light you can shed on this would be greatly appreciated. |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
Installing Addin via Automation | Excel Programming | |||
Referencing a com addin from a .net application via ole automation | Excel Programming | |||
addIn functions in automation | Excel Programming | |||
May be Automation AddIn loading problem!! | Excel Programming | |||
Automation COM Addin with Excel | Excel Programming |