I mean doing this in a InstallScript project so the installer would exit in the first place if it's not running with correct processor type.
I found it'll be easy if it's a InstallScript MSI project, just modify the "Template summary" field, while this options is not there in InstallScript project.
I have some requirements which could be met perfectly by InstallScript project type so I cannot git it up.
Thank U in advance for your advices.
In InstallScript you often have to roll your own behavior. In this case, it's easy: just check the SYSINFO struct for the parameters you require, and provide appropriate messaging and abort (or continue). In this case it's probably SYSINFO.bIsWow64.
Related
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
We are migrating our applications from 32 bit to 64 bit. And also .net framework 3.5 to 4.0.+Visual Studio 2008 to Visual Studio 2010
Aspart of migration we created all msi's in 64 bit with visul studio 2010. we had a problem while installing them.
we are getting System.BadImage error for the msi's which are having some customaction condigured in depolyment project. Due to this error installation rolled backed.
Root Casue Identified:
For doing customaction we have projects with installer classes While installing those using msi we caught that error.
When ever we get that error.We just tried installing that .exe manually using 64 bit visual studio commandLine with installUtil.exe command. it successfully installed.
But when we are using 32 bit visual studio commandLine with installUtil.exe, we end up with the same error.
So problem is when ever we are using msi its picking the 32 bit installUtil.exe eventough the msi is 64 bit which is causing the problem.
Tried Solutions:
1.Tried debugging the installer class using Debugger.Launch(). But before hitting the point we end up with error.
2.Try to edit the Database table of msi with orca editor to pick the correct version of installUtil.exe. But failed with other error.
Question:
1.How can we modify our solutions to pick the 64 bit installUtil.exe?(if we can do this)
Rule #1: Don't reinvent the wheel. Avoid CA's wherever possible.(See PhilDW's answer)
Rule #2: When you really must use a managed custom action don't use InstallUtil. Use Windows Installer XML (WiX) Deployment Tools Foundation (DTF) instead.
Rule #3: Write custom actions that follow MSI's transactional model (Install, Rollback, Commit) whenever possible.
Rule #4: Write data driven, declarative (custom tables) custom actions whenever possible.
Rule #5: Honor the security model of MSI ( custom actions that change data must be deferred in the system context )
Rule #6: Test the !#Q%Q! out of your CA's. Make sure that install, uninstall, reinstall, cancel (rollback ) and upgrade (and upgrade rollback), repair and silent installs all work as expected. Hint: Rule #1 exists because you get this for free when you don't write custom actions.
Reference:
Deployment Tools Foundation (DTF) Managed Custom Actions
This might be the issue:
http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
You don't need installer classes. Visual Studio setups to generate MSI files are not in newer versions of VS, so you should use a tool that uses the standard methods of installing services, ServiceInstall and ServiceControl being the underlying tables in the MSI file.
i have implemented successfully custom actions in my visual studio setup project to encrypt app.config file and also to capture user input through textboxes. However my project has 3rd party dll references which I want to merge. I have done merging using redgate smart assembly and after that when I build the setup project using the merged obfuscated assembly there is an error during installation( unable to get installer type for assembly error 1001).
Can you show me how to encrypt app.config and capture user input via custom dialog using Installshield
InstallerClass Custom Actions ( InstallUtil ) are very fragile and should never be used. The problem you are having is most likely that your custom action assembly has a reference to an assembly that can no longer be found on the disk since it's been merged into another assembly.
This problem would happen with InstallUtil CA's whether it's being called by a Visual Studio Setup Project or an InstallShield Basic MSI project because the problem isn't in MSI, it's in your CA.
I would reccomend you look at WiX Deployment Tools Framework (DTF). It's a far cleaner way of implementing managed code custom actions so that the CA and all of it's dependencies appears as a single native DLL to the Windows Installer. At runtime the native stub extracts all the files, runs your .NET code and marshals all of the MSI API calls between the two sides for you.
It's very clean and it can be used in Setup Projects, WiX, InstallShield and other MSI authoring tools because the output is a simple Win32 DLL with exported stdcall functions. ( Msi Type 1 Custom Action Spec )
I am at my wit's end with this and our CM just, ahem... left the company.
I have a 32-bit InstallScript based InstallShield installer that I have copied and modified to install the 64-version of our software. It properly grabs everything from the correct (x64) location and everything is good.
The only problem is figuring out what I need to change in order for the OS to recognize that this installer is installing 64-bit components and that they need to be placed into the Program Files folder (as opposed to Program Files (x86).
I have found plenty of information regarding how to do this when you have an MSI based project. Unfortunately, all of the options that are referenced in the documentation do not exist in an InstallScript based project.
As setup.exe is a 32-bit executable I am assuming that it is querying the Program Files dir and getting back the 32-bit version. I simply have no idea how to build it as an x64 exe or otherwise how to workaround this fact.
I can't find anything in the documentation that explains how to accomplish this task. I am using InstallShield 2011, thanks in advance for any help you can offer.
Yeesh, the answer was simple enough. Changed
TARGETDIR = PROGRAMFILES ^ "Target\\Dir";
To:
TARGETDIR = PROGRAMFILES64 ^ "Target\\Dir";
Seems to work fine for uninstall as well.
I'm working on a deployment project (Wix based) which is used to deploy an application to run with AutoCAD and create shortcuts of AutoCAD's acad.exe while passing its own argument.
To achieve this, there is a Custom Action dll (C++) which iterate through Autocad's registry keys and get the "acad.exe" location and create/update the shortcut using MSI Api methods in MyInstaller.msi at run time.
Problem:
On x64 bit OS like Windows 7, Custom Action is reading the proper 'acad.exe' location from registry i.e. C:\Program Files\AutoCAD 2010\acad.exe, and update the shortcut properties in msi at runtime. But when msi finishes creating shortcut, the path is converted to 32bit program files i.e. C:\Program Files (x86)\AutoCAD 2010\acad.exe, which actually doesn't exists.
My Work Around:
As my msi is 32bit (x86), so I created a separate Component with attribute Win64=Yes, and modified Custom Action to update/create shortcuts for this component. But still target path in shortcuts are being converted to C:\Program Files (x86).
I know if I convert my MSI for x64 OS, this might be solved, but at the present, I can't do such a big change.
Is there any way that a 32bit msi can create shortcuts containing paths of x64 OS?
Any help would be really be appreciated..
Thanks a lot.
You are swimming upstream against MSI on this one. (Although I can understand why. )
Officially MSI is never platform nuetral. I assume you are using a custom action to read the registry values because MSI's AppSearch/Reglocator will constrain you to the WoWSys64 node. After that, MSI will substitute even hard coded references to program files as part of an application compatibility approach ( basically microsoft assumes you didn't know what you were doing and that they know what you really meant to do ).
Unofficially- read this thread to find a hack that I figured out to work around this. The summary is I found that if you convert C:\Program Files\ to a short path ( C:\Progra~1 ) that MSI is no smart enough to figure out what you are referring to so it doesn't substitute the value.
http://www.joyofsetup.com/2010/03/27/wix-msbuild-v2-0-and-x64-systems/
Note, this a hack and there is no way of telling if Microsoft will 'fix it' in future releases. The only other approach I can think of is you to then not use the shortcut table and instead write custom actions to create the shortcuts for you.
If you don't want to swim against MSI, consider this workaround. Create a small 64bit EXE ( yes, you can deploy a 64bit or AnyCPU exe to Program Files x86 is a x86 MSI ) that acts as a front end launcher to AutoCAD. Make it query the registry table and find the file then launch it or display a message saying AutoCAD is unavailable if it can't be found.
If you do this you make your install far cleaner.
Ok I was able to solve it:
Problem was, 32bit MSI on 64bit OS, was converting paths (in shortcut table) to 32bit equivalent paths i.e. Our Custom Action dll was getting AutoCAD's path from 64bit registry key as C:\Program Files\AutoCAD 2010\ and then injecting this path to MSI's shortcut table and Directory table. But when MSI was writing the shortcut, it was converting it to C:\Program Files (x86)\AutoCAD 2010.
We can't have 64bit Components in 32bit MSI, but Vice Versa is possible i.e. We can have 32bit Components in 64bit MSI.
However, in my case, I have to use 64bit Components for shortcuts and other components would remain 32bit.
So I have converted my 32bit MSI to 64bit MSI adding Plantform=x64 in Package information. And declare the component as Win64=Yes.
And this solved my problem and now I'm getting proper paths in shortcuts.
Due to this, now I have 2 separate installer i.e. for each 32bit and 64bit respectively.
Best regards
Farrukh