Comments on: Creating and deploying Managed COM add-ins with VB.NET 2005 – Part X http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/ Daily posts of Excel tips…and other stuff Thu, 09 Feb 2012 23:42:03 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: ross http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20830 ross Mon, 04 Sep 2006 23:27:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20830 <p>It's one of my things to learn (dam that's a long list), C and XLL's, I've done a little bit, but I think I should step it up a bit. I belive that 2007 has a new C API, mainly for the new grid and dual threading...I think. </p> <p>One thing that did cross my mide was if you could write XLL's with C#? I'm guessing no. Anyone got the SP?</p> It’s one of my things to learn (dam that’s a long list), C and XLL’s, I’ve done a little bit, but I think I should step it up a bit. I belive that 2007 has a new C API, mainly for the new grid and dual threading…I think.

One thing that did cross my mide was if you could write XLL’s with C#? I’m guessing no. Anyone got the SP?

]]> By: Simon Murphy http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20770 Simon Murphy Sat, 26 Aug 2006 21:48:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20770 <p>Ross<br> Yes actually. I see C/C++ as the ideal Excel partner technology for the next 4+ years. </p> <p>As far as I have seen (could be well wrong) there is more xll (C/C++) enhancement in 2007 than .net.</p> <p>cheers<br> Simon</p> Ross
Yes actually. I see C/C++ as the ideal Excel partner technology for the next 4+ years.

As far as I have seen (could be well wrong) there is more xll (C/C++) enhancement in 2007 than .net.

cheers
Simon

]]> By: ross http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20766 ross Sat, 26 Aug 2006 13:06:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20766 <p>"Then you have the long start-up time issue"</p> <p>That's a big bug bare of mine with some .net things I've done. It's embarrassing!!!! I click an icon and about a minute later my app opens? Its utter pants!!! </p> <p>I totally agree that as a dev tool VS2005 is excellent, I don't know anything about its use as a web development vs. Desktop. What would you suggest instead, back to C?</p> “Then you have the long start-up time issue”

That’s a big bug bare of mine with some .net things I’ve done. It’s embarrassing!!!! I click an icon and about a minute later my app opens? Its utter pants!!!

I totally agree that as a dev tool VS2005 is excellent, I don’t know anything about its use as a web development vs. Desktop. What would you suggest instead, back to C?

]]> By: XL-Dennis http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20732 XL-Dennis Thu, 24 Aug 2006 22:48:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20732 <p>Stephane,<br> Thanks for Your good points.</p> <p>>> So it may work well on your dev environment, but not on someone else's machine, who knows?</p> <p>This issue seems to be the most frequent issue on some forums I regular visit. Unfortunately it looks like there is a great number of a possible solution to it as well.</p> <p>I agree that the obfuscation of managed code is another important aspect to bring up but we first need to understand .NET before moving to this kind of questions.</p> <p>I downloaded yesterday Process Explorer (free utility) from Sysinternals that provide information about handles and DLLs (http://www.sysinternals.com/Utilities/ProcessExplorer.html). </p> <p>Simon,<br> Thanks for Your kind comments :) </p> <p>I think we all need to realize that .NET has to 'faces':<br> - Good for the Web<br> - Less good for the desktop</p> <p>VB 6 is strong related to VBA and therefore it's more accessible for the average Excel developer then what C++ and MFC is.</p> <p>Mike,<br> Thanks for Your kind comments :)</p> <p>If Carter & Lippert will have the kindness to skip the poor comments about VBA and the virus threat then an updated edition of their book will be of interest. But I would consider spending the money on an updated edition of Andrew Whitechapel's book instead ;)</p> <p>Kind regards,<br> Dennis</p> Stephane,
Thanks for Your good points.

>> So it may work well on your dev environment, but not on someone else’s machine, who knows?

This issue seems to be the most frequent issue on some forums I regular visit. Unfortunately it looks like there is a great number of a possible solution to it as well.

I agree that the obfuscation of managed code is another important aspect to bring up but we first need to understand .NET before moving to this kind of questions.

I downloaded yesterday Process Explorer (free utility) from Sysinternals that provide information about handles and DLLs (http://www.sysinternals.com/Utilities/ProcessExplorer.html).

Simon,
Thanks for Your kind comments :)

I think we all need to realize that .NET has to ‘faces’:
- Good for the Web
- Less good for the desktop

VB 6 is strong related to VBA and therefore it’s more accessible for the average Excel developer then what C++ and MFC is.

Mike,
Thanks for Your kind comments :)

If Carter & Lippert will have the kindness to skip the poor comments about VBA and the virus threat then an updated edition of their book will be of interest. But I would consider spending the money on an updated edition of Andrew Whitechapel’s book instead ;)

Kind regards,
Dennis

]]> By: Simon Murphy http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20731 Simon Murphy Thu, 24 Aug 2006 21:43:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20731 <p>Hi Dennis<br> Great set of articles, thanks for taking the time and effort to share them with us all.<br> Like you I like .net as a dev tool, and I use it for most server/web stuff, but also like you I struggle to justify it for desktop development.<br> I think there is a hint in the name - its not called the .desktop development environment is it?<br> Stephane also makes some good points, and I dont think Excel will ever be pure .net<br> I think what .net gives in nice development experience it takes away in deployment misery.<br> I would echo your advice about using VB6 for COM, and if you need a fully supported technology then consider C++ and MFC.<br> cheers<br> Simon</p> Hi Dennis
Great set of articles, thanks for taking the time and effort to share them with us all.
Like you I like .net as a dev tool, and I use it for most server/web stuff, but also like you I struggle to justify it for desktop development.
I think there is a hint in the name – its not called the .desktop development environment is it?
Stephane also makes some good points, and I dont think Excel will ever be pure .net
I think what .net gives in nice development experience it takes away in deployment misery.
I would echo your advice about using VB6 for COM, and if you need a fully supported technology then consider C++ and MFC.
cheers
Simon

]]> By: Stephane Rodriguez http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20730 Stephane Rodriguez Thu, 24 Aug 2006 20:39:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20730 <p>Another problem to address with the .NET interop layer is that Excel may load more than one add-ins. It's quite typical. And the version of the .NET run-time which your addin will run against will be of the first .NET add-in that gets loaded, not the one you compiled against, or bound to in the optional config file.</p> <p>So it may work well on your dev environment, but not on someone else's machine, who knows?</p> <p>Worse, it may work well on someone else's machine, and stop working overnight when the user installs another add-in, or updates his .NET run-time (servicing, ...)</p> <p>And that's describing the easy case where your add-in has no dependencies to dlls, i.e. no Dll hell.</p> <p>I don't think the situation is going to change anytime soon since there is no reason to believe Microsoft is going to rewrite to Excel in pure .NET anytime soon. If my adventure with BIFF12 proved something to me, it's that the old beast lives.</p> <p>As for using VSTO, there are plenty of versions out there already, and that makes the .NET run-time version bootstrap problem even more blatant. Question : are add-ins loaded before the VSTO run-time?</p> <p>Then you have the long startup time issue, the fusion binding issues, the partial trust environment issue (with COM interop, you're basically screwed), the assembly signing issue (500$ a year), the mandatory obfuscation (otherwise your code will be stolen), the CAS problems if you ported VB 6.0 code straight to VB.NET without furthing thinking. The list goes on and on.</p> Another problem to address with the .NET interop layer is that Excel may load more than one add-ins. It’s quite typical. And the version of the .NET run-time which your addin will run against will be of the first .NET add-in that gets loaded, not the one you compiled against, or bound to in the optional config file.

So it may work well on your dev environment, but not on someone else’s machine, who knows?

Worse, it may work well on someone else’s machine, and stop working overnight when the user installs another add-in, or updates his .NET run-time (servicing, …)

And that’s describing the easy case where your add-in has no dependencies to dlls, i.e. no Dll hell.

I don’t think the situation is going to change anytime soon since there is no reason to believe Microsoft is going to rewrite to Excel in pure .NET anytime soon. If my adventure with BIFF12 proved something to me, it’s that the old beast lives.

As for using VSTO, there are plenty of versions out there already, and that makes the .NET run-time version bootstrap problem even more blatant. Question : are add-ins loaded before the VSTO run-time?

Then you have the long startup time issue, the fusion binding issues, the partial trust environment issue (with COM interop, you’re basically screwed), the assembly signing issue (500$ a year), the mandatory obfuscation (otherwise your code will be stolen), the CAS problems if you ported VB 6.0 code straight to VB.NET without furthing thinking. The list goes on and on.

]]> By: Mike Rosenblum http://www.dailydoseofexcel.com/archives/2006/08/24/creating-and-deploying-managed-com-add-ins-with-vbnet-2005-part-x/#comment-20727 Mike Rosenblum Thu, 24 Aug 2006 18:16:00 +0000 http://www.dailydoseofexcel.com/?p=1481#comment-20727 <p>Hey Dennis, a really very nice set of articles... And thanks for the (totally unnecessary) plug! :D</p> <p>That FAQ and the sub-forum I watch over is really about MS Office Automation via .NET, which is not *that* hard, certainly not when compared to the complexity that your articles have discussed in using .NET to create a Managed COM Add-in.</p> <p>I look forward to VSTO 3.0, hopefully a 3rd book by Carter & Lippert, as well as printing and re-reading your set of articles a few times over...</p> <p>Thanks Dennis :),<br> Mike</p> Hey Dennis, a really very nice set of articles… And thanks for the (totally unnecessary) plug! :D

That FAQ and the sub-forum I watch over is really about MS Office Automation via .NET, which is not *that* hard, certainly not when compared to the complexity that your articles have discussed in using .NET to create a Managed COM Add-in.

I look forward to VSTO 3.0, hopefully a 3rd book by Carter & Lippert, as well as printing and re-reading your set of articles a few times over…

Thanks Dennis :) ,
Mike

]]>