Custom Action gacutil 1721 error

[mike4421]

I am using a custom action that installs and calls gacutil.exe to register a dll in the Global Assembly Cache. When I uninstall the program I get a 1721 error because of this custom action. 1) is there a better way to register the dll to the GAC? 2)is there a way to tell the installer to only run the custom action on install/repair not on uninstall. We are deploying this via group policy so I can't pass it any properties during the install/uninstall like I have read in some of these forms.

TIA you all are always helpful!

[Cary_R]

Mike,

GacUtil.exe shouldn't be necessary--Windows Installer will handle this for you in a much cleaner fashion. Simply include the file inside a component, and set the Component Destination to [GlobalAssemblyCache].

What happens next is that InstallShield does a scan of the assembly (via the default setting of '.Net Scan at Build') to populate the tables necessary for talking to Fusion.dll, and Windows Installer handles the rest. It's really pretty easy.

[Christopher_Pai]

Unless we are talking Server 2003, gacutil.exe won't even be on the machine by default. It's not a framework redist.

[mike4421]

Correct I am placing gacutil on the xp workstations with the msi package and calling it with the custom action after it gets copied to the workstation

[Christopher_Pai]

Do you understand that gacutil is part of the .NET SDK not the redist and Microsoft does not grant redist rights? Also I really don't understand why you would need to call a CA to do something that InstallShield can do natively using MSI.

[mike4421]

Thanks for your help that's why I specifically asked in my first post to this thread "is there a better way to register the dll to the GAC?" I did not know that installshield had this functionality built in. now that I know it is done. I am a sysadmin that uses adminstudio to repackage software for AD deployment. My .net/oracle programers told me that I had to get these dlls registerd using the gacutil. I have no idea where it came from.

[Christopher_Pai]

I hear you..... developers tend to think that way. That's the reason I wrote:

http://blog.deploymentengineering.com/2006/07/msi-vs-net.html

When a .NET developer walks up and says how to do something, the better question is whats the end state and why do you need it? The way .NET does thing and the way MSI does things is usually drastically different.