Geeks With Blogs
Adventures of a Setup Developer my musings about setups and other things in my life

I had been off the blogging world for quite some time now. I was so swamped with work that I really could not collect my mind to write anything worthwhile. I recently bumped into a really sticky issue (and continue to remain stuck with that). We have a VSIP enabled COM DLL that uses a lot of ATL RGS code. Some of these values in this RGS file were dependent on some environment variables. Also the path to the satillite DLL and some project items were authored in the RGS file. I tried harvesting registry entries out of the RGS file but there were far too many parameters to handle. And hence, I had to do the unthinkable ---- SELF REGISTRATION --- . But despite our attempts, surprise..surprise..But that did not work either.

I then remembered that the environment variables were also a part of my package. And ofcourse, the environment variables will not be effected until the installation finishes and hence the registration failed. Developers did not have the time to fix it so we had to do a really nasty workaround. We needed to have chained setup; one to setup the environment variables and other to actually install the package. This is okay at the current stage as the package is used by our internal customers who are all developers and have predictable machine configurations. However, this will be a catastrophe on an actual production environment.

I had posted in the MS Visual Studio extensibility newsgroups about other alternatives but was informed by Bob Arson that RGS file was the only way to go. However, some of Microsoft's VSIP deployment presentations demostrated authoring these registry entries using the registry view in the Visual Studio Installer project. A little bit of googling also revealed that we could use VsipRegPkg.exe to extract these registry entries for managed plugins. But ours is an unmanaged plugin :-(. Our developers claim that they have done the right thing as per Microsoft's recommendation and that they would not require the environment variables after they acquire the PLK. But even then, there is the dependency on the satillite DLL to be present in a particular location. I wish that the other Microsoft teams run their suggestions via the deployment groups. This would greatly benifit the overall quality of the product. I guess our developers need to watch MSDN TV. They almost say "Use Managed Code" on every show.

Posted on Wednesday, March 9, 2005 7:25 PM Setup | Back to top


Comments on this post: ATL RGS Woes

# re: ATL RGS Woes
Requesting Gravatar...

Well if your already resigned to ugly self registration you could always do a DllRegister CA in the execute sequence after InstallFinalzie.

Otherwise would it be possible to set the environment up, do your COM extraction then figure out which registry entries are based on which environment variables then do a bunch of property substitution at runtime to dynamically link it all up?
Left by Christopher Painter on Mar 11, 2005 10:34 AM

# re: ATL RGS Woes
Requesting Gravatar...
That is what I would have tried but there are just too many entries. More than the environment variables, it expects satellite DLL and some project items in a relative path. That one thing is keeping me from using COM Extraction effectively.
Left by Vagmi Mudumbai on Mar 11, 2005 2:10 PM

# re: ATL RGS Woes
Requesting Gravatar...
I know this is more than 4 years later, but I will shortly release an MSI custom action that can "solve" this problem. Are you interested in helping me test it?
Left by Blair Murri on Sep 06, 2009 2:22 AM

Your comment:
 (will show your gravatar)


Copyright © Vagmi Mudumbai | Powered by: GeeksWithBlogs.net