cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Daniel_Dority
Level 6

InstallShield Architecture Question

Does InstallShield 2010 execute .NET Custom Actions natively to the current operating system?

I have a DLL written in C# .NET that is compiled targeting "Any CPU" which means it runs on both 32-bit and 64-bit installations. The catch is it references a DLL stored in the GAC that could be 32-bit or 64-bit depending on the current operating system. InstallShield 2009 would blow up because it explicity runs my DLL in 32-bit mode thus it isn't able to find the DLL in the GAC on 64-bit installations. Does InstallShield 2010 fix this issue?

I see under the General Information for an IS Project the Template Summary but there is no version for "Any CPU". Just [Intel|Intel64||x64|Alpha] which doesn't neccessarily target every architecture.

Thanks
Labels (1)
0 Kudos
(8) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

No; our managed custom action host is still 32-bit only. Depending on what you need, it may be possible to build an EXE that you launch for your custom action instead. But since EXEs don't get access to the install handle, that may not be able to provide what you need.
0 Kudos
Daniel_Dority
Level 6

Darn...


That definately throws me into a road block. The code that I am writing contacts another managed code classes from a vendor and then that contacts (based on the calling host) the appropriate unmanaged code. Since it isn't picking up the correct version it fails. My only solution using IS 2009 was to launch a console application for that but I had to create a configuration file on the fly.

In order to make a the installer more intuitive, I wanted to automate more options for our customers but it seems like I cannot now because I have to be able to return a value. I may have to write my own installer using Windows Forms and the .NET framework for this one.

I definately would like to see a version of InstallShield execute the managed custom actions based on the current system's architecture. I believe that will help developers create future installations for multiple systems with just one version of the installer rather than separate 32/64 bit versions.

Thanks
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

The feature request to support 64-bit managed custom actions is being tracked under IOA-000051744. However this would not address Windows Installer's inherent limitation regarding installations to 32 and 64-bit systems from a single package; it would just make the 64-bit case better.
0 Kudos
Daniel_Dority
Level 6

That would solve the issue though. If and only if InstallShield can execute the manage code depending on how the developer writes the code.

For instance if we are able to create the following objects:
32-bit: CoCreateObjectDotNet
64-bit: CoCreateObjectDotNet64

Than this would solve the issue. If the object is dependant on the host specified in the Template Summary than it is no good.

I can use code to determine the architecture of the system and drive the flow of the installation to target either x32 or x64 bit installations. If developers are going this route than I am all for it. If not, well, then bummer.

Also you mentioned that the issue is being tracked under IOA-000051744. How do I see the progress on this? Is there an bug/feature tracking subsite here?

Thanks
0 Kudos
Christopher_Pai
Level 16

Have you looked at DTF?
0 Kudos
Daniel_Dority
Level 6

I have not.

I am in the process of building of finalizing my tasks out for this next installer and DTF is one of the items left to research.

I know you have dozens of posts related to DTF and a few blogs as well. I'll search on these forums at the start of next week but if you would like to post a few links to them that would be great 🙂

But more importantly, does DTF solve the issue stated in this thread?
0 Kudos
Server
Level 5

We already acompished a couple of installations using InstallShield together with WIX DTF. It has a compression engine and many other features built in.

DTF works perfectly together with InstallShield as usual MSI custom action. Even in the system context deferred mode.
0 Kudos
Daniel_Dority
Level 6

I see there are better examples out there today then last year.

So it does fix the issue describe in the original post?

I see that it has just custom actions with failure/success return types. Can I return values or would I have to change the flow of the program to store everything in a session variable, then allow the user to choose the value in a listbox for the next custom action to consume?
0 Kudos