I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.
Related
I have applications using 'mswinsck.ocx' file for windows messages.
My 'mswinsck.ocx' file is registered from 'C:\Windows\SysWOW64' folder.
All 32bit applications are working fine with this ocx file.
Now I am migrating my Delphi applications from 32bit to 64bit.
Should I require 64bit ocx file to run 64 bit exes?
I downloaded one and tried to register from system32 folder but got following error message:
I do not have code files of ocx file.
If you wish to continue using this library you will need a 64 bit version of it. If you cannot obtain a 64 bit version of the OCX there is little you can do. You may be compelled to replace this component.
I just got my first 64-bit Windows notebook. Now I'm looking for information when and why to use the 32 or the 64-bit versions of PowerShell or ISE.
My first impression is that I better stay with 32 bit, until I understand things better.
What I miss or didn't find are basic tutorials and practical experiences and links to this questions.
I'am working on a Seven 64Bits and W2K8 R2 for one year now, and, on the command line, I'am always using 64 bits Powershell without any troubles.
For me the problem is not to choose 32 or 64 Bit PowerShell.exe, but to know that the two exists, and that a 32 bits process will use the 32 bits PowerShell. For example if you use PowerShell as post build execution script in Visual Studio 2010, it will use 32 bits PoweShell because Visual Studio 2010 is 32 bits process.
The two versions see two differents places in the registry so you have to Set-ExecutionPolicy for both.
As scripting is concerned I do not use ISE, but PowerGUI script Editor. You can use
[intPtr]::size
in a script to know if you are runing 32 or 64 bits PowerShell.exe.
You would use the 64 bit versions of PowerShell or PowerShell ISE where the problem you are trying to solve is uniquely 64 bit. For example:
You need your PowerShell script to be able to consume more memory than a 32 bit application will allow
You are consuming libraries that are 64 bit only or need to run in a 64 bit environment. For example on Windows 2008R2/IIS7.5 if you are using the Microsoft.Web.Management managed wrapper, if you need to modify administration.config via this library then your application or script needs to run in a 64 bit process.
I typically stick with 64-bit PowerShell unless I have a good reason to not use it. One issue with 32-bit PowerShell is that you may accidentally find yourself in HKLM:\SOFTWARE\Wow6432Node location of the registry instead of where you think you are.
The example I've most-often come across for an explicit need for 32-bit is when using certain COM objects. For example, if you have a 64-bit OS, but 32-bit Office... If you want to instantiate a Word, Excel, or Access object, you're going to need to be in 32-bit PowerShell or else it's going to act as if you don't have Office installed at all.
When running SharePoint 2013, it's important to run the 64-bit versions when attempting to user the Windows.SharePoint.PowerShell snapin. I spent too much time not realizing I had open the 32-bit ISE not being able to load SharePoint Commands.
I think you don't really need to take care about that. As for my 64bit system, there is only a 32bit PowerShell preinstalled (in \system32) and it works without any issues. So just use it ;) And well, besides that, it's most likely the same case as with any other application: if you rely on functions/properties that are only available under 64bit you are better of to use the 64bit version of that application.
I have to make an installer for motionbuilder 2011 for 32 bit and 64 bit.
The installer should detect and deploy the corresponding plug-ins.
One of the 64 bit machines has both versions installed on it but the registry shows only one of them at a time.
Is there any way to detect both the installed versions and deploy the corresponding plug-ins in their install directories?
Thanks
you have to query HKEY_LOCAL_MACHINE64 to get MoBu 64-bit path. For example, using Inno Setup script:
32-bit path
RegQueryStringValue(HKEY_LOCAL_MACHINE, Software\Autodesk\MotionBuilder\2011, 'InstallPath', path)
64-bit path
RegQueryStringValue(HKLM64, Software\Autodesk\MotionBuilder\2011, 'InstallPath', path)
Hope that helps!
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.
When downloading the tar file from AdaCore for the GNAT compiler (the libre version), I noticed that there are two exe files for installation purposes:
win32ada-gpl-2010.exe of size 2.67 MB
and
gnat-gpl-2010-i686-pc-mingw32-bin.exe of size 70.2 MB
In the folder containing the second one, there are instructions for the installation and it installs the GPS editor as well.
I have Win XP and chose to install the second exe file. Now I'm thinking that the second one is for a MINGW installation whereas the first exe file is for a native Windows installation. But I can't find information for this. Which of the two exe files is for a normal Windows installation?
Thanks a lot...
Win32Ada I believe is just a set of Win32 bindings for Ada. That's why it is so much smaller.
You might download that if you want to do a lot of Win32 systems programming or GUI work, and don't have a set of higher-level bindings (eg: GTKAda)