[V0.29-RC] Question about COM servers new feature
337 views
Skip to first unread message
Ron
May 17, 2011, 7:17:06 AM5/17/11
to Excel-DNA
Hi Govert,
I am very interested in the feature about COM server as I am currently
working on the same kind of issues.
I understand that for deploying the COM server, we always need to
register the xll file on user's pc, right ?
My question is : what is the added value of building and registering
the xll file while we could directly register the dll file (which
contains com visible classes) ?
More precisely : I have a project in .Net using DNA that is not com
visible. I wrote a tool which analyzes the assembly using reflection
and build another assembly which is com visible and exposes the types
from the first assembly to COM (so the developer doesn't have to worry
anymore about COM interoperability).
Finally, to make it work, I need to register the final assembly and I
use a command like "regasm /tlb /codebase".
In full DNA mode, I won't register the dll with regasm, but I will
build the tlb file with tlbexp, then create the xll with
ExcelDnaPack.exe and finally register the xll with regsvr32.
So what are the advantages in doing so ?
I have another question : did you look for a way of making the xll
work without registering ? I worked on a registration free mechanism,
using manifest files. But finally it is a true nightmare and it
doesn't seem to always work (I didn't finished and I am a little bit
bored). Am I a dreamer ?...
Ron
I am very interested in the feature about COM server as I am currently
working on the same kind of issues.
I understand that for deploying the COM server, we always need to
register the xll file on user's pc, right ?
My question is : what is the added value of building and registering
the xll file while we could directly register the dll file (which
contains com visible classes) ?
More precisely : I have a project in .Net using DNA that is not com
visible. I wrote a tool which analyzes the assembly using reflection
and build another assembly which is com visible and exposes the types
from the first assembly to COM (so the developer doesn't have to worry
anymore about COM interoperability).
Finally, to make it work, I need to register the final assembly and I
use a command like "regasm /tlb /codebase".
In full DNA mode, I won't register the dll with regasm, but I will
build the tlb file with tlbexp, then create the xll with
ExcelDnaPack.exe and finally register the xll with regsvr32.
So what are the advantages in doing so ?
I have another question : did you look for a way of making the xll
work without registering ? I worked on a registration free mechanism,
using manifest files. But finally it is a true nightmare and it
doesn't seem to always work (I didn't finished and I am a little bit
bored). Am I a dreamer ?...
Ron
Govert van Drimmelen
May 17, 2011, 4:44:46 PM5/17/11
to Excel-DNA
Hi Ron,
I'll split your questions into three parts.
1. "I understand that for deploying the COM server, we always need to
MyAddin.xll (possibly as part of an installer), or alternatively call
ExcelDna.ComInterop.ComServer.RegisterServer() from your add-in's
AutoOpen, or from a menu item or something. These write exactly the
same registry entries, and can be unregistered the same way.
Registration only writes to HKEY_LOCAL_USER, so there should be no
permissions issues.
Your description of the workflow is right. The same classes that would
have been registered by Regasm will be registered by Excel-DNA, so you
still need some care with [assembly:ComVisble(true)] and to deal with
the ClassInterface issues.
2. " what is the added value ..." / "So what are the advantages in
doing so ? "
(Disclaimer: I am not entirely convinced that this is a useful
feature, and it wasn't my idea.)
But the motivations are to do three things that needed some Excel-DNA
support to be built in:
* You can make RTD servers that can be called directly from the sheet
with =RTD(...) with no wrapper. And such an RTD server can have its
old values preserved (return 'false' for newValues in ConnectData -
see this discussion: http://groups.google.com/group/exceldna/browse_frm/thread/ad6163ef47ace53d/6743dce0b956d131.
For this to work, don't call XlCall.RTD(...) in your wrapper, but call
the native XlCall.Excel(XlCall.xlfRtd,....).)
* Your COM classes / RTD servers are instantiated in the same
AppDomain as the Excel-DNA add-in, which means your UDFs can share
data with your COM classes. So you can make an alternative way to call
your functions from VBA, nicer than Application.Run, and still have a
shared cache, configuration etc.
* You can pack everything into a single .xll (that does the COM
registration when it is opened).
I suspect this might be a useful feature in putting together a
flexible VBA -> .NET migration story.
3. "did you look for a way of making the xll work without
registering ?"
Indeed. When doing the RTD integration last year, I also tried for a
while to use the registration-free COM interop. After diving into the
manifests and experimenting the the Activation Context APIs, I gave
up. There are two serious complications for using these in the Excel-
DNA case:
* The add-in is running in a 'foreign' process, so I don't want to do
anything that could cause process-wide interactions,
* I wanted to continue with the dynamic structure of the Excel-DNA add-
ins, where a single binary (.xll) is used to load the different add-
ins.
The Activation Context APIs seem like the right interface to use, but
I just couldn't make it fit what I wanted to do.
Initially I didn't want to write to the registry at all. The only
other option I could think of was to install a hook to intercept the
library calls to COM functions like ProgIDFromCLSID. That seemed like
an ugly and dangerous hack, so I didn't even try.
By then I had a look at the registry again, realised I can do all the
COM registration I need under HKEY_LOCAL_USER, so there are no
permission issues, and I saw how much Excel writes to the registry
during a normal session anyway. So I stopped trying to fight obscure
APIs, and just put the stuff in the registry when needed. For the
Ribbon, CTPs and most of the RTD server support, Excel-DNA leaves
nothing in the registry - it writes the entries just-in-time before
the COM classes are loaded be Excel, then deletes those entries again.
For the new COM server support, the COM classes and RTD servers can be
made available to Excel even if the add-in is not loaded. Basically
the .xll replaces mscoree.dll as the unmanaged host for the managed
COM classes.
I hope you have many more questions :-)
Kind regards,
Govert
I'll split your questions into three parts.
1. "I understand that for deploying the COM server, we always need to
register the xll file on user's pc, right ?"
There are two ways to do the registration. Either run regsvr32.exe
MyAddin.xll (possibly as part of an installer), or alternatively call
ExcelDna.ComInterop.ComServer.RegisterServer() from your add-in's
AutoOpen, or from a menu item or something. These write exactly the
same registry entries, and can be unregistered the same way.
Registration only writes to HKEY_LOCAL_USER, so there should be no
permissions issues.
Your description of the workflow is right. The same classes that would
have been registered by Regasm will be registered by Excel-DNA, so you
still need some care with [assembly:ComVisble(true)] and to deal with
the ClassInterface issues.
2. " what is the added value ..." / "So what are the advantages in
doing so ? "
(Disclaimer: I am not entirely convinced that this is a useful
feature, and it wasn't my idea.)
But the motivations are to do three things that needed some Excel-DNA
support to be built in:
* You can make RTD servers that can be called directly from the sheet
with =RTD(...) with no wrapper. And such an RTD server can have its
old values preserved (return 'false' for newValues in ConnectData -
see this discussion: http://groups.google.com/group/exceldna/browse_frm/thread/ad6163ef47ace53d/6743dce0b956d131.
For this to work, don't call XlCall.RTD(...) in your wrapper, but call
the native XlCall.Excel(XlCall.xlfRtd,....).)
* Your COM classes / RTD servers are instantiated in the same
AppDomain as the Excel-DNA add-in, which means your UDFs can share
data with your COM classes. So you can make an alternative way to call
your functions from VBA, nicer than Application.Run, and still have a
shared cache, configuration etc.
* You can pack everything into a single .xll (that does the COM
registration when it is opened).
I suspect this might be a useful feature in putting together a
flexible VBA -> .NET migration story.
3. "did you look for a way of making the xll work without
registering ?"
Indeed. When doing the RTD integration last year, I also tried for a
while to use the registration-free COM interop. After diving into the
manifests and experimenting the the Activation Context APIs, I gave
up. There are two serious complications for using these in the Excel-
DNA case:
* The add-in is running in a 'foreign' process, so I don't want to do
anything that could cause process-wide interactions,
* I wanted to continue with the dynamic structure of the Excel-DNA add-
ins, where a single binary (.xll) is used to load the different add-
ins.
The Activation Context APIs seem like the right interface to use, but
I just couldn't make it fit what I wanted to do.
Initially I didn't want to write to the registry at all. The only
other option I could think of was to install a hook to intercept the
library calls to COM functions like ProgIDFromCLSID. That seemed like
an ugly and dangerous hack, so I didn't even try.
By then I had a look at the registry again, realised I can do all the
COM registration I need under HKEY_LOCAL_USER, so there are no
permission issues, and I saw how much Excel writes to the registry
during a normal session anyway. So I stopped trying to fight obscure
APIs, and just put the stuff in the registry when needed. For the
Ribbon, CTPs and most of the RTD server support, Excel-DNA leaves
nothing in the registry - it writes the entries just-in-time before
the COM classes are loaded be Excel, then deletes those entries again.
For the new COM server support, the COM classes and RTD servers can be
made available to Excel even if the add-in is not loaded. Basically
the .xll replaces mscoree.dll as the unmanaged host for the managed
COM classes.
I hope you have many more questions :-)
Kind regards,
Govert
Ron
May 18, 2011, 4:24:29 AM5/18/11
to Excel-DNA
Wow, that's a very complete answer !
Thanks for the details, I will try to use the auto-registering
mechanism. If it actually writes only in HKEY_LOCAL_USER, then the
deployment won't be a problem anymore. Moreover, if I just can put the
xll on the user's computer, without registering anything at the
moment, it would be very nice.
I hope I will have many more questions !
Thanks,
Ron
> see this discussion:http://groups.google.com/group/exceldna/browse_frm/thread/ad6163ef47a....
Thanks for the details, I will try to use the auto-registering
mechanism. If it actually writes only in HKEY_LOCAL_USER, then the
deployment won't be a problem anymore. Moreover, if I just can put the
xll on the user's computer, without registering anything at the
moment, it would be very nice.
I hope I will have many more questions !
Thanks,
Ron
Ron
May 18, 2011, 10:35:46 AM5/18/11
to Excel-DNA
Ok, I played a little bit more with the com server feature and I must
admit that it is awesome !
My only issue is that "AutoClose" seems not to be called every time
you close Excel, but it would be the perfect place to unregister.
I am pretty sure that if I add an UDF for unregistering, nobody will
ever call it...
Do you have any idea ? I wouldn't like to have to put some VBA code
into user's spreadsheet (as I don't want to be responsible of VBA
code).
I could also not care about unregistering, but that is not so
professional !
Regards,
Ron
admit that it is awesome !
My only issue is that "AutoClose" seems not to be called every time
you close Excel, but it would be the perfect place to unregister.
I am pretty sure that if I add an UDF for unregistering, nobody will
ever call it...
Do you have any idea ? I wouldn't like to have to put some VBA code
into user's spreadsheet (as I don't want to be responsible of VBA
code).
I could also not care about unregistering, but that is not so
professional !
Regards,
Ron
Govert van Drimmelen
May 18, 2011, 11:46:53 AM5/18/11
to Excel-DNA
Hi Ron,
Indeed, I couldn't come up with a good unregister scheme, and this is
a disadvantage of this feature.
I don't think there is an easy way to know when to unregister.
AutoClose is problematic - Excel-DNA only calls you add-in's AutoClose
when the add-in is removed from the add-in manager. Internally Excel
calls AutoClose too early - that's a known bug.
I think there is a way to reliably know that Excel is closing or your
add-in is being removed (without using VBA). You can implement a COM
add-in in your Excel-DNA add-in just like the Ribbon and CTP support
is done: Make a class that derives from ExcelComAddIn and then call
ExcelComAddInHelper.LoadComAddIn(...) to load an instance. Override
OnDisconnection or OnBeginShutdown to be notified when Excel closes or
the add-in is removed. But even that is not a good place to
unregister, because multiple instances of Excel might be running. So
you'd need some sort of inter-process semaphore scheme.
But anyway, I think one of the main uses of the feature - the RTD old
values story - require that the registration should be in the registry
even if the add-in is not loaded. And I'm not sure any VBA code that
the COM classes should break just because you remove the add-in. I
guess it depends on how you think about the COM activated classes -
are they a dependent part of the add-in or an orthogonal entry point
into the managed code.
I'd probably suggest having an explicit uninstall macro that cleans
up, with a button that the user presses if they want to remove the add-
in?
If you want to be super-professional, I guess you could make a Windows
installer, which calls "Regsvr32.exe /u MyAddin.xll" when
uninstalling. But that kind of complication is too much for me.
Why do you think this is a useful feature?
How do you plan to use it?
Cheers,
Govert
Indeed, I couldn't come up with a good unregister scheme, and this is
a disadvantage of this feature.
I don't think there is an easy way to know when to unregister.
AutoClose is problematic - Excel-DNA only calls you add-in's AutoClose
when the add-in is removed from the add-in manager. Internally Excel
calls AutoClose too early - that's a known bug.
I think there is a way to reliably know that Excel is closing or your
add-in is being removed (without using VBA). You can implement a COM
add-in in your Excel-DNA add-in just like the Ribbon and CTP support
is done: Make a class that derives from ExcelComAddIn and then call
ExcelComAddInHelper.LoadComAddIn(...) to load an instance. Override
OnDisconnection or OnBeginShutdown to be notified when Excel closes or
the add-in is removed. But even that is not a good place to
unregister, because multiple instances of Excel might be running. So
you'd need some sort of inter-process semaphore scheme.
But anyway, I think one of the main uses of the feature - the RTD old
values story - require that the registration should be in the registry
even if the add-in is not loaded. And I'm not sure any VBA code that
the COM classes should break just because you remove the add-in. I
guess it depends on how you think about the COM activated classes -
are they a dependent part of the add-in or an orthogonal entry point
into the managed code.
I'd probably suggest having an explicit uninstall macro that cleans
up, with a button that the user presses if they want to remove the add-
in?
If you want to be super-professional, I guess you could make a Windows
installer, which calls "Regsvr32.exe /u MyAddin.xll" when
uninstalling. But that kind of complication is too much for me.
Why do you think this is a useful feature?
How do you plan to use it?
Cheers,
Govert
Ron
May 18, 2011, 1:20:50 PM5/18/11
to Excel-DNA
I like the idea of making my application as simple as possible. So the
inter-process semaphore scheme does not seduce me.
A tool to clean up can be a good idea. Finally, I don't think it would
be a big problem to not unregister classes on user's computer (because
we will rarely remove classes, rather update or add).
The matter with registration is more for the developer : I often break
my debug session and forget to unregister. Then I rebuild and test
again, etc. Finally, I have now a lot of "ghost" referenced assemblies
and it can sometimes disturb my tests. Ok, I guess the AutoClose
wouldn't solve my problem anyway.
About my needs : I have to build a tool with UDF functions callable
from the sheet, but also with objects available in VBA (users always
love VBA, that's painful for developers).
So I use DNA for the first need and it is very helpful (some little
changes in the architecture and even the RTD server is great !).
I didn't wait for DNA to make the com server. As I told before, I want
a tool which allow the developer not to know anything (or almost)
about com interoperability. That's why I made a tool which auto-
generate a com server dll, calling the previous dll (not so hard, just
a big pleasure when you have to deal with ref/out arrays of custom
objects !).
Finally my tool used to register the com server at the end of each
build, in order to make the developer able to test. But I don't really
like this way (we don't need to test the com server after each build).
So the dynamic registration is nice.
One of the most important features : always being in the same domain.
Now my users will be able to share the data cache between the sheet
and the VBA code. So they can mix simple UDF calls in cells and bigger
macros.
Last but not least : I won't have to fight against architect and
support teams for deployment process, as I don't need anymore to
register the dll with admin rights.
All I found for that was making manifest files but it involved in
modifying Excel directory and it wasn't really better...
I will be pleased to to answer if you have more questions.
Cheers,
Ron
inter-process semaphore scheme does not seduce me.
A tool to clean up can be a good idea. Finally, I don't think it would
be a big problem to not unregister classes on user's computer (because
we will rarely remove classes, rather update or add).
The matter with registration is more for the developer : I often break
my debug session and forget to unregister. Then I rebuild and test
again, etc. Finally, I have now a lot of "ghost" referenced assemblies
and it can sometimes disturb my tests. Ok, I guess the AutoClose
wouldn't solve my problem anyway.
About my needs : I have to build a tool with UDF functions callable
from the sheet, but also with objects available in VBA (users always
love VBA, that's painful for developers).
So I use DNA for the first need and it is very helpful (some little
changes in the architecture and even the RTD server is great !).
I didn't wait for DNA to make the com server. As I told before, I want
a tool which allow the developer not to know anything (or almost)
about com interoperability. That's why I made a tool which auto-
generate a com server dll, calling the previous dll (not so hard, just
a big pleasure when you have to deal with ref/out arrays of custom
objects !).
Finally my tool used to register the com server at the end of each
build, in order to make the developer able to test. But I don't really
like this way (we don't need to test the com server after each build).
So the dynamic registration is nice.
One of the most important features : always being in the same domain.
Now my users will be able to share the data cache between the sheet
and the VBA code. So they can mix simple UDF calls in cells and bigger
macros.
Last but not least : I won't have to fight against architect and
support teams for deployment process, as I don't need anymore to
register the dll with admin rights.
All I found for that was making manifest files but it involved in
modifying Excel directory and it wasn't really better...
I will be pleased to to answer if you have more questions.
Cheers,
Ron
Govert van Drimmelen
May 18, 2011, 5:26:47 PM5/18/11
to Excel-DNA
Hi Ron,
That sounds pretty much like the intended use.
One day we'll get those VBA users to use Excel-DNA and .NET too...
Maybe for your development cycle you can add a pre-build step that
unregisters by calling regsvr32.exe /u MyAddin.xll on the old, pre-
build, .xll (if it exists). That way you are unregistering with the
old library, so it should clean up properly, and then you build a new
library that is not registered, so you can test from there.
Regards,
Govert
> > > > > On May 17,...
>
> read more »
That sounds pretty much like the intended use.
One day we'll get those VBA users to use Excel-DNA and .NET too...
Maybe for your development cycle you can add a pre-build step that
unregisters by calling regsvr32.exe /u MyAddin.xll on the old, pre-
build, .xll (if it exists). That way you are unregistering with the
old library, so it should clean up properly, and then you build a new
library that is not registered, so you can test from there.
Regards,
Govert
>
> read more »
Ron
May 20, 2011, 4:55:30 AM5/20/11
to Excel-DNA
Hi Govert,
That's a good idea. I added a macro in VS which unregister the xll if
it exists. It is not the ultimate solution but it is much cleaner.
I have another question (and I think I have the answer too, but I can
try) : for UDF functions, I use ExcelDNA.Integration.RegisterMethods
methos, so I can decide which UDF I want to expose, according to the
user's profile.
Would it be possible to do so with COM server ?
"ComServer.DllRegisterServer()" registers everything in the assembly.
Could there be a way of doing so only for a chosen class ?
Thanks
Ron
> ...
>
> read more »
That's a good idea. I added a macro in VS which unregister the xll if
it exists. It is not the ultimate solution but it is much cleaner.
I have another question (and I think I have the answer too, but I can
try) : for UDF functions, I use ExcelDNA.Integration.RegisterMethods
methos, so I can decide which UDF I want to expose, according to the
user's profile.
Would it be possible to do so with COM server ?
"ComServer.DllRegisterServer()" registers everything in the assembly.
Could there be a way of doing so only for a chosen class ?
Thanks
Ron
>
> read more »
Govert van Drimmelen
May 20, 2011, 11:45:47 AM5/20/11
to Excel-DNA
Hi Ron,
Nope, no support for runtime-selection of what you register. At
compile-time you can of course determine which types are to be
exported by marking them with [ComVisible(true/false)].
But the registration only involves writing some registry entries, so
you could implement your own registration scheme very easily - start
with a copy of ExcelComClassType.RegisterServer and fill in the bits
you need from the type information. Excel-DNA will be ready to provide
a ClassFactory for any of the COM-visible types, so I don't think you
need to make any changes to the Excel-DNA runtime to support this.
Are you otherwise happy that this version works OK?
Regards,
Govert
> > > > > > > up. There are two serious complications for...
>
> read more »
Nope, no support for runtime-selection of what you register. At
compile-time you can of course determine which types are to be
exported by marking them with [ComVisible(true/false)].
But the registration only involves writing some registry entries, so
you could implement your own registration scheme very easily - start
with a copy of ExcelComClassType.RegisterServer and fill in the bits
you need from the type information. Excel-DNA will be ready to provide
a ClassFactory for any of the COM-visible types, so I don't think you
need to make any changes to the Excel-DNA runtime to support this.
Are you otherwise happy that this version works OK?
Regards,
Govert
>
> read more »
Ron
May 20, 2011, 11:55:02 AM5/20/11
to Excel-DNA
The runtime-selection is not an emergency so I will see later. I am
quite curious about the ClassFactory.
I finished the integration of the new DNA version today, and all tests
are good. So on my side I will continue to work with it, waiting for
the official version.
And yes, I am very happy with that version, the new com server
features make my application very impressive !
Cheers,
Ron
> ...
>
> read more »
quite curious about the ClassFactory.
I finished the integration of the new DNA version today, and all tests
are good. So on my side I will continue to work with it, waiting for
the official version.
And yes, I am very happy with that version, the new com server
features make my application very impressive !
Cheers,
Ron
>
> read more »
Reply all
Reply to author
Forward
0 new messages