Currently it is not possible to load x64 assemblies (i.e., with Target Platform set to “x64”) into the Code Protector application. However, it is still possible to protect these assemblies as both the command-line tool, ProtectCmd (see http://www.inishtech.com/KB2) and the MSBuild support (see http://www.inishtech.com/KB12) [which uses ProtectCmd internally] will handle AnyCpu, x86, x64 and Itanium assemblies successfully.

Based on this, one can work around the problem with loading x64 assemblies into Code Protector by temporarily compiling your assembly as AnyCpu, which can then be loaded into Code Protector in order to generate a Code Protector Configuration (.SLMCfg) file. Upon completion of this, one can then adjust the Platform Target to x64 and use the command-line tool (ProtectCmd) or the MSBuild integration, which will successfully process your x64-targetted variants of your binaries.

While we intend to remove the current Code Protector restriction on processing x64 assemblies in a future release as part of ongoing development, we do not plan to release a 64 bit edition of Code Protector but to continue to only ship a single download of Code Protector which will handle the various supported Target Platforms, .NET variants and .NET execution hosts.
 

Code Protector application is the only element of the SLPS system that bears this restriction:-

1. ProtectCmd and the MSBuild integration will handle x86, x64, AnyCpu and Itanium assemblies
2. The SLP Runtime DLLs are marked AnyCpu and hence will work appropriately in x86 and x64 deployments [as an assembly compiled with AnyCpu, it's fully usable in a 64-bit environment]

Currently, the assembly Target Platform modes supported by Code Protector are x86 and AnyCpu. This is for the following reasons:

1. We wish to have just one MS download of Code Protector – as a standard MSI file is either x64 or x86 and cannot be both. (We believe having two separate MSI downloads of the Code Protector (i.e., x64 and x86) could lead to unnecessary confusion for most users.)
    
2. We believe that x86 and AnyCpu are by far the most advisable and commonly used Target Platforms. A related piece of information is that while Visual Studio 2008 defaults to AnyCpu mode, Visual Studio 2010 defaults to x86 (See http://blogs.msdn.com/rmbyers/archive/2009/06/8/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx for the rationale behind this).
    

Based on the above, the primary reasons for needing to mark an assembly x64 are thus:

1. it is a host (EXE) that knows it definitely should not ever run in 32 bit mode;
2. you need to ship two editions of your software e.g., as separate x86 and x64 MSIs, and hence want to mark the EXE's as x64 and x86 (it's generally fine for the DLLs to be AnyCpu).

Given that the above situation is already a complex one, we believe that necessitating the automation of the protection process is tolerable in this context.