CODEWITHSUNDEEP
.netasp.net64-bit
mson
mson

Reputation: 7822

programming for 64-bit asp.net

Given a .NET 3.5 programming and client-use environment with Windows Vista. What are the implications for programming for a 64 bit OS under the below circumstances? Please specify whether there are issues of functionality or optimization - i.e. will it work and can it be made to work better in 64-bit environment.

1) You are developing a web app (asp.net c#)

2) You are developing a win forms business app (nothing driver level)

3) You are developing a hardware controller

I would have thought there are no differences in case 1 or 2 and that there might be some caveats in case 3. But I'm puzzled by the lack of support for 64-bit VPNs... There must be some issue.

Upvotes: 0

Views: 507

Answers (3)

ligos
ligos

Reputation: 4266

In addition to Franci's answer, be aware that some more abstracted resources can also raise issues.

I commonly develop using a 32-bit only ODBC driver, and must force all apps to be compiled for 32-bit.

Oh, and don't get me started about VPN clients and poor 64-bit support! A pox on network companies!

Upvotes: 0

Franci Penov
Franci Penov

Reputation: 76021

There's no difference for 1. and 2. Unless you specifically request your binary to be built against particular platform, the .Net tools compile to IL, which is JIT-ed to the actual platform at runtime. Even if you are ngen-ing the application at setup, for the majority of the cases it will not affect your development process.

However, there are couple of caveats when developing on 32-bit machine and targeting 64-bit around use of P/Invoke, COM interop or registry access. By default the app will be JIT-ed as a native app for the target system, thus:

  • P/Invoke to a 32-bit dll will fail to load the dll on the 64-bit target system, while happily working on your 32-bit dev machine.
  • COM interop will fail with class not registered for 32-bit inproc objects on the target 64-bit machine. 32-bit out-of-proc object might work, depending on how they are registered on the 64-bit machine. Again, everything will work just fine on your 32-bit dev machine.
  • Registry access to registry keys for a 32-bit application will work on your dev machine, but will write to a different place on the 64-bit target system.

You can solve any of these by forcing your application to be 32-bit, though this works for scenario 2 from your list.

As far as drivers go - I am not sure if you can really use .Net to write Windows Driver, at least I haven't had much experience in this area (last WIndows driver I wrote was back in 1993 for Windows 3.11 :-)). But if you could:

  • same issues as above apply
  • when accessing directly memory be aware of the different addressing between 32-bit and 64-bit (always use 64-bit pointers)
  • follow the best practices from the Windows Driver Kit documentation

Upvotes: 1

Rex M
Rex M

Reputation: 144172

For #1, no difference practically all of the time. I work on a massive .NET web application developed on 32-bit machines and deployed to a 64-bit server farm. The only issues we've had is with TFS - not directly related.

For #2 (and to some degree #3, as it deals with the general subject of calling into unmanaged code), a good answer can be found here.

Upvotes: 1

Related Questions