Installscript REGSVR32 Example???

[stiggy8]

I could use some help with two things in my project...
First:
Could someone post up an Installscript sample perfoming registration and ungregistration using REGSVR32...

Second:
After unregistering the component, I need to rename it to something like comp.dll.bak

I've scoured the forums with no success... 😞


...

I can't use a batch file for this process because I can't run the batch file untill after I install files. This would be too late as I need to do the rename action after the unreg. So it all must happen in an installscript that is run prior to move files.

And then on de-install, I need to reverse the problem.

If someone has a better idea, I would gladly love to see a sample of how...

Thanks!

[Holger_G]

Which type of project do you use?

Why don´t you just use the built in selfregister feature of Installshield instead of calling regsvr32?

-Nick

[stiggy8]

I'm building a simple MSI project. And part of the project is replacing some legacy components with versions that are named the same and versioned the same.

For some reason... the Installshield project will replace the components on install, but won't replace the legacy versions on De-Install. It might not even do that, but that's besides the point.

So my plan is to unregister the legacy files and rename them so they can be saved... then replace them on De-Install.

So unless I'm missing something... I can't use the self reg tools on something I'm not actually adding to the target machine.

Thanks for the thoughts though.

[DLee65]

I have an InstallScript setup that calls LaunchAppAndWait. Here is the basic gist of the code.

prototype RegisterComponents(BOOL);
...
function RegisterComponents( p_bRegister )
	STRING	sReg32param;
	STRING	sLaunchStr, svFileName;
begin
	/*
		Set command line parameters. 
		/s = silent
		/u = unregister server 
		
		IMPORTANT - do NOT miss the trailing space within
		the quotes. The file name to register will be appended
		and the space is needed.
	*/
	sReg32param = "/s "; 
	if FALSE == p_bRegister		
	then 
		sReg32param = "/s /u ";
	endif;
		
	sLaunchStr = WINSYSDIR ^ "regsvr32.exe";  
	LongPathToQuote (sLaunchStr, TRUE);
		
    //change directory to application directory
    //to avoid long path names.
    ChangeDirectory(TARGETDIR);  
   	
    //Register specific DLL files
    LaunchAppAndWait(sLaunchStr, sReg32param + "dmDataConnectionWrappers.dll", LAAW_OPTION_WAIT); 
    LaunchAppAndWait(sLaunchStr, sReg32param + "dmConnUtil.dll", LAAW_OPTION_WAIT);
    LaunchAppAndWait(sLaunchStr, sReg32param + "FindServ.dll", LAAW_OPTION_WAIT);
   	LaunchAppAndWait(sLaunchStr, sReg32param + "ShapeFileControl.dll", LAAW_OPTION_WAIT);
    LaunchAppAndWait(sLaunchStr, sReg32param + "ADC_Generator.dll", LAAW_OPTION_WAIT);
    LaunchAppAndWait(sLaunchStr, sReg32param + "ExchangeWiz.dll", LAAW_OPTION_WAIT);
	
	//Register OCX files ...
  	while(FindAllFiles(TARGETDIR,"*.ocx",svFileName, CONTINUE)=0) 
		LongPathToQuote ( svFileName, TRUE);
		LaunchAppAndWait(sLaunchStr, sReg32param + svFileName,WAIT);   
  	endwhile;        

end; 

Please note you will want to include error checking here. I have removed error checking for clarity.

[stiggy8]

Thanks DLee,

I'll try to implement in my project tomorrow.


By chance do you have any suggestions on performing a "RENAME" action???

B

[Christopher_Pai]

Personally I think your going about this all the wrong way. It would be better to follow the component rules and not try to deploy newere versions of COM servers that aren't backwards compatible with the ones that are already installed and then expect the installer to revert back on uninstall.

That's just not the way Windows Installer was designed at all... It violates more best practices then I care to count.

[DLee65]

I agree with Chris here. You should really conform to the component rules. In fact I do not use this code in my MSI installations at all. It was just something I had kicking around from an older Installscript installation.

For the rename action you should consider using the movefile table. This should then be able to handle changing names back on uninstall too. Remember the movefile action must be coupled with conditions on the component foreign key which indicates when a component is installed and removed.

[stiggy8]

I agree totally... However, you have to understand what our contract is telling us to do. This is a "demonstration" of a specific capability. And to enable this ability we need to modify some legacy components and then add our functionality on top of the rest. This is the design our software team came up with. So as the integrator, this is the only option that I see available.

If we win the contract... things will be totally different. But for now this is what I am stuck with.

Could you provide some more detail on the MoveFile table??? I'm not sure that this will work as I need to make sure that the components are "moved" prior to any files being added. I'll do some research but any supporting info would be appreciated.

Thanks

[DLee65]

Ahh, now I see.

So the program flow would be:

1. Unregister file.
2. Rename file.
3. Install MyFile
4. Register MyFile

OnUninstall the flow is:
1. Unregister MyFile
2. Remove MyFile
3. Rename file
4. Register file

So if you have a list of files that need to be renamed then I would start by creating an InstallScript custom action that executes before CostFinalize in the execute sequence.

In this InstallScript custom action you would call my register script passing in FALSE as the parameter. You may want to pass in a list of files to unregister as well. So this means modifying the prototype and definition a bit.

So the register function will process all the names. Use the RenameFile InstallScript function to handle the file rename and I would keep it simple like RenameFile("sFileToRename", "sFileToRename" + "bak"); I would insert this function call just after I have unregistered each specified file so you don't have to loop through all names again.

You will need to also create a Rollback custom action that will rename these files back. I would check to see if the file exists first. If the file exists with the "bak" last three characters then I would rename it back and then register it.

Hopefully this gives you enough to go on.

[Colbey]

I agree with the comments about this going against best practice. However, as that’s what you need to do don’t forget to consider what you want to happen if the install fails and rolls back.

If I was doing this I would create a custom table to hold the info about what files are to be backed up and knock together some custom actions to use that table.

Were the files that are being backed up initially installed using an msi?

[stiggy8]

Yes DLee,
That helps. I've got a manual process that works and I'm working on implementing it in install script using your suggestions. And the rollback feature is something that I would have over-looked. I'll check into adding that as well.

One last question... can you recommend a book or two that would be good for learning a bit more about IS? I'm hoping to get into one of the classes, but it probably won't happen for several months. I could use some additional insight before then.

Thanks for all of the help.

B

[Colbey]

Mmh, when I started there wasn’t much in the way of books or documentation so I cant suggest books for beginners.

Have a look at
http://www.installsite.org/pages/en/msi/books.htm

Perhaps try
http://www.amazon.com/Definitive-Guide-Windows-Installer-Experts/dp/1590592972/ref=pd_bbs_sr_1/002-1554884-8728811?ie=UTF8&s=books&qid=1189261593&sr=8-1
I've not read it, but Phil Wilson knows his stuff.

This one provides good guidelines on how you should do stuff (a must read)
http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx

The msi.chm is always very useful for understanding how Windows Installer works.

Although InstallShield is the most popular tool for creating windows installer msi’s I recommend learning about Windows installer and deployment rather than a specific tool.

[stiggy8]

Thanks Colbey

[DLee65]

Back in the day ... I cut my teeth on "Bullet Proof Installs" but I am not certain if that is still available and it was written for InstallScript 5.0! So much of it is outdated. However principles still apply if you can find it.

I usually keep several Windows Installer books on hand but the online documents are good too.