Uninstall using the Setup project in vb 2003

Add-in Express™ Support Service
That's what is more important than anything else

Uninstall using the Setup project in vb 2003
Installer leaving files behind... 
Eugene Starostin


Guest


Hello Jeff,

BTW, our guys will contact you tommorow (Monday) and solve all your ploblems. Just give them a chance to relax a bit...
Posted 29 Oct, 2006 20:12:23 Top
Andrei Smolin


Add-in Express team


Posts: 18506
Joined: 2006-05-11
Jeff,

But, unless I am misunderstanding, it looks like I need to write a custom action dll in C++?


No, you don't. Add-in Express .NET deployment is completely based on the VS deployment. That is, you write custom actions for your setup project in order to meet your requirements. You write actions in any .NET language. I used to write custom actions in C#. VB.NET can be used as well. To add a custom action you add a new class library project to your solution and add an instance of the Installer class to the project using the Add New Item dialog.

The usual deployment scheme requires you to close the host application of your add-in before you reinstall your add-in. This causes some inconveniences for end-users of COM add-ins. That's why Sergey uses the ShadowCopy-related properties and methods of the AppDomain class in both ADX Shim and ADX Loader. When you run your ADX add-in, the host application loads the shim dll (either ADX Shim or ADX Loader) which is referenced in the registry and which does the following:

1) It finds your add-in dlls in DllCache
If there are no add-in dlls in the cache it copies all .NET dlls to the cache (including dependencies). The cache folder is located in c:\Documents and Settings\<user name>\Local Settings\Application Data\assembly\dl<number>. If all add-in dlls (including dependencies) already exist in the cache, it compares their versions. If the versions are not the same, it copies new dlls to the cache.

2) It loads the add-in dlls from the cache.

You can see how the add-in versioning influences the add-in loading.

This approach (it is built into .NET, as you see) allows you to replace add-in dlls when the add-in is loaded. The disadvantage is numerous files located in dllcache. MS doesn't provide a solution for this problem as far as I know. You may think you can remove these files in an add-inís uninstall custom action. But you remove the files from your profile only. And what about other users and their profiles?

Nevertheless, I think we could supply our shims with a mechanism for removing unnecessary files from the cache but the problem with other user profiles will remain.

Please note, the ADX Loader contained a bug that didnít permit using the add-in files replacement scheme (ADX Shim is free of this bug). Today we are releasing ADX.NET 2.8 with this bug fixed.

I wanted to throw out a few quotes...

So, sorry for the cranky nature of my previous post!


Thank you, Jeff! You've pointed us to the real problem with ADX.NET. We want it to be worth of the quotes you've mentioned. Really. At the moment, I am developing a new version of Getting Started for ADX.NET (the current one is desperately poor, I know). And your posts give me the chance to see the chapters in the documentation that I should have described better.

If you want to, I'm ready to describe here some or all aspects of both ADX Loader and ADX Shim for you. I think this could help me to clarify the documentation. :)

Other questions are welcomed, too.
Posted 30 Oct, 2006 09:53:26 Top