This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: InstallShield Architecture Question
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2009
04:48 PM
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
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
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2009
10:57 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2009
05:05 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 22, 2009
01:27 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2009
09:10 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2009
02:36 PM
Have you looked at DTF?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2009
08:09 PM
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 26, 2009
07:38 AM
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.
DTF works perfectly together with InstallShield as usual MSI custom action. Even in the system context deferred mode.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 26, 2009
10:49 AM
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?
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?