I made a Universal Windows Platform application. I want to publish this app. My operating system Is x86 and I want to publish to x64. Is this possible?
Generally, this is not possible, 32-bit OS is not compatible with 64-bit assemblies. There used be some ways to do this before by modifying some configuration. But I don't recommend this.
My suggestion is that you might need to create a VM with 64-bit OS on your device and then do the work in the VM. Of course, it's better to get a real device with 64-bit OS. After all, it's always the best practice to test your app completely before you publish.
Related
I have a .NET exe compiled for "AnyCPU", so it can theoretically run in both 32-bit and 64-bit mode (on a 64-bit operating system). Since my exe strongly interacts with MS Office, I need to run it with the same bitness as the installed Office version. (Please take this requirement as granted, I will gladly provide details in the comments, if you are interested.)
Now, I have thought up a solution for this, but it seems more complicated than necessary:
Compile two versions: MyExe32.exe and MyExe64.exe, targeting x86 and x64, respectively, instead of AnyCPU.
Create a launcher application Launcher.exe, which determines the bitness of the locally installed Office version (I know how to do that) and then starts MyExe32.exe or MyExe64.exe.
This would work, but I'd rather have a single, simple MyExe.exe with something like the following pseudo-code during start-up:
if (Environment.Is64BitProcess && IsOffice32BitInstalled)
{
// restart myself in a 32-bit process instead of a 64-bit process
??? // <-- this is where I need help
}
Is that possible? If yes, how?
Notes: I know about the CorFlags utility, but I'd rather have a solution that does not require modifying the exe itself at runtime.
Apparently I don't have reputation enough to post comments, so posting this as an answer instead.
If, as you say, you're deploying to an internal network, I'd recommend using a launcher anwyay.
That way users can have a single network shortcut to the launcher, that doesn't move around. The launcher can determine which bitness is required, and which is the latest release, and launch the EXE for that release.
If you allow users to go directly at the EXE, you will either encounter problems with users having the EXE opened, so you can't overwrite it, or have to create new user shortcuts for every release.
Is restarting via runtime parameter an option?
dotnet run -r win-x86
https://stackoverflow.com/a/63252884/18152293
I am designing a client application that will list several applications that I offer. A user will pick the application, and press run, then the application will be downloaded and will be loaded into the client application's domain using Assembly.Load. Here's the snippet of where it gets loaded:
var vAsm = Assembly.Load(client.GetBase());
var vEP = vAsm.EntryPoint;
var vSC = vAsm.GetType(vEP.DeclaringType.FullName).GetMethod("SetClient");
var vInst = vAsm.CreateInstance(vEP.Name);
vSC.Invoke(vInst, new object[] { client, license });
vEP.Invoke(vInst, null);
Problem: Two of the current applications are 32bit. However one of my applications is 64bit.
Question: If I build the client application in AnyCPU, will it be able to load both the 32bit applications AND the 64bit application? Or is there maybe a setting that launches it in 64bit if the machine supports it? This would be ideal, as I would just detect if they are 32bit/64bit and warn them that the one application is not supported on their machine if that's the case.
I will be testing this myself, but maybe somebody could give me some sort of advice to handle this.
Thanks!
To answer your first question, if you compile the application as AnyCPU you let Windows decide which CLR to pick. In my experience, it usually works out to Windows picking the x64 CLR on x64 operating systems and the x86 CLR on x86 operating systems but I'm not certain if that's always a guarantee. AnyCPU does not mean that it gets to run in both. You will only be able to load the version of the application which corresponds to the architecture of the CLR which loaded your client application.
I've had to deal with this sort of thing in some of the applications that I work with at the place where I'm working. I've run into some frustrating bugs when I tried interoperating with applications compiled for a specific architecture and applications compiled for AnyCPU. To make things easier and more predictable, I just ended up compiling the "AnyCPU" applications which had to interact with the "non AnyCPU" applications for each architecture for which they had to interact. There may be some people who have a more sophisticated setup but it wasn't worth the headache for me.
So, the answer to the second question is more advice. I'd just compile the client application for a specific architecture so that you know for sure which architecture that you're dealing with and then add appropriate code to detect the architecture. In fact, I think that you could use some compiler directives to store some sort of indicator as to which architecture that you're running under or even put a "detection" branch specific to each architecture in the compiler directive and that would help you do the warning that you're thinking of doing.
The alternative is to keep the client application as AnyCPU and detect which architecture the application is currently running under (if memory serves, it's IntPtr.Size == 8 for x64 applications but there may be more reliable methods; not sure...) and then only launch the appropriate applications. But still, you have to be mindful of the fact that, even with AnyCPU, you can only load applications of the specific architecture of the CLR which is running your AnyCPU client application.
Does that make sense?
You should build all your binaries in AnyCPU. That way, on a 64-bit OS, they'll run as 64-bit and on a 32-bit OS, they'll run as 32-bit. If you compile to x64, it won't run on a 32-bit OS at all. If you compile to x86, you'll always run as 32-bit, even on a 64-bit OS. The final rule is that you can't mix & match x86 and x64 bins in the same process. The mismatching ones will fail to load.
I have my own old Windows Service (.Net 3.5) which was running at 32-bit windows. Now we have a x64 Windows Server 2012, and would like to migrate this Service.
My question is : should I do something special with this Windows Service in order to achieve in it "all benefits" of 64-bit framework ? I mean - should I set some options during building/compiling it in Visual Studio 2010 (project/solution properties). Or something else ? Or I don't need to do anything - it will use 64-bit framework by itself, no matter how it's build.
It depends on the build target:
if the platform target is x86, it will always run as a 32-bit executable (or not at all)
if the platform target is x64, it will always run as a 64-bit executable (or not at all)
if the platform target is Any CPU without "Prefer 32-bit" enabled, it will run as 64-bit where possible, else 32-bit
if the platform target is Any CPU with "Prefer 32-bit" enabled, it will run as 32-bit where possible, else 64-bit
You can use Environment.Is64BitProcess to check how your application is running (or just look in task manager).
For your scenario, Any CPU without "Prefer 32-bit" would seem the correct choice.
Since this started as a 3.5 project, no, you probably don't have to change anything. The setting that matters is Project + Properties, Build tab, Platform target setting. The default in older versions of Visual Studio was AnyCPU. Which does what it says, it runs on any CPU so you get a 64-bit process on a 64-bit operating system. If it is "x86" (or the Prefer 32-bit checkbox is checked) then you force it to run in 32-bit mode.
It doesn't actually matter much btw, the only benefit of a 64-bit process is that it can consume a lot more memory. Well past the 2 gigabyte that a 32-bit process is restricted to. A service should never have that kind of impact on a machine.
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.
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...