1. VS has only x32bit version, NO x64 version.
2. DotNet Framework including basic library (System.*), CLR, JIT compiler, etc, have x32 and x64 version. For example, I have a C:\Windows\Microsoft.NET\Framework and a C:\Windows\Microsoft.NET\Framework64 folder.
3. a dotnet assembly only contains IL before first time running, so at that time, it's not process-specific (x32 / x64). By default, the Platform Target is "Any CPU." Remember that our C# or VB compiles to IL, and that IL is basically processor agnostic. It's the JIT that makes the decision at the last minute.
4. When a dotnet assembly is loaded into x32/x64 CLR, the CLR helps you find corresponding dependent modules.
5. That 64-bit process is also having its code JIT compiled to use not the x86 instruction set we're used to, but the AMD64 instruction set. This is important to note: It doesn't matter if you have an AMD or an Intel processor, if you're 64-bit you are using the AMD64 instruction set. The short story is - Intel lost. For us, it doesn't really matter.
6. VS installed on either 32-bit or 64-bit OS can create 32-bit or 64-bit applications, but of course the applications need the corresponding platform to execute.
7. To debug a x64 app on x64 OS, you need VS remote debugger as a must as VS is only x32 app so that it needs a way to debug a x64 app.
MOre detail, please refer to below two:
1. My blog
2. Scott blog
For further understanding:
2. Reference to a x32 dotnet assembly for building and then make that app can call corresponding that assembly x32/x64 version at runtime on x32 / x64 OS?