Comments on: Mine Field of Excel Development Tools - Part 5 http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html Welcome to the Nebula Thu, 07 Aug 2008 20:40:41 +0000 http://wordpress.org/?v=2.2.2 By: Tony Gravagno http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-108 Tony Gravagno Fri, 28 Dec 2007 20:10:00 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-108 <p>I have found that there are specific registry keys that are not set on the target box, though they are set on the source/development box. My first guess was that something in the Setup project wasn't creating the keys, but then the keys do get created in another system with VS and the .NET SDK vs the redistributable runtimes (.NET and Office PIAs). I'll post article #6 in a few days with details, and I'll check to see if manually loading the keys to the target gets it to work.</p> <p>It's also interesting that the missing keys aren't for the shim but for the function code itself - and that's confusing since this was added to the Setup as part of the Primary Output. I know the shim is executed because I can add the shim to Excel addins, and the Programmable registry key gets created from the shim.</p> <p>About Extensibility.DLL - yeah, I mentioned that in step 20 of Part 5 here, but I haven't tried adding it manually yet. There are so many "maybe I should try this" permutations and very little time to experiment with change, build, deploy, uninstall old version, install new, test, fail, go back.</p> <p>About click-once: I think with a shim a new assembly for functions can simply substitute the original, as long as there are no versioning issues. If the code is binary compatible and the GUIDs are the same, there's nothing to differentiate an old DLL from a new one. In this case the shim is managed code calling to our managed code, so all of those rules apply, including click-once. If you're not using a shim then there may be an issue with COM calling a different managed assembly (though I don't think so) and that could mandate full re-installs for users.</p> <p>HTH</p> I have found that there are specific registry keys that are not set on the target box, though they are set on the source/development box. My first guess was that something in the Setup project wasn’t creating the keys, but then the keys do get created in another system with VS and the .NET SDK vs the redistributable runtimes (.NET and Office PIAs). I’ll post article #6 in a few days with details, and I’ll check to see if manually loading the keys to the target gets it to work.

It’s also interesting that the missing keys aren’t for the shim but for the function code itself - and that’s confusing since this was added to the Setup as part of the Primary Output. I know the shim is executed because I can add the shim to Excel addins, and the Programmable registry key gets created from the shim.

About Extensibility.DLL - yeah, I mentioned that in step 20 of Part 5 here, but I haven’t tried adding it manually yet. There are so many "maybe I should try this" permutations and very little time to experiment with change, build, deploy, uninstall old version, install new, test, fail, go back.

About click-once: I think with a shim a new assembly for functions can simply substitute the original, as long as there are no versioning issues. If the code is binary compatible and the GUIDs are the same, there’s nothing to differentiate an old DLL from a new one. In this case the shim is managed code calling to our managed code, so all of those rules apply, including click-once. If you’re not using a shim then there may be an issue with COM calling a different managed assembly (though I don’t think so) and that could mandate full re-installs for users.

HTH

]]> By: ep http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-107 ep Fri, 28 Dec 2007 17:45:20 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-107 hey tony -- great posts, I only wish I had found them a bit earlier, as I've recently gone through the exact same miserable experience trying to develop automation add-ins for excel. although I haven't bothered to shim my add-ins (yet) I was able to solve my non-dev box deployment issues by adding the exensibility dll in my setup project. Have you had any luck since this post on successfully deploying? And on the topic of deployment, have you come across anything on using click once to automate updates for add-ins? Since there's no Publish tab in the project properties, I'm guessing VS isn't going to be a pal and do it for me. Any suggestions rather than making my users manually go through a wizard each time I update? thanks for all the useful stuff. hey tony — great posts, I only wish I had found them a bit earlier, as I’ve recently gone through the exact same miserable experience trying to develop automation add-ins for excel. although I haven’t bothered to shim my add-ins (yet) I was able to solve my non-dev box deployment issues by adding the exensibility dll in my setup project. Have you had any luck since this post on successfully deploying?
And on the topic of deployment, have you come across anything on using click once to automate updates for add-ins? Since there’s no Publish tab in the project properties, I’m guessing VS isn’t going to be a pal and do it for me. Any suggestions rather than making my users manually go through a wizard each time I update?
thanks for all the useful stuff.

]]> By: Tony Gravagno http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-105 Tony Gravagno Tue, 04 Dec 2007 04:27:00 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-tools5.html#comment-105 <p>Looks like I didn't post this anywhere, not sure in all of this mess.</p> <p>Andrew Whitechapel has a recent blog entry with a bug fix for the COM Shim Wizard v2.3.  I haven't had time to try it but it could be the solution to all of these problems.</p> <p><a href="http://blogs.msdn.com/" rel="nofollow">http://blogs.msdn.com/</a><br />andreww/archive/2007/11/25/com-shim-clr-loader-bug.aspx </p> <p>I'd really appreciate it if someone could tell me if this actually fixes deployment issues.  I'll check it myself in the next couple days.</p> Looks like I didn’t post this anywhere, not sure in all of this mess.

Andrew Whitechapel has a recent blog entry with a bug fix for the COM Shim Wizard v2.3.  I haven’t had time to try it but it could be the solution to all of these problems.

http://blogs.msdn.com/
andreww/archive/2007/11/25/com-shim-clr-loader-bug.aspx

I’d really appreciate it if someone could tell me if this actually fixes deployment issues.  I’ll check it myself in the next couple days.

]]>