Chip, please forgive if you've already seen this inquiry recently.
At the bottom of your article you mention using regasm in the
deployment process. Few people (except maybe Phil Wilson) discuss
deployment at all, so it's great that you have that material. I
haven't been able to deploy to any non-development system even after
using regasm. I was able to deploy to other development systems and
everything worked fine.
See my blog link below. In article 2 of my series documenting my
effort, I link to an MSDN article on Registration-Free COM. Whether
using manual or automatic registration I still couldn't get my managed
code to execute from Excel. Given that MSDN article, do you still
recommend regasm or can everything really be handled with an Isolated
flag from VS2005?
Can you verify that you've deployed to basic end-user systems using
the info provided on your page?
A COM Shim is highly recommended by many MVPs and Microsoft people.
But you don't mention shims at all. (My blog describes shims and why
they're supposed to be helpful, for anyone interested.) Misha
Shneerson wen't so far as to say "Regasm’ing is not good enough for
addins". Any comment?
From all of the reading I've done (a lot) it seems like there are a
lot of people who can't deploy this architecture, but the answers from
all of the professionals are all the same, leading to the same sites.
I haven't seen a single confirmation that someone has been able to do
a successful rollout, given the common responses like "read Chip's
article", or Eric's, or Phil's, or Andrew's, or... Maybe everyone
winds up going back to XLL/XLA/VBA?
In short my best guess at the moment is that deployment to a system
with just the .NET Framework Redistributable is different than
deployment to a system with the .NET Framework SDK.
I reworked my code to use a COM shim and still haven't had any luck,
with or without manual regasm and even regsvr32 of the COM shim. I
have a complete tutorial on my blog which includes lots of links to
sources of information on this interesting topic:
remove.this.munge.pleaseNebula-RnD.com/
blog/tech/2007/11/excel-tools5.html
Part 5 is the tutorial but it stops short of explaining how to do a
successful end-user deployment. Parts 1-4 have good intro material I
gathered during the learning process.
I call my blog series "Mine Field of Excel Development Tools" because
there is so much beyond the basics that get published in articles and
forums. This isn't as easy as writing a little code and then using
=MyFormula(). Developers need to learn about data typing between
managed code and the basic Excel typs. they need to consider whether
they should implement IDTExtensibility2 - and if they do they'll
probably wan to override methods like Equals() and GetHashCode() which
no one discusses. They need to know if and when to implement an
Interface for COM, and what flags to set for Setup/MSI packages. And
then, leading back to the OP, is the future with XLL? VSTO? Excel UDF
Services? Some as-yet-unnamed middleware/API in development? Third
party offerings like ExcelDNA, ManagedXLL? or Add-In Express?
Ahem... this is really fun stuff, but simple it aint. :)
Thank you kindly.
Tony Gravagno
Nebula Research and Development
TG@ I.always.munge.my.domainNebula-RnD.com
"Chip Pearson" wrote:
Create a VB.NET Class Library and write your functions in that library. This
is straight NET, no VSTO required.
http://www.cpearson.com/Excel/Creati...nctionLib.aspx
Personally, I think NET will be MUCH more tightly integrated with Office
(not via VSTO/SE, which strikes me as something of a hack job to get
*something* NET-related into Office) long before we see the demise of VBA.
(Remember, XLM is/was supported 12 years after is was made "obsolete" by
VBA.) There are millions upon millions of lines of VBA out in the world. I
doubt MS would abandon all of that code. VB6 is still fully supported (as in
it works, not as in MS provides tech support or updates) 6 years after is
was made obsolete by NET.
It is just my opinion, but NET has a long way to go to make it easily
integrated with Office.