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.
My Visual Studio 2012 solution has C# projects, VB.NET projects, C++/CLI projects and C++ projects. Currently, I have three platforms: x86, x64 and Win32. When I added x64, I noticed it was used by all projects. I'd like to do the same with x86, so that I can remove Win32.
So I went to Configuration Manager, selected a C++ project and in the platform combo box I only had the options: Win32, x64, New and Edit. If I selected New, the only option available is ARM.
So then I thought of just replacing Win32 with x86 in my .vcxproj. Didn't work (it defaulted to x64). Then I looked at the .sln file, but couldn't see how x64 manages to work for every project.
The IDEs differ too much to get a common platform name for 32-bit code. Otherwise reflective of managed code being rather fundamentally different from C++ code. Managed project platform names can only be AnyCPU, x86, x64. C++ project platform names can only be Win32, x64 and ARM. History plays a role, Win32 comes from the early 1990s, back when Windows NT introduced the 32-bit version of the winapi. Distinguished from the 16-bit version. There was no real opportunity to ever change it again without risking breaking existing projects.
The x86 platform name for managed projects isn't exactly standard either, that was a mistake in VS2010 that you appear to have inherited. VS2012 creates new projects with the AnyCPU platform name like old VS versions used to do. Which pretty accurately describes the true platform for managed code, it runs on any thanks to the jitter. The name is otherwise irrelevant, only the Project + Properties, Build tab settings matter to force a specific jitter to be used at runtime. In other words, if you don't force x86 there then your program is still going to run as a 64-bit process, even though the platform name is x86. That was the VS2010 mistake, it caused a lot of misery.
So you're pretty stuck with this. It is not a real problem, the IDE can handle the mix just fine. You already know about the Build + Configuration Manager dialog, it unambiguously shows which platforms are going to be built when you use Build + Build or press F5.
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'm deploying 64bit dlls, exes by setting each component's 64bit component = yes and setting "General Information->Summary INformation Stream->Template Summary = x64;1033". All things are ok, but the produced setup.exe when i run it, from task manager i notice its a 32 bit exe. How to make it a 64bit exe?
Why I wanna do it: In custom action i called some methods of managed dll(64bit) and wrote some registries to Software/MyApp, the matter is setup.exe(32bit) loads the dll which eventually writes to Software/Wow6432Node/MyApp. Yes I can replace the dlls with 64bit exes but can't we make the setup.exe a 64bit one?
The "bit-ness" (e.g. 32-bit or 64-bit) of an exe is determined at compile time. If you have the source code for setup.exe you could recompile, targeting it to a 64-bit platform. Other than recompiling, there really isn't a way to make it 64-bit.
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.