Recently i upgraded my visual studio 2008 installer project to InstallShield Limited Edition project into Visual Studio 2013. I was able to build the solution from visual studio and from my Nant build script. My solution build platform is x86/Release and my installshield limited edition project build platform is singleimage without specifying any platform. My computer is Win32 and i installed installshield limited edition for 32 bit.
Now i added one merge module in the InstallShield Limited Edition project which can be run in both Win32 and Win64. The signature of the merge module specifies that it can be executed in both Win32 and Win64.
But as long as i added the merge module and built the solution, i got the following error
ISEXP : error : -5008: This 32-bit package cannot include 64-bit data. The 64-bit data may come from a merge module.
My merge module is developed by other party and they said it should be worked in both Win32 and Win64.
When working with Windows Installer, you have to choose between making a 32-bit or a 64-bit package. The 32-bit package can install on a 64-bit system but can only access 32-bit locations; the 64-bit package cannot install on a 32-bit system, but can access 64-bit locations on a 64-bit system.
The error you quote is to avoid letting a merge module change your whole package from 32-bit to 64-bit, as that can cause you compatibility problems that are difficult to diagnose. If you want to use that merge module as is, you must do something in your project to indicate you want a 64-bit package, such as adding a file or registry key that installs to a 64-bit location. Alternately, if you need to support 32-bit systems, you should request the other party properly separate their 32-bit and 64-bit merge modules.
Related
let's say that DLL A as the CRT 8.0.50727.762 as dependency. This DLL is used in a exe project that is linked dynamically (/MD) with "Use Of MFC" = "Use Standard Windows Libraries".
Both the DLL and the project using the DLL are using VS 2005, yet the project building machine has a newer CRT. So the exe itself has a dependency to 8.0.50727.6195 in its manifest.
Now I have two question:
Is my understanding correct that the CRT versions are backwards compatible?
So when I deploy the project and add the CRT assemblies version 8.0.50727.6195 to the exe's working directory it should work on any client no matter what is in his WinSXS cache right?
No. CRT or MFC is not backward compatible. You must install appropriate Visual C++ Runtime on client's machine, ensuring that:
The version should match (VC7, VC8,.. VC14 etc.)
The bit-ness should match. If your application is 32-bit, you need 32-bit redistributable, and same for x64.
The service pack version must also match!
It should be noted that all of them can co-exist! VC10 RTM, VC10 SP2, VC10 x64 RTM.. all can co-exist.
We have a VC++ 2012 application for native Windows (classic fat app)
Also we have a NSIS based installer.
I would like to add the VC110_CRT merge modules to the installer but the merge modules cannot be installed on Windows XP. The error Message is.
This installation package cannot be installed by the Windows Installer service. Your must install a Windows service pack that conatains a newer version of the Windows Installer service.
and yes, Its a fully updated Windows XP (SP 3 + all updates). As far as I understand it, we need at least Windows Vista to install the update.
My Question:
Is there a way to convert the Microsoft_VC110_CRT_x86.msm module, so its usable under Windows xp
I know I can use the vs_2012_redist, but it has ~6,5 MB instead of ~0,8 of the merge modul size.
and I only need the CRT, because the app uses QT and no MFC/ATL/....
This is an incorrect error message. MSIEXEC is looking at the schema verson in the SummaryInformationStream of the MSM and seeing it's newer then the version of MSI on Windows and giving you this error message.
In truth, merge modules can never be installed because they have no concept of Product or Features. They are merely encapsulated collections of components and related installation metadata. Merge modules are like .LIB files in C/C++ and are statically linked (merged) into an MSI at build time.
NSIS isn't a Windows Installer technology so it can't use merge modules. Instead you should use the redistributable provided by Microsoft and launch the EXE with the correct command line.
You're only other options are to deploy the desired DLL privately (in your application directory), statically link it in your EXE or dump NSIS and create a proper MSI.
Be aware of the security / patching implications of your choice.
I built a C++ based COM object using Visual Studio 2012. It registers and works fine on 64-bit machines (called by 32-bit code and calling a 32-bit out-of-process COM server) but does not register on 32-bit machines (neither XP nor Win7 32-bit). The message from regsvr32 is
LoadLibrary("comobj.dll") failed - The specified procedure could not be found.
The project was originally built with Visual Studio 6 (7 years ago). It uses ATL macros such as BEGIN_COM_MAP and BEGIN_SINK_MAP to declare its implementation of various interfaces. It had to be re-compiled because the COM server it was invoking changed (new ProgID, new GUID, new type library, etc). Other than making those adjustments, and using current VS, there were no (intentional) changes -- there certainly was nothing in the old equivalent of the project file that would have pointed to 64-bitness.
Examining the DLL with the 64-bit version of DEPENDS.EXE shows "64" icons next to the standard referenced DLLs like KERNEL32 and USER32. Other than having built the DLL on a 64-bit machine, there is nothing "64-bit" about the DLL that I can find. The target is explicitly Win32 (not X64).
Examining the DLL with the 32-bit version of DEPENDS.EXE (on Windows XP running under Virtual PC) shows KERNEL32.DLL with a red icon, apparently because there are references to FlsAlloc FlsFree FlsGetValue FlsSetValue that do not exist in the 32-bit KERNEL32.DLL. (I have no idea what those are and don't know where those references come from -- perhaps from the copy of MFC on the 64-bit machine where the compile was done?)
Could it be that I have to install VS2012 on XP and re-compile there? How could that really be what needs to be done to build a Win32 COM object in C++ using current Visual Studio?
Does anyone know where I might look? I've checked all the project and solution options and nothing seems set to 64-bit. The option under "Use of MFC" is set to "Use Standard Windows Libraries" -- that's probably the answer but if that's not portable to 32-bit Windows it's hardly using only "standard libraries". (I will be trying changes to that after sending this.)
Thanks in advance for any advice.
Default toolset coming with Visual Studio 2012 produces output incompatible with Windows XP, through using certain APIs introduced only later with Vista.
In order to both utilize the power and feature richness of the latest Microsoft C++ compiler, and be still compatible with Windows XP, you need to use an alternate toolset codename "v110_xp" introduced with Visual Studio 2012 Update 1. At the moment the latest update available is Visual Studio Update 3, and you might want to simply install latest available updates for Visual Studio.
You have the setting available under Project Settings:
See more here: Configuring C++ 11 Programs for Windows XP.
Is the package type (x86 or x64) dependent on my application type or on the OS type it is installed on?
I.e., if I develop a 32-bit application do I need to
deploy the x86 package only or
deploy both packages and install x86 on 32-bit windows and x64 on 64-bit windows?
The answer to this question 32-bit VC++ redistributable on 64 bit OS? suggests that it's only the x86 package, so it would be dependent on my application but it doesn't give any explanation/links.
The MS download sites are also not specific on this.
When you compile, all use of the standard library creates references that must be resolved at link time. The linker bakes in the import library for the matching runtime DLL(s), which must be matched completely at load time. That means matching the compiler version, service pack, and bitness.
Also remember that a 32-bit process cannot load 64-bit DLLs. Because the 64-bit redist only contains 64-bit DLLs, it is of no help when loading a 32-bit executable.
it depends on the application if you need to maximize the potential of 64-bit OS, you may deploy both for handling 64-bit and 32-bit processing. However, if your application did not exceed the limits of 32-bit, you may deploy the application on x86 only, anyway it should also work on 64-bit OS via 32-bit virtualization.
I need to create a setup which targets 64 bit O.S.,Currently my project is Installshield 2008 Premier Edition and type is InstallScript MSI and we right now we are supporting 32-bit O.S.
I have some set of questions
Do i need to build Installshield on 64-bit dedicated machine ??
Is it possible to have same project which supports 32-bit as well as 64-bit? If Yes how to approach?
Is single Setup.exe will support both 32-bit and 64-bit ??
Thanks
No, you can build in either environment, unless you need to do things like 64-bit COM Extraction which must run on a 64-bit platform. However 32-bit packages should be fine building from either environment.
It's possible to create a project with multiple product configurations that each target different platforms (different template summaries, possibly different release flags). I'm not sure I'd want to try to do that with an InstallScript MSI project type.
InstallShield does not yet create a single installer that really supports both platforms. You can hack it together in an InstallScript project, for the most part, but Windows Installer requires different packages for different platforms, and setup.exe only supports one.