To deploy ASP.Net web application in a 64 bit IIS 7 web server, Should i compile in x64 or Any CPU mode. I know that both is going to work but is there any performance impact on choosing one over the other ?
Only compile for x64-only if you absolutely need it. There shouldn't be any noticeable performance issues.
Related
We have a large ASP.NET application that has been built over the last decade and is now running in .NET 4.0.
Recently, we upgraded to Visual Studio 2012 Premium (from 2010 Premium).
Our application compiles successfully, and when we run/debug our application its from a local IIS on each one of our developer workstations (versus using using the development server).
Ever since upgrading to 2012, when we are debugging our application, we have noticed the application to run VERY slow in loading ASP.NET pages, it can take nearly 20-30 seconds per page. But, when we access the application straight to the local IIS and without using the VS2012 debugger, it runs great. Something about debugging in Visual Studio 2012 on our application is slowing down our application performance significantly.
Is there a good tool we could use to capture what is going on in the background?
Also, this is happening on both Windows 7 Enterprise machines and Windows 8 Pro machines. All 64 bit with 8+ GB of RAM, and Intel Core i7 processors.
Thanks for any help.
My debug on VS 2012 was very slow, it was taking 20~30 seconds for every step.
My solution was disable the .NET Reflector extension.
Go to Tools - Extensions and Updates - Disable .NET Reflector.
Try to delete all breakpoints, then clean and rebuild solution and debug it again.
Maybe your application is throwing and catching lots of exceptions? This can really slow things down in debug mode. Set the Exceptions properties to break on CLR exceptions and see if this is the case.
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 have an ASP.NET application that I am currently developing in C#.
The application needs a set of reference (dlls) to work. At development phase I need to use the x86 (32 bits) libraries but when I put the application in production I need to substitute the libraries with the x64 (64 bits) version.
Is it correct and safe to deploy the sytem in my IIS7 (Server 2008) as it is in Visual Studio (so working with x86 libraries) and then change the x86 libraries with the x64 directly in production environment (by copy pasting)? If that is not the case may you please suggest a more clean way?
In all cases you should test/develop with the same version as you deploy on production. So in development you should compile for x64 if your production server is x64. Otherwise you have the risk of error when you go to production. For example you can use a x86 lib which you do not compile yourself. The you will only notice this on production, which is a little late.
The way to go is to make all environments the same.
I have an asp.net application and can debug the application fine when I click F5 (Start Debugging), hits breakpoints, no problem. When I have a web app open and I try to attach to the w3wp.exe process, I get a message saying "Unable to attach to the process. Mixed mode debugging is not supported on Windows 64-bit platforms." Is there a way for me to attach to the process?
My asp.net application is .net 3.5, has a platform target specified as "Any CPU", and the Configuration set to debug. I am developing on Win7 x64 bit system.
VS2008 doesn't support mixed mode debugging in 64 bit (it runs in 32 bit itself).
VS2010 does support this.
Try just selecting T-SQL, Managed, x64 when attaching the remote debugger.
See a possible solution here: "Mixed mode debugging is not supported on Windows 64-bit platforms" when trying to attach to an ASP.NET process using Visual Studio 2008
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.