Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Visual Studio.NET / Extensibility / February 2005

Tip: Looking for answers? Try searching our database.

Deploying an unmanaged VSIP Addin

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Vagmi Mudumbai - 22 Feb 2005 06:39 GMT
Hi All,

I am a complete newbie to VSIP and I am a setup developer. The problem is
that the addin that is currently developed (unmanaged) creates a lot of
registry entries during the self registration process. The source of this
understandably is an RGS file which uses substitution strings to put in these
values. As a setup developer, I would appreciate if these registry entries
are not created during the registration process but be done after that. Or
atleast have them extracted as a REG file so that we can import it back into
the MSI package.

We are using VSIP 2003 Beta 1. I was informed by our developers is that it
was not possible. However, I have read about the VSIPRegPkg.exe file and
would be glad if we would be able to use that. Our addin is in the very
initial stage of the testing process and since the MSI build is a part of the
daily build process, the quality team has a real tough time getting this to
work. Frankly, I would prefer a "cleaner" solution than creating the registry
keys during self registration. I am sure that this is against Microsoft's
philosophy about setups.

Thanks a ton,
Vagmi
http://geekswithblogs.net/vagmi.mudumbai
Bob Arnson [MSFT] - 22 Feb 2005 07:54 GMT
> We are using VSIP 2003 Beta 1. I was informed by our developers is that it
> was not possible. However, I have read about the VSIPRegPkg.exe file and
[quoted text clipped - 7 lines]
> keys during self registration. I am sure that this is against Microsoft's
> philosophy about setups.

It is. 8~) Unfortunately, .rgs format is specific to ATL; Windows Installer
and supporting tools don't understand it. That said, it wouldn't be
complicated to do a text conversion to a WiX <Registry> fragment.

If you're using VSIP 2005, the RegPkg tool (replacement for VSIPRegPkg) can
write .reg files (among others) that would be easy to WiX-ify. (I believe
someone on one of the WiX lists wrote that tool already.)

Signature

Bob Arnson :: Visual Studio Extensibility User Education
This posting is provided "AS IS" with no warranties, and confers no rights.

Vagmi Mudumbai - 22 Feb 2005 08:29 GMT
Hi Bob,

Good to find you around. :-)

It is very unfortunate that VSIP 2003 does not support getting this out of
the registration process. I would love to consume the RGS file and create a
REG file that I can import or WIXify it to a fragment. But the RGS file is
strewn with tons of substitution strings. I am really stuck with this one.
:-(((

Regards,
Vagmi

> > We are using VSIP 2003 Beta 1. I was informed by our developers is that it
> > was not possible. However, I have read about the VSIPRegPkg.exe file and
[quoted text clipped - 15 lines]
> write .reg files (among others) that would be easy to WiX-ify. (I believe
> someone on one of the WiX lists wrote that tool already.)
"Ed Dore [MSFT]" - 24 Feb 2005 23:43 GMT
I'd like to see this as well.

I suspect the reason why we still have self registering components is due
mostly for convenience sake. It's nice to be able to rebuild and test the
package without having to explicity install it. And the ability to register
the package against a particular test environment (aka /rootSuffix) is
pretty convenient. But when it comes to building a setup/installation
utility for the package, this does become a headache.

For managed packages though, this step is pretty trivial. Check out the
/regfile and /vrgfile options supported by the vsipregpkg.exe utility.

For what it's worth, I've sent along a feature request to the ATL team, as
I don't see how we could do this outside of ATL, as the .RGS files contain
replaceable parameters that you don't actually know how to resolve until
the component's actually installed and DllRegisterServer and/or
DllUnregisterServer is called. Maybe just keeping the replacement params in
there would suffice for our purposes though. An RGS2REG.exe utility
perhaps?

Sincerely,
Ed Dore [MSFT]

This post is 'AS IS' with no warranties, and confers no rights.
Bob Arnson [MSFT] - 26 Feb 2005 07:40 GMT
> It is very unfortunate that VSIP 2003 does not support getting this out of
> the registration process. I would love to consume the RGS file and create
> a
> REG file that I can import or WIXify it to a fragment. But the RGS file is
> strewn with tons of substitution strings. I am really stuck with this one.
> :-(((

The %strings% in the .rgs file are all either static or defined in your
vspkg.cpp file (when created by the VSPackage wizard). It's doable, just not
fun. The .rgs format is even spec'd out:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_at
l_understanding_parse_trees.asp
.
You'd have to pass in the replaceable parameters as command-line
arguments...Hmmm...

Signature

Bob Arnson :: Visual Studio Extensibility User Education
This posting is provided "AS IS" with no warranties, and confers no rights.


Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.