My development machine is Win XP Pro 32 bit and production machine is Windows Server 2008 (64 Bit) with IIS 7. On my development machine I want to compile ASP.NET (Using aspnet compiler) to 64 bit byte code.
Can anyone please tell me how to do that? Please do not suggest any way to run 32 bit application on 64 bit environment.
I want 64 bit application to be compiled on 32 bit machine so that when it runs it will take full advantage of 64 bit O/S without any emulation.
Leave the target platform at AnyCpu and .NET will automatically run natively on 64bit when executed on a 64Bit operating system
Clarification:
(this started out as a comment but I thought it might be interesting for the question as well)
Actually you never compile to a special architecture. You always compile to IL.
That's something like Java Bytecode. And that bytecode is the same for 32 bit and 64 bit.
The Virtual Machine (.NET Framework) on the machine the code gets executed then compiles the IL to actual machine code while running (through the Just In Time compilation). So, no matter where you compile, you'll always end up in IL that's bit-ignorant.
The setting in .NET is only an instruction in IL that tells the JIT (Just in Time compiler) to specifically use 32bit/64 bit. By flipping that one bit in your assembly you could still execute it in AnyCpu or x64 without recompilation.
This setting is only used and needed in case you call out to native code that isn't bit-ignorant (when interacting with COM components or doing p/invoke calls)
There's an option in Visual Studio 2013 now to direct IIS Express (which is usually used for debug) to run in 64 bit mode.
It's at Tools -> Options -> Projects and Solutions -> Web Projects -> Use the 64 bit version of IIS Express…
.net apps will re-target themselves for the target machine environment assuming that you didn't specifically choose to compile in 32-bit mode. This can be found under the project build options.
Related
A solution containing my MVC application is having nearly 20 different projects (one of them is MVC, few are WCF service applications, and the rest are class libraries.
They all work, and gets build fine.. but the issue is they are giving warnings related to platforms while doing build. I have checked in the configuration manager that some of them are set as "x86" platform, and some of them are set for "Any CPU" and I feel I receive the warnings due to this.
As a developer, and in order to support cross-platform, I think I need to set all projects under this solution to target "AnyCPU".
I would like to know if this is the safer approach? or if there is any risk involved during deployment?
Any inputs over this, much appreciated.
AnyCPU is the least restrictive and should be fine. x86 will restrict to 32-bit process and require running in WOW64 mode on 64-bit platforms. x64 will limit it to 64-bit. AnyCPU creates DLLs that can run in the current loaded process (whether it is 32 or 64 bit). This should be the option unless you have some sort of limitation or optimization that requires you to target a specific platform.
I am getting following exception at runtime when I changed platform from AnyCpu to x64 of a web application. I am running it locally on windows 7 x-64
[BadImageFormatException: Could not load file or assembly or one of its dependencies. An attempt was made to load a program with an incorrect format.]
As well as checking whether you have any 32-bit components you should also check whether the ApplicationPool that's running your app is set to run as 32-bit. From IIS Manager > Application Pools > Your App Pool > Advanced Settings > Enable 32-Bit Applications. This should be set to False if you want to run in 64-bit mode or True if you want to run in 32-bit mode.
Sounds like you have a component/DLL that is 32-bit, while you are trying to force the Web Application to run solely as a 64-bit application.
You may also consider looking at:
Read
If you leave it as anycpu and it's compiled on a 64 bit system, it should compile and run on 32 and 64 bit. Don't try specifying an architecture when compiling unless you want it to be only 32bit specifically.
Ensure you have the 64bit framework installed.
I am developing an ASP.NET Application and am trying to use the 64-bit driver version of ODBC on my 64 bit win 7 machine, because the deployment server has Windows Server 2008, which is naturally in 64 bit, since Microsoft decided not to make a 32 bit version afaik.
The first issue was an System.Data.Odbc.OdbcException "ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application". Despite the fact, that I am developing on a 64 bit operation system, the compiler seems to have decided to compile for 32 bit. After some research I changed the target platform to x64 in every of my (own) assemblies. I am using NHibernate and Spring.Net, but I read somewhere that 64 bit is no problem for NHibernate. I did not check Spring.Net yet. The compilation began.
I got some warnings that quite every .net assembly is built for another platform, but I read somewhere again that I can ignore these warning and the application should run just fine because the runtime (or compiler?) will figure out the right assembly.
So I tested the application right away and was rewarded with an System.BadImageFormatException (wrong format). It was again an exception concerning 32/64 bit issues although every one of my assemblies is compiled as 64 bit.
I am slowly starting to hate 64 bit. Seriously. Is it that difficult to build an 64 bit application on an 64 bit operation system for a 64 bit server with 64 bit drivers?
Does anybody have a solution or have experience with this issue? I found many workarounds with using 32 bit, but that is not an option here. It has to be a 64 bit solution.
Nevertheless I will continue trying for myself to solve this. I will write any progress here.
Update:
Spring.Net seems to be just fine on 64 bit since the assembly is "dynamically compiled at runtime to the native machine architecture".
i fought with this same error for several hours. My environment was slightly different, but the error was the same. I was using SSRS, Report Builder 3 and SQL Server 2008 R2 on a Win Server 2008 R2 x64 Box
I could create connections and test them successfully in SSRS, but when i would use them, i got the error above. It was resolved when i created a 32bit DSN of the same name and parameters.
I usually try to go other way: If I don't need any native in-proc DLLs, I use AnyCPU. So final program can be used on both x86 and x64. If I need native in-proc DLLs, I always chose x86 32bit version, because it is much easier to make it work correctly, and IMPORTANTLY I don't need any 64bit features. So why 64bit version? I just go to IIS configuration and setup my asp.net application to run in 32bit mode.
For example my current deveopment environment is fully 64bit and works perfectly. But my production server is setup to host my app in 32bit mode. It works perfectly, no 64bit issues. I apologize if this answer is not good for you, but I really never needed 64bit stuff in my asp.net applications.
update: I use 32bit IIS on production server. I am not sure if it is possible to setup asp.net as 32bit in 64bit IIS.
We are developing a Data Synapse calc node process in C# that requires functionality in a Win32 DLL. We have no problems building this.
The question is it has to run on a Windows 64 bit system, with Data Synapse 5.1 Grid APIs for Windows 64. While Windows 64 will run most processes transparently using WOW we don't know that Data Synapse's 64 bit will in some way stop this from working?
Anyone done this?
8 Jun 2009: Update.
when we try to run a win32 service on the win64 grid we run into problems because on Win64 the grid code intrastructure runs as 64 bit Java. This java calls our service using a win64 JINI call to our service which is implemented as a DLL. Unfortunately as a Win32 DLL.
Do you want your C# code to run as a .NET service? .NET Services run in-process and as far as I know, there is no way of mixing 32bit and 64bit code within a single process.
I see two solutions
1) Run 32bit DataSynapse engines OR
2) Run the C# code in a surrogate 32bit process. Use some form of IPC to communicate between some stub code running in the engine process and the surrogate process.
I believe this infrastructure has already been built by DataSynapse for C/C++ code and is called IsolateService. To use IsolateService a simple C->.NET bridge would need to be developed on the remote end or a .NET executable wrapper developed to host the .NET dll and handle COMs.
Nathan
Maybe you can install and run a win32 engine at the win64 machine, in that case everything is in WOW.
If you try to install a win32 engine on a win64 machine, make sure that your installed manager is ALSO USING a 32 bits JDK Java (look for the environment variable JAVA_HOME).
So, in order to have a 32-bit running on a 64-bit machine, you must have a 32-bit Java JDK, and the DataSynapse manager must have been installed pointing to the 32-bit Java machine (when installing the manager, the JAVA_HOME variable should be pointing to the 32-bit version).
Are there any compatibility issues that would prevent this from working? Do I need to have a 32-bit VM to use when working on projects for this team?
No. Should work perfectly well.
Read a little here: http://msdn.microsoft.com/en-us/library/ms973190.aspx
I run Vista 64 and the other members of my team run XP 32 bits, the only issue we've had so far was with a third party COM-component where the interop assembly wasn't easy to generate on the 64 bit machine. Once it was generated it screwed up the other machines. That was fixed by generating the interop assembly on the 32-bit machines and checking it into source control.
I heard in the latest .Net-rocks podcast that setting x86 instead of "Any CPU" in the build configuration should resolve a lot of problems, but since I haven't had any problems other than the one I described I have not yet tried that.
It doesn't matter what your environment is, develop on whatever machine you wish. I would be concerned about the QA, staging and production environments. If they are all 32 bit, I would want a 32 bit VM to test my code.
I'm not sure about collaborating with other developers in a different windows 32/64-bit environment, but I can speak about deploying an .NET application that was developed in Windows XP 32-bit on a Windows 2008 64-bit server.
The only problem I had was with an application that relied on a 3rd-party assembly. We only had a 32-bit version of the assembly. So, in order to run our application in a 64-bit environment, I had to compile my project for x86 (as you described). It solved everything.
All other applications I was able to get running without changing a thing (they were compiled in the 'Any CPU' mode.
I suspect you won't have problem unless you have some external assemblies. If that's the case, then you will either have to recompile them or simple force your project to compile to x86.
I know that doesn't definitely answer you question, but hopefully it helps.
Andrew