I'm in the process of adding MySQL ODBC conector as a prerequisite in Installshield. Oracle provides two separate MSI for 32bit and 64bit and they dont support cross-architecture(32-64).
I'm able to add both of these modules as two separate prerequisite with two separate custom conditions to check for the exact architecture.(win32 or win64)
when I used both of these prerequisite in a setup project I'm not able to build it for 32 bit. If I build it for 64 bit the setup will support only for 64 bit PCs.
Is there any option to add both 32bit and 64 bit prerequisites to a single setup and make it run on both platforms and let it to decide to install the suitable version of the prerequisite.
prerequisite conditions are as below
User is running a particular OS -> Custom(Platform Id=Any, Major Version=10,Minor Version1, Service Packs=-,Product Type=Any, Platform Architecture=Win32, CSDVersion="", Build No=)
User is running a particular OS -> Custom(Platform Id=Any, Major Version=10,Minor Version1, Service Packs=-,Product Type=Any, Platform Architecture=Win64, CSDVersion="", Build No=)
PS- I'm using Installshield 2015 premier edition (SP1) with VS2013
The error msg when I tried to build it or 32bit is:
error -5008: intel64 or amd64 must be specified in the template of the summary
In the General Information view, Summary Information Stream section, set the Template Summary property to x64;1033. Note: If you live in a country where English is not the language, you will use a different language code from 1033.
This will make sure your installation if 64bit. In a 64bit installer, you can add 32bit components.
Related
I need to migrate an enterprise production database from a Windows source machine running Postgres 9.5 to an Ubuntu destination machine running Postgres 11.6 with < 15 mins downtime. I plan to do this with pglogical, which requires the extension being loaded on both source and destination. I am having trouble with the source side because it is Windows.
I have very little Postgres-Windows experience and can neither find any helpful literature on the specific situation nor can I figure out for myself how to presumably install from source.
I've dug and dug and so far the only answer I've been able to find is "ugh... Windows". It seems like the only way to build from source is using Visual Studio, which I don't have or know how to use.
Sources:
https://www.2ndquadrant.com/en/blog/compiling-postgresql-extensions-visual-studio-windows/
https://postgrespro.ru/list/thread-id/1835275
Alex, the 2ndQuadrant article you link to in your own comment solves this. A few of the project or build options noted there have moved a little bit in the newer VisualStudio Community editions, so I can see where you got hung-up.
Just for kicks I compiled 32-bit DLL on my oldest Windows instance. I included the /Release path so you can grab my DLL & see if it works for you. It's (a) 32-bit because I'm assuming worst-case for an old v9.5 install, and (b) targets Postgres 9.6 because that's what I had installed. Unless there were major API changes though, it should connect to v9.5 without any issues:
https://github.com/mbijon/winpglogical/tree/master
If you find you need a version that entirely matches Postgres 9.5, grab my solution files & VS Community 20xx. Load the project & update the Additional Include Directories in Project Config to target your v9.5 paths. That should be all that's needed to link v9.5 Postgres libs.
In Advanced Installer, how can I know if a 32bit process is running within a 64bit machine? I need to know this in order to prevent final users to install our application in given scenarios. Our approach is to use custom actions to detect if a given process is running, but it seems that Advanced installer isn't able to recognizes the ".exe *32" in the string end. Does someone know how to proceed in this situation?
This is not the correct approach. To stop users from installing the application on 64 bit machines you need to go to Launch Conditions page and uncheck all the 64-bit OS-es from the list. This will make your package to stop from installing on 64-bit machines.
Of course, for clients running a 64-bit OS you need to create a new setup package, that contains the 64-bit version of your application. For this package set the package type 64-bit AMD from Install Parameters page. Also, in Launch Conditions page make sure you uncheck all the 32-bit OS-es.
If you're really using a custom action to detect a particular 32-bit process, it's nothing to do with Advanced Installer. Your code enumerates the processes to find the one you want, does an OpenProcess() to get a handle and then calls IsWoW64Process, and closes the handle. If you have an x64 MSI file it won't install on a 32-bit system anyway, so I'm assuming that you are trying to prevent your x64 MSI file from installing on a 64-bit system if a certain 32-bit process is running.
I have an ActiveX control which needs to be deployed in client machine and i am planning to do this by supplying installers to the clients .
I have made separate msi packages for 64 and 32 bit operating systems and it works properly.
However , i face a problem when it comes to 64 bit machines since i have the following requirement ,
In case of 32 bit machine install 32 bit ActiveX control.
In case of 64 bit machine install both 32 and 64 bit ActiveX control.
I read many articles stating hybrid installations cannot be done using basic msi installers ?
Can this be done using a single setup.exe file ?
A single MSI cannot both install files or registry to 64-bit locations on a 64-bit system and run on a 32-bit system. So assuming your 64-bit ActiveX control must be installed to or registered in a 64-bit location, you cannot do this in a single MSI.
If you have the premier edition of InstallShield 2012, this is one of the use cases of the Suite (or Suite/Advanced UI) project type. You must create two MSI files, and include them both in the suite with relevant eligibility conditions. (The exact conditions depend on whether you make the MSIs standalone or cumulative, but the 64-bit MSI should only be eligible if the platform has an architecture of x64.)
You can have both 32bit and 64bit components within a single installer and make it to decide what to install depending on the target platform as below.
1) Create two new features(one for 32 and one for 64) and add conditions to both of them.
for 32 bit -> Not VersionNT64
for 64 bit -> VersionNT64
2) Add both prerequisites and select appropriate (parent) feature for each one
I currently have a Java application packaged in an RPM that gets built for 32-bit RedHat platforms, and I want to create a 64-bit RPM, which is largely just the same as the 32-bit one, but with a couple different .so files included. All the Java stuff is the same on both platforms, so it's just JNI .so's.
My question is: Is it possible to have rpmbuild on a 32-bit system generate both the 32-bit and 64-bit RPMs (from different .spec files) since it's just repackaging already-built components, or do I need to build the 64-bit RPM on a 64-bit system?
N.B. I'm not actually building anything native on the system. I'm just repackaging stuff that's already built.
... or vice versa, can I build a 32-bit one on a 64-bit system? I really would prefer just to build and package this on one system than have two separate builds run for the separate RPMs.
As Aaron stated you can build an RPM for multiple distros on the same machine (64-bit), but you have to be very careful or you can run into issues. The biggest problem I've run into is you build on RHEL 5, then you try to deploy to RHEL 6, since RHEL 6 has a different version of RPM installed, it can cause conflicts and fail to install. So in this scenario you have a few options:
Build the RPM on two machines, you've stated you don't really want to do this.
If you have the disk space, configure Mock, I've used it a ton before and it's really easy to get going as long as you have the disk space and the package spec was designed to pull in requires properly.
Personally I'd give Mock a shot, it's quite simple to set up, and will allow you to do what you want with minimal effort as long as the proper repos are available. In the event the build fails the log is pretty comprehensive regarding what the RPM build error was.
I'm making installation script and I'm using ODBC, how can I automatically add a node to ODBC Data Sources.
Building installer with Visual Studio setup project, but I'm able to run any script for it.
Thank you.
1)
ODBC Data Sources are typically defined in registry entries - located at -
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI...... (DSNs on 32bit Windows or 64bit Windows)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI...... (DSNs on 64bit Windows for 32bit Drivers)
That part of the registry contains the "System" DSNs - HKEY_CURRENT_USER contains "User" DSNs.
Of course, all drivers are different so there may be additional stuff required elsewhere too...
2)
You could also consider using File DSNs and ship the fie with the installer.
3)
You could also consider a DSN'less connection - but this would depend on how the ODBC application is coded.