At http://msdn.microsoft.com/en-us/library/hh846498.aspx, it states: "Set the Active solution platform in Visual Studio to one of the following options. C#, Visual Basic: ARM, x86 or x64"
Does this mean that I can't create a solution that will run on all of these devices/scenarios? I want my app to run on tablets, laptops, and desktops, both x86 and x64... "AnyCPU" is not an option?
"AnyCPU" doesn't mean you'll run on ARM. It's used for code that will run as either x86 or x64 and so wouldn't include ARM.
However, if you're depending on third party libraries (and especially ones that include unmanaged code) you will often find that you need to pick specifically between x86 and x64 in order to operate with the specific version of the interop library you reference.
That said, x86 apps will run fine on an x64 machine, so you only need differentiate between x86 and ARM.
If you create an app using the WinRT runtime, you should be able to cross-compile for ARM and x86, but it's possible that the Bing Maps API doesn't currently support WinRT.
Related
I want to develop an embedded application using Colibri iMX6 module (Linux OS). I have Ubuntu 16.04 running on virtual machine and have monodevelop installed. I want to write my application in C# and cross compile it using mono for arm processor.
Can someone guide me through the process of creating an arm executable file using mono?
Thank you in advance.
One of the great things about .NET is that you don't need to cross-compile anything. CIL assemblies are, by nature, platform- and architecture-independent -- unless your assemblies link against platform-specific assemblies (such as the WPF assemblies on Windows), or if the project file build settings target specific processor architectures (like x86 or x64/x86-64). If you don't link to any platform-dependent assemblies (unless they exist on your target platform) and target the AnyCPU architecture, then assemblies you build on one system should run anywhere that mono is available.
I've got a C# Application that is 32-bit with a target x86 Installer. This application can be installed an run on x64 machine no problem. However, a third party piece of hardware from a vendor (which is integrated into the software) now requires the use of a 64bit DLL whenever we install on x64 systems.
Currently I have placed both the 32bit DLL and 64bit DLL in my project. However the target x86 Installer obviously doesn't like the 64bit DLL.
Is it possible for me to create a solution whereby I can deploy the 64bit DLL and/or 32bit DLL and still only have one installer project? (I've looked at third party software called Advanced Installer but I do not know for sure if this will help me achieve the solution I need)
Or is it possible to create a generic Installer project?
Note: Two installer (x86 vs x64) deployments aren't feasible because we have a process for automatic updates I do not want to redefine. Maintaining one MSI file is important to me.
Advice is much appreciated.
Installing the file from a x86 MSI is not a problem with Advanced Installer, the following article explains how to do it:
http://www.advancedinstaller.com/user-guide/qa-OS-dependent-install.html
Also, if you have two versions of the DLL with the same name that need to be placed in the folder you should look here: http://www.advancedinstaller.com/user-guide/qa-install-file-with-same-name.html
However, you should first check if your application can correctly load the x64 DLL, as the guys mentioned in their comments.
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.
I need to use a COM-DLL from an external company (so I have no source code) that only works with the compile-option CPU-Target x86.
But my program is a "Any CPU" program and I don't want to change this.
So I read and google a lot and found out that I need 2 processes that communicate with IPC and WCF.
The problem: WCF isn't available with the .Net Framework 2.0.
So what is the best and easiest way to do it without change CPU-Target from my main program?
If you have a x86 target dll, be it a .Net assembly or a native dll then you must host this dll in a 32 bit process - in the case of .Net this means selecting the x86 platform, otherwise your dll wil fail to load on a 64 bit machine.
If you absolutely must have a 64 bit process when possible then your only real means of using this dll will be to create an external 32 bit process that "hosts" the dll and communicated with your main 64 bit process via IPC (interprocess communication). WCF is only 1 method of communicating between processes - its not available in .Net 2.0 however you can still use other methods such as .Net remoting.
See Interprocess communication for Windows in C# (.NET 2.0)
However all of this will be a pain to implement and maintain - unless you have a very good reason just compile your application with the x86 platform instead, at least until the external company release a 64 bit version.
If you don't want to change your assembly to "x86" then you need to use some form of IPC, of which WCF is only one. Another option is to used Named Pipes to communicate between the two processes.
In the past I've always written a .NET wrapper for COM and C++ DLLs and placed it within it's own class library.
The wrapper can deal with all interop calls to the dll.
It also allows you to perform data conversion and error reporting that would be meaningful to both parties (your NET application and the COM DLL).
I would think that this should solve your problem.
EDIT
Actually I've thought further on this and the above process won't work. This is because the X86, x64 and Itanium target processors are so fundamentally different.
edited x64 is able to run x86 targetted code and so can Itanium (which used an emulator and now an extension EM64T)
There's more information here
What you may be able to do though is run your x86 dll within a separate process and implement some form of communication between them. I guess that this is why you mentioned WCF. I say this because x86 software should run on x64 system.
This would mean that your solution would have two executables one x86 and one AnyCPU, as an assembly can only be targetted at one CPU type.
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.