I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I'm expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I'm stuck with using Visual Studio's deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
it is marked as a x64 installer
it writes the entries under HKLM/Software/Blablah for the benefit of 64-bit processes
it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablah for the benefit of 32-bit processes on the same machine.
I'm guessing that because I've marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.
The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it's much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You've got to produce the 32 bit package anyway for 32 bit machines, so it's no extra work.
Related
I have created a WPF Windows Application project based on the existing standards in the solution. The project properties had Platform Target as Any CPU and says Prefer 32-bit. Mine is a 64-bit machine and the application wasn't launching, it took me while to figure out and turned off Prefer 32-bit to launch it.
My question is what is happening when I say Prefer 32-bit? I expect it to launch it as a 32 bit application on a 64-bit machine. But in my case it does not run, it simply terminates. Why?
Edit:
The problem was when I say Prefer 32-bit or x86 it builds the application in 32-bit mode. Any CPU makes it a 64-bit build. The application launches only in 64-bit mode and when launched with 32-bit mode it terminates without any exception.
After trial and error found out that problem is with the length of the AssemblyName. It was 56 character long after I reduced it to say 36 character it worked fine. Could not get information on whats the permissible limit for 32-bit assembly name and 64-bit assembly name. But 64 bit allows bigger names which has caused the confusion.
I am trying to run this project in my VisualStudio 2010.
it build and run fine on my 64 bit Machine.
NOTE:I have to change build Platform of my project to x86.
my problem is when I try to run compiled assembly (after moving Debug Folder to another 64 Bit machine) I couldn't run my project. my exe breaks down when I open it.
as per my understanding problem is because of three DLL used in project are 32 BIT and Machine is 64Bit.
NOTE: below is three DLL
Interop.Office.dll
Interop.VBIDE.dll
Interop.Word.dll
I googled much but couldn't found any solution?
one solution comes in my mind is manage to get 64BIT version of above DLL for that also I have googled much but couldn't get anything.
could you please help me to find solution for this problem? or is there any way to found 64BIT version of above DLL?
If you have to use 32 bit dlls, probably you cannot run your application, compiled on 64 bits.
So you need to compile all your project (as you did for debug) in the 32 bits mode before release to another pc.
You can ensure your dlls compiled right (32 bits only), using Microsoft CorFlags.exe utility.
If you'll find that dll is not 32bits, you can also try to change it with same utility (/32BITS falg).
More information:
The default version of Office is 32 bit version.
To get 64 bit versions of the assemblies you need to specifically install 64 bit office (see here.)
The 64 bit version of Office should be able to use your 32 bit program (using WoW)
but it's best if you create (and test) two versions of it: one for 32 bit and one for 64 bit.
Unfortunately this means two development environments as the 32 bit Office cannot be installed along side the 64 bit one.
Are you positive that the office interOps are the problem?
What is the error message you are receiving? You have stated that you are compiling with x86 platform build mode. Therefore your dlls will run as 32 bit processes even on the other 64bit machine and will therefore call the 32bit office dlls.
If you had of compiled as AnyCPU then I could see how the error you are getting relates to office dll bitness, because your application would start in 64bit (on a 64bit machine) and then attempt to call into the 32bit office dlls.
But I fail to understand how you're finding that the 32bit dlls are the problem on any 32 or 64bit machine since you are compiling to 32bit (x86). So your assembly manifest is telling the JIT compiler, "hey Im a 32bit process".
Remember, ngen aside, the bitness of your code isn't determined till it's run. Post compilation the code is just IL waiting to be compiled and it's the same IL regardless of whether you had a build platform of x86 or x64 or AnyCPU.
When it's run the runtime looks at the manifest and compiles it to the platform of choice... which in this case is x86... from what you have said.
So the problem is not that:
three DLL used in project are 32 BIT and Machine is 64Bit.
32bit dlls are used all over the place on 64bit machines. Visual Studio itself is a 32bit application and runs just fine on 64bit machine. The problem (IMHO) is either
Not the office dlls at all but something else... Office is installed on the other machine I assume.
You've accidentally changed the target platform of the last build you did before deploying to something other than x86.
Since I can't find anything clearly stating it on the MSDN documentation: what does the ProgramFilesX86 enum value return on 32-bit systems?
Development Environment
Please note: in my organization I can't just stand up machines whenever I want to test things. This is why I'm asking the community. I don't even have access to 32-bit ISO's to build a virtual machine -- so please understand I have some limitations inside this organization.
Windows 7 64-bit
Production Environment
In production I don't know if they are running 32 or 64-bit systems, and it's likely a mixture. However I do know the list of operating systems.
Windows 7
Windows Vista
Windows XP
Objective
Get the correct program files directory so I can launch my application dynamically.
Known Variables
The application is installed with an MSI, and it will be installed with the default options, so it will be installed in the Program Files directory.
The application is a 32-bit application, so on 64-bit systems it will use the Program Files (x86) folder, but on 32-bit systems it will use the standard Program Files directory.
Thanks all!
32-bit XP: an empty string :(
32-bit Vista: "C:\Program Files"
32-bit Win7: not tested, probably same as Vista
64-bit Win7: "C:\Program Files (x86)"
Not sure about 64-bit XP, I am curious myself.
The Remarks section for KNOWNFOLDERID contains a handy table giving you the information you seek (from an unmanaged perspective). It's tricky to reproduce it here:
OS App KNOWNFOLDERID Default CSIDL
32 bit 32 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files CSIDL_PROGRAM_FILESX86
64 bit 64 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files (x86) CSIDL_PROGRAM_FILESX86
64 bit 32 bit FOLDERID_ProgramFilesX86 %SystemDrive%\Program Files (x86) CSIDL_PROGRAM_FILESX86
It returns "Program Files". Since you're installing using an MSI, you might consider using the installer APIs (MsiLocateComponent, and so on) to locate your program instead of assuming it's in the expected location.
On my Win 7 32-bit system ProgramFilesX86 returns C:\Program Files (no trailing slash).
Console.WriteLine("GetFolderPath: {0}", Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86));
I am running 64-bit Windows, and I want to create the registry key HKCU\Software\Classes\Wow6432Node\CLSID\{myguid}\InprocServer32 using C#.
What registry key should I tell it to write, so that it will be redirected to the above key? This should also work on 32-bit Windows.
I am compiling my app to target x86.
If you are using .net 4 you should make use of the RegistryView enumeration.
Pass RegistryView.Registry32 when you call OpenBaseKey. Use HKCU\Software\Classes\CLSID{myguid}\InprocServer32 as your key and let the redirector do the work.
If you are using an older version of .net then I am afraid you will need to p/invoke the native Win32 API.
If you happen to be targetting x86 then you don't need to do anything. The registry redirector will do the right thing and redirect your registry access to the 32 bit view of the registry. You only need to take the steps outline above from a 64 bit process.
64-bit versions of Windows emulate 32-bit functionality through the "Windows on Windows" (WoW) subsystem.
In the case of the registry, they move the 32-bit keys over to a special subkey for compatibility reasons. It will automatically redirect 32-bit registry operations to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. More details can be found on the MSDN topic about the Registry Redirector.
You can use the RegistryView enum on RegistryKey.OpenBaseKey to open the 32-bit view explicitly and access HKCU\Software\Classes\CLSID{myguid}\InprocServer32 directly. This will automatically access the WOW64 node on 64-bit systems and the normal key on 32-bit systems.
Since you are targetting x86, simply using HKCU\Software\Classes\CLSID\{myguid}\InprocServer32 will work on all platforms.
By default your C# application is compiled using "Any CPU" (this is the default -- it means that your program will run as a x86 exe on x86 machine, and x64 on x64 machines). What you want to do is change the setting to Win32.
Now your program will always run as an x86 exe, so it will be automatically redirected by windows the WOW6432Node. When you access the HKCU\Software\Classes\CLSID{myguid}\InprocServer32 on an x64 machine you will be redirected to the desired key.
I'm updating my operating system to Windows 7 x64, I only have experience with running 32-bit operating systems. Does anyone have any bad/good experiences with a 64 bit environment?
For reference, the tools I use are:
Visual Studio 2008
Tortoise SVN
TestDriven.Net
Oracle 10g XE
PL/SQL Developer
Dundas Chart
Analysis Services from MS SQL Server 2008
Running on a 64-bit operating system has a number of side effects that will be noticeable to some extent. The most common issues:
Edit and Continue in Visual Studio won't work. You can fix this by forcing your .NET app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86. Resolved in VS2013.
If you use any ActiveX controls or COM components in your .NET app you may find your program no longer works since your machine doesn't have a corresponding 64-bit version of the COM server. You'll get error 0x80040154, REGDB_E_CLASSNOTREG, "Class not registered". Same fix as above.
The 64-bit debugger doesn't support mixed-mode debugging, you'll have to commit to either Managed only or Native only debugging. Same fix as above, as long as you don't have 64-bit specific issues. Resolved in VS2010.
Poorly written P/Invoke declarations that declare an uint or int where an IntPtr is required will stop working in 64-bit mode. You'll generally get an AccessViolation exception or a failure return code. Or a PInvokeStackImbalance MDA warning. You should not have any trouble locating the mistake, just fix the declaration.
Several legacy end-of-life Microsoft libraries are not available in a 64-bit version. That's most commonly a problem with Microsoft Access databases. Same fix as above.
You must use the correct version of Regasm.exe to register [ComVisible] assemblies. Select the one from either Framework or Framework64, depending on whether the client program is going to run in 64-bit or 32-bit mode. Or both if you want the server to be available in either.
A few COM type libraries contain bit-ness dependent arguments in their method declarations. ADO 2.8 is a notable one. Be sure to use the correct bitness of Tlbimp.exe to generate the correct COM interop assembly, Visual Studio won't do this right. Same approach as Regasm.exe
A 32-bit program has a different view of the registry from a 64-bit program. Specifically the HKCR and HKLM\Software hives are virtualized. In Regedit.exe, the 32-bit visible keys are seen under the HKLM\Software\Wow6432Node key. This can cause many subtle problems with programs that use the registry. The .NET 4 RegistryKey.OpenBaseKey() allows specifying the view you want.
Again for COM, you'll have the use the correct bitness of Regsvr32.exe to register an unmanaged COM server (not .NET servers, they use Regasm.exe). Use the one in c:\windows\system32 for 64-bit servers, c:\windows\syswow64 for 32-bit servers.
Folders in the file system are virtualized, specifically c:\windows\system32 and c:\program files. A 32-bit program will see c:\windows\syswow64 and c:\program files (x86).
Installers need to take all the above issues in consideration.
I wouldn't worry too much, if each program has an x64 download link, then use that. If not then your code will run through WOW64 emulation. And it will seem to you like it is running like normal.
Please see this related question I answered about 5 minutes ago.
WOW64 refers to windows32 on windows64
and it is a transparent emulation
laywer that allows x86 programs to run
on x64 operating systems. WOW64 will
automatically be used if you run an
x86 Windows program on an x64 Windows
operating system.
I am running Windows 7 Ultimate x64.
Visual Studio 2008 works fine.
I am using Subversion, but not Tortoise. AnkhSVN works fine.
The others I have no experience with.
Majority of software I use has no issues with x64, it's been a few years since the XP x64 troubles, and people have caught up with x64 it seems.
The primary issue with development in x64 however, is when running in x64 mode in Visual Studio, you can not edit code while debugging.
You must use x86 as the target platform in order to do so.
This is one of the reasons one of the beta's for Visual Studio 2010 defaulted target platform to x32 instead of Any Platform...