I am an InstallShield noob and I was just experimenting with a couple of features in InstallShield.
I have a basic MSI project (InstallShield 2010). I created 3 features in my project namely -
1) 32 bit
2) 64 bit
3) Common Files
All these features deliver the files to program Files folder which is the default install folder.
Each of these features contain 2 components -
1. a .txt file
2. and a registry key.
For the both the components under 64bit feature, I have set the 64bit component option to true
In the Setup Design for 32 bit feature I have set the release flag as "X86"
and for the 64 bit feature I have set the release flag as "X64"
Now I have configured 2 releases
1. X86 release - which contains 32 bit feature + common feature
2. X64 release - which contains the 64 bit feature + common feature
Now when I execute the 64 bit MSI, all my files are delivered to ProgramFiles x86 folder, instead of ProgramFiles Folder.
However I am able to see that the 64 bit registry is created properly under the HKLM\software hive and not under WOW6432Node
I have been slogging away at different options for almost a day now without any progress :(
Ensure your 64-bit release does both of the following:
Roots files under [ProgramFiles64Folder] instead of [ProgramFilesFolder], probably through an appropriate custom action to set directories
Uses a Template Summary of x64 instead of Intel (plus the same list of language codes)
Michael you did put me on the right path.
I still used the programFiles folder as my base installation directory and I created a directory custom action just after costfinalize, which checks for the target architecture of the end machine and sets the Installdir as either Program Files x86( for 32 bit install) and Program Files x64 for 64bit install.
Thanks :)
Uses a Template Summary of x64
Set 64 bit component to yes
Related
I have a simple 32 bit app running. It uses Qt and other libraries. Having figured out manifests, I have a folder containing the app , manifests and dependent DLLs. Running this on the target machine under Windows 7 64 bit straight from a USB stick works. Copying this to a folder on the D:\ drive and it works.
Copying this to a folder under Program files (x86) and I get :
R6034. An application has made an attempt to load the C runtime library incorrectly.
I have a manifest for my executable. I also have the manifest for the msvc*.dll's in the folder as suggested elsewhere in this forum. So, why does this work everywhere except in the place it's supposed to be?
Dependency Walker will help here - run it on your .exe when it's in a working state and when it's not and compare the locations of the C runtime library your app is attempting to use (I believe it should be msvcrt.dll if you're in release, msvcrtd.dll if you're not) and you'll hopefully be able to spot a difference.
I'm not certain where you could go from there - perhaps deploy the correct version of the dll into the same folder as your .exe?
I'd like to be able to build my solution to create 32-bit and 64-bit output executables in the same build for the same project. So I would invoke "Build Solution" and end up with, for example, ProjectName32.dll and ProjectName64.dll in the output folder. Is this possible?
You can use the Batch Build option to create more than one build in one action. Just check the configurations you'd like to build and go.
Each build - Any CPU, 64 bit or 32 bit is a separate configuration so has to be built separately.
The easiest solution is to use the Batch Build option and enable all the configurations you want to build.
You can set the output file name and directory for each configuration independently so you can set them to be "ProjectName32.dll" and "ProjectName64.dll" and have them both appear in the same folder. Make sure that the intermediate file folders are different though. Otherwise you might have issues debugging.
In our environment, we have 32-bit and 64-bit machines for development. In VS 2010, when a reference to a dll is added, a refresh file is getting created which points to path of the dll. On 32 bit machines, the path used to be <drive>:\Program Files\ ....
but for 64 bit machines, it is <drive>:\Program Files <x86)\.....
The refresh files are under Source Control (subversion) so if I change the dll for a 64-bit machine, the build starts failing for 32 bit machines. Is there a way to make these refresh files change as per the system architecture?
Is there a different way to handle this? One way I am thinking is to not include the refresh files under Source Control but that would mean that anytime we upgrade our dll's, we need to change the dll's on each machine.
I leave the refresh files 'as-is' and store both architectures in a \lib directory.
MyLibrary.dll // (refresh target)
MyLibrary.dll.x86
MyLibrary.dll.x64
Whenever I need to switch architectures I execute a build script (or batch file) that simply copies & overwrites all refresh target DLLs within my \lib. For example, when switching to x64, MyLibrary.dll.x64 gets copied as (and overwrites) MyLibrary.dll.
I've got a project that depends on a particular version of MSVCR80.dll (the MS Visual C Runtime) and I'm running into problems where, depending on the particular system configuration, my app doesn't always get the right version of that file. It's been a bit of a crap shoot as to what path it takes to find a file with that name, and it's not always right...
Is there a way, when creating a Deployment Project in VS2005, to ensure that my app will always use the runtime that I provided?? When I add the runtime file to the project, it asks about creating a merge module...but not really sure what that does. And regardless of creating one, the issue remains.
Martin Richter wrote an article about that on CodeProject:
Create projects easily with private MFC, ATL and CRT assemblies
This solution does not rely on your MSI packages but on the application that uses the CRT files.
I am not sure if it is your application after installation that doesn't work, or if it is a dll you use as part of the installation that doesn't work?
To make a very long story, very short: new versions of the C / C++ runtimes are installed as Win32 assemblies, or side-by-side installation. This means the files will go into folders under C:\Windows\winsxs - the Win32 equivalent of the GAC, and several versions of the same file can co-exist here.
Applications compiled with Visual Studio 2005 / 2008 will put a manifest file into the binary, and this manifest specifies what side-by-side runtime version to bind to. It doesn't matter if you put the MSVCR80.dll next to your EXE or even in system32 - the manifest embedded in the EXE will load the file from C:\Windows\winsxs.
This is all "full circle". In the old days runtimes went to System32. This caused the original dll-hell: applications overwriting each other's global runtime files. To remedy all this the idea was to "isolate changes" to each application. Hence the new approach was to isolate a local copy of the runtime file next to the EXE. Now this caused an entirely new problem: how do you make sure security updates for the isolated dll was deployed? In most cases this never happened, and you had lots of applications running with local, unsafe dll's. So what to do? The decision was to introduce the second coming of dll-hell: the side-by-side assembly approach. In this approach runtimes are not local, but global - with the critical difference of supporting side-by-side installations. This way, in theory, applications can function without overwriting each other's runtime dlls.
So that was the quick summary of "how to make runtime deployment complicated". I am not positive it is still possible to do, but did you check whether you can statically link to the runtime? Sometimes old-school really is easier...
i'm using vs installer to build a setup package for my vb6 app.
and the problem is i can see that under the project explorer there's a list of dependencies attached to my exe file.
alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8.png
and under the file system on target machine treeview, i can actually store the dll/ocx on a folder or in the windows system folder itself[the left window].
alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1.png
so what i don't understand is .. is there actually a difference?
if i just set the dependencies and didn't add the dll or ocx to the folder or win sys folder, does the dll automatically get copied over too?
It is not guaranteed that all those dlls will be present on the system that the software is being installed on. So they need to be included in your installer. From there you have two choices.
You can install them in your windows system folders or in your application folder. The difference is that if you install them in your application folder you can set things up on XP and Vista so that the different version of the software with different version of the components can be fired up and run side by side. Installing them into the system folder will break any older version that depend on older version of the components.
Installing in the application folder rarely doesn't work if a component depends on other components that can't be updated. When this occurs it is usually with with Microsoft libraries. They have gotten better over the years on this issue.
You can read more about the issues involving side by side execution here
Finally the dependencies need to be in your installer so that they are registered in the Windows Registry. Unlike most .NET assemblies any ActiveX/COM application needs to have the component registered in order to use it even if you are using CreateObject and Variant types to access it.
I will admit the whole process is idiosyncratic and is one of the sources for the stories about DLL Hell. Start with the MSDN article, use wikipedia, and of course ask further questions here.
You should usually not have a "dlls" folder under the app folder for a normal Installer package but there are many factors involved (private standard DLLs, Reg-Free COM, etc.). Yes, the dependencies get included (unless you exclude them). They should each have a property that determines where they install on the target systems.
You also have a number of components in that list that are either not redistributable this way because they are OS-dependent system components, MDAC components, or not licensed for redist (fm20.dll for example).
Sadly this is an example of the type of package that can lead directly to DLL Hell for your users' systems. Fixing this can mean researching every MS component in MS KB articles to determine what can or should be redistributed and how.
Deployment can be a messy business to get right.