I have a .NET 5 WPF application built for AnyCPU platform.
In the project file i have:
WinExe
net5.0-windows
The output folder contains all dll and an exe but when i run the exe on a 32 bits windows i get this message:
This version of software.exe is not compatible with the version of windows
you're running. Check your computer's system information to see
whether you need a x86 (32-bit) or x64 (64-bit) version of the
program, and then contact the software publisher.
To ease deployment and run, I want to have only 1 build and 1 shortcut no matter the target system.
So my initial solution was to run the application using dotnet.exe and having the core dll as a parameter.
dotnet.exe software.dll
The WPF application start and run fine but the console with the dotnet command line is kept open during the application lifetime.
Is there a solution to get rid of the console when I start the WPF application using dotnet.exe ?
No solution without exe file at this time, so as a workaround I found a way to produce both 32bit and 64bit exe.
In the Visual Studio build configuration manager, I added x86 and x64 platforms.
Which updated the csproj with
<Platforms>AnyCPU;x86;x64</Platforms>
Then I added in csproj
<AssemblyName>MySoftware-$(Platform)</AssemblyName>
When I build the solution, it automatically append the targeted platform to the exe and dll for the platform.
MySoftware-x86.exe
MySoftware-x86.dll
MySoftware-x64.exe
MySoftware-x64.dll
Finally, I call "dotnet.exe build" twice for both x86 and x64 using a script.
To put all this together, a 32-bit machine can run anything with a PE
set to PE32, but nothing with a PE of PE32+. A 64-bit machine can run
your file in 64-bit mode as long as 32BIT is 0, but if 32BIT is 1 then
it must use WOW64.
https://illuminatedcomputing.com/posts/2010/02/sorting-out-the-confusion-32-vs-64-bit-clr-vs-native-cs-vs-cpp/
Why would you want to compile a .NET assembly specific to 32-bit or
X64, or IA? Usually because you're P/Invok'ing into a x64 specific
native dll.
The interesting things that corflags tell us are these:
CLR Header: The compiler version...2.0 is .NET 1.1, 2.5 is .NET 2.0
and 3.0 is .NET 3.5. Don't ask. ;)
PE (Portable Executable): PE32 is 32bit and PE32+ is 64-bit.
32BIT: Are we asking to force 32-bit
execution or not?
www.hanselman.com/blog/32bitness-and-64bitness-and-migrating-dasblog-on-iis7-and-aspnet-under-vista64
Related
I use TAPIEx.Net in my application to connect to a TAPI-Driver.
I compile my Application as AnyCPU. TAPIEx.Net has a x86 Version (TAPIEx.net.dll) and a x64 Version (TAPIex.net.x64.dll). For developing, I reference TAPIEx.net.x64.dll (because I develop in x64 Environment). But I am searching for the solution what I have to do, when a customer loads the application in 32bit-Environment?
I have a solution where the executable's target platform was initially set to x86, many other projects were set to AnyCPU, and included 3 projects in .Net 3.5 (everything else .Net 4.0). I presume this is why the installer wrote to the HKEY_LOCAL_MACHINE\SOFTWARE registry key.
Recently, I fixed some issues and now all projects are .Net 4.0. Additionally, I set the executable target platform to AnyCPU. I found the application was now installed in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.
[sidebar - we have p/invokes - DllImport attributes - that did not
specify a CallingConvention. When this was modified both in
managed and unmanaged code to specifiy Cdecl and __cdecl, we were able to
upgrade dependent projects to .Net 4.0 without receiving a PInvokeStackImbalance exception.]
We develop currently with VS2010 on Windows 7 (64-bit) machines.
My question is: Did the installer write to \SOFTWARE\ initially because some of the projects were .Net 3.5?
Also, if this application is intended to be installed on WindowsXP (32-bit is expected to be supported) machines, is the registry key problematic? Better yet, what should I look for in build options that ensures compatibility on WinXp 32-bit systems?
Only a 64-bit installer will avoid Wow6432Node on a 64-bit operating system. In a Setup project, that's set by the TargetPlatform property of the installer, it defaults to "x86". Change it to "x64" if you changed the C# EXE project's Target platform to AnyCPU. This will also ensure that your program is installed to c:\program files and not c:\program files (x86).
You will thus need to maintain two installers. Bit of a headache, you can avoid it by setting the C# EXE project's Target platform to x86 so both the installer and your program access the key in Wow6432Node.
The pinvoke problem is normally the other way around, 64-bit code has only one calling convention and there's no difference between cdecl and stdcall.
Our Teamcity agent is running on a 32bits OS for now and this was not an issue up until now (we now have an x64 applications to build in there).
I heard its possible to compile x64 applications on a 32bit OS but I've never did it. What would be the step required to have Teamcity build a specific project in x64 - Ideally using MSBuild?
When I set my project's MSBuild property "Run Platform" to x64 my agent give me the following warning: "Unmet requirements: DotNetFramework4.0_x64 exists"
As a side note: we will eventually move the agent to a 64bits OS but I would like a short term solution.
I think the Run Platform for MSBuild in TeamCity is for what version of MSBuild to use, it's looking for MSBuild.exe in the C:\Windows\Microsoft.NET\Framework64\v4.0.30319 folder, when you're on a 32-bit version of Windows, and that framework isn't installed. However, the 32-bit version of MSBuild can invoke the C# Compiler that can still produce x64 assemblies, even on your 32-bit machine.
What you want to do is do a Run Platform for x86, but pass /property:Platform=x64 as one of your commands. If you don't have a x64 Configuration, you may considering trying to pass it /property:Platform="Any CPU". However, Any CPU would only be guaranteed to work if all the assemblies you reference in your project are set the Any CPU as well. Alternative, you can create a custom configuration where all your assemblies are specified x64, and pass that via command line to MSBuild.
Keep in mind if any of your projects are C++, you will need to make sure you have the x64 compilers installed, as I don't think they're installed by default.
I have an executable build with Visual Studio 2005 using C#. dumpbin reports that it is x86 and it is claimed that it was built as a x86 target. However, when I try executing it, it somehow becomes a 64bit executable as reported by task manager, process explorer and procmon shows that it loads Framework64. And it fails eventually due to failure to load a 32bit DLL.
What could cause this behavior?
You are building it with the AnyCPU target. If you want it to be x86 even on a 64 bit system, then you must target x86.
When you target AnyCPU, the loader runs the process as a 64 bit process on a 64 bit system, but a 32 bit process on a 32 bit system.
Change the platform target from "Any" to "x86" in the project properties / build configuration list.
One can use corflags.exe to force it to run as 32-bit.
O:\>corflags
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.
Usage: Corflags.exe Assembly [options]
If no options are specified, the flags for the given image are displayed.
Options:
/ILONLY+ /ILONLY- Sets/clears the ILONLY flag
/32BIT+ /32BIT- Sets/clears the 32BIT flag
/UpgradeCLRHeader Upgrade the CLR Header to version 2.5
/RevertCLRHeader Revert the CLR Header to version 2.0
/Force Force an assembly update even if the image is
strong name signed.
WARNING: Updating a strong name signed assembly
will require the assembly to be resigned before
it will execute properly.
/nologo Prevents corflags from displaying logo
/? or /help Display this usage message
"What could cause this behavior?"
To be techically accurate in answering this question, but not quite in the spirit you asked, what causes this behavior is the lack of the 64-bit DLL.
Why doesn't the program have a 64-bit version of it?
In a few years I doubt 32-bit systems will exist anywhere except as ARM and ARM systems will need new DLLs to be recompiled anyway.
reading excel files from C# working well in 32 bit version server. It is not working in 64 bit version (Windows 2003 server), because excel data connection dll not supported in 64 bit version.
Is any other option available ?
In your project properties set the target platform from 'Any' to 'x86'.
Details:
In Windows x64 a process may be started as 32bit or 64bit process. A 64bit process can only load 64bit dlls and a 32bit process only 32bit dlls.
If your platform target (e.g. specified in the project properties) of your .Net application is set to "Any CPU", the intermediate code will be compiled to 32bit or 64bit code depending on the target platform, i.e. on a x64 system 64bit code will be generated.
Therefore the code can no longer load a 32bit dll.
If your code loads unmanaged assemblies you should always specify the target platform explicitly