Microsoft Dynamics CRM Team Blog: 32-bit vs. 64-bit CRM SDK Assemblies

[Blog bot]

Источник: http://blogs.msdn.com/crm/archive/20...ssemblies.aspx
==============

As you may have noticed, recent updates to the Microsoft Dynamics CRM 4.0 SDK now include two different sets of SDK assemblies. This had led many of you to ask when the different sets of assemblies should be used. Luckily enough, most of the time there is no wrong choice because the Common Language Runtime and CRM will take care of the heavy lifting without you even knowing. However, depending on the type of application being developed and how your code will execute, there are some things to be aware of and associated actions you can take to ensure that your solution can easily be ported to any CRM 4.0 deployment.

Common Language Runtime Support

For the sake of this discussion, I’m going to assume some familiarity with the Common Language Runtime (CLR) and .NET development, but will dive into some of the details regarding its support for 32-bit and 64-bit applications. The 2.0 release of the CLR introduced a 64-bit version in addition to the already existing 32-bit version. Along with this, the capability to have your .NET code compiled to target a specific platform was also introduced. For instance, when developing with C# and Visual Basic, the developer can pass in the /platform switch to the compiler with potential values of x86, Itanium, x64, or anycpu with anycpu being the default if the switch is not provided. As you can see, this allows the developer to control exactly what platforms the compiled .NET code can execute on. For executables, what happens is relatively straightforward – x86 compiled executables run in 32-bit mode on all systems (WOW64 on 64-bit operating systems), x64 will only execute on computers that support the AMD64 or EM64T instruction sets, and for executables compiled with anycpu, the application will run as a 64-bit process on 64-bit operating systems and a 32-bit process on 32-bit operating systems. Similarly, .NET class libraries can be loaded by an executable only if they support the platform that the loading executable is running under. Therefore, a 32-bit process cannot load a .NET class library that is compiled as x64 assembly only and a 64-bit process cannot load an assembly that is compiled to be x86 only. However, if the class library is compiled as anycpu, it can be loaded by both 32-bit and 64-bit processes.

You can refer to the articles referenced at the end of this article for more information regarding how to build 64-bit applications using the CLR and the .NET Framework.

CRM 4.0 SDK Assemblies

To determine what platform a specific assembly is compiled to target, you can use the CorFlags.exe tool included with the .NET SDK. Simply running it with the file that you want to examine as a command line argument, you will be able to gather enough information to determine what platforms the targeted file supports. For instance, here’s what the output looks like when running CorFlags.exe on the 32-bit version of Microsoft.Crm.SdkTypeProxy.dll.



The important pieces of information here are the PE and 32BIT values. The breakdown for the various different platform targets and their associated values are as follows:

table.msotablegrid {border:solid black 1.0pt; font-size:11.0pt; font-family:"Cambria","serif"; } p.msonormal {margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; font-size:11.0pt; font-family:"Cambria","serif"; }

/platform Switch

PE

32BIT

anycpu

PE32

0

x86

PE32

1

64-bit

PE32+

0

Based on this chart, we can see that this is indeed the 32-bit version of the Microsoft.Crm.SdkTypeProxy assembly. If we ran the same command on the 64-bit version, we’d see that it is compiled with the anycpu value. I won’t get into the details about why these are compiled as such, but given this information, we can start seeing where the problems might pop up during solution development and when it is appropriate to use the two different sets of CRM 4.0 SDK assemblies.

For more information regarding CorFlags.exe, refer to the link at the end of this post.

CRM 4.0 Solution Development

Now that we have understand of some of the details about how the CLR executes .NET code in 32-bit and 64-bit processes and the differences between the two sets of CRM 4.0 SDK assemblies, let’s talk about what it takes to build a portable solution against the CRM 4.0 SDK. There are several different places where you may write code that links against the SDK assemblies, so let’s walk through each of them.

Plug-ins

Plug-ins could be one of the more challenging ones to get correct given the different factors making up who will actually end up executing the code. If the plug-in is registered to execute synchronously, it will execute in the IIS worker process, if the plug-in is registered to execute asynchronously, its execution will be in the MSCRM Asynchronous service, and if the plug-in is available offline, it will run in the Outlook client hosting process. Depending on the complexity of the CRM topology that your plug-in is running in, the “bitness” of the various processes that will execute your plug-in may be incompatible with each other. In this case, the best solution would be to see if you can compile your plug-in code using the anycpu option as this would allow your plug-in to execute in each of these processes without any changes. If you require your plug-in to be compiled platform specific, then you will need to take into account how the plug-in is going to be registered, the processes that may execute the plug-in, and ensure that your plug-in is compiled in a manner that is consistent with the bitness with which those processes will run. This may, however, limit the portability of your solution and require that you have different plug-in assemblies for the different environments you plan on deploying your plug-ins in.

Custom Workflow Activities

Custom workflow activity assemblies pose many of the same challenges as plug-ins. The one scenario we can rule out is having the custom workflow activity executing in the Outlook client hosting process. However, both the IIS worker process and MSCRM Asynchronous service may load the custom workflow activity assembly at various points in a workflow’s lifetime. Therefore, like plug-ins, if you can compile your custom workflow activity assembly with the anycpu option, you can rely on the CLR and CRM to do the heavy lifting for you. If you need to compile your custom workflow activity assembly to be platform specific, you’ll need to ensure that you are registering a version of the assembly that is compatible with the CRM processes that it will execute in for the environments you want it to have it registered.

SDK Client Applications

This type of solution is the one that developers hit most often as the code is not executing from within CRM, but rather an external process that is reading and writing data from CRM via the SDK. When the code is executing within a CRM process, the CRM setup process will ensure that the correct SDK assemblies are in place to ensure that your solution can execute given the CLR restrictions already discussed. However, when calling the SDK from outside of CRM, your application needs to link to the appropriate SDK assemblies so that they can be loaded into your process. Luckily, this is easy to fix using the two sets of assemblies that are now included in the CRM 4.0 SDK. If we look back at the information we gathered from CorFlags.exe earlier, you’ll remember that the 32-bit SDK assemblies are compiled to target x86 and that 64-bit SDK assemblies are compiled to target anycpu. Given this information, simply linking against the 64-bit SDK assemblies from your client application will do the trick as these can be loaded in both 32-bit processes as well as 64-bit processes. If you are building a SDK client application that is going to execute as a 32-bit process only, then you can use either set of the SDK assemblies without running into any issues.

Putting It All Together

As we’ve discussed, there are two sets of CRM 4.0 SDK assemblies – one for 32-bit and one for 64-bit. This may pose problems at runtime for your code, but with a few simple checks and some configuration when building your code, you can make your solution portable across the various environments where your code may execute. The simplest solution is to build your code using the anycpu so that it can target both 32-bit and 64-bit processes and let the CLR and CRM take care of the rest. Luckily enough, this is the default setting in Visual Studio, so you don’t even need to do anything to add this capability to your solution. Just remember to link against the 64-bit version of the SDK assemblies if you are going to potentially run your anycpu code from outside of CRM. If you do need to compile your code to target a specific platform, then you are going to limit the portability of your solution. In this case, you will need to verify that the platform that your code is compiled to target is the same platform that CRM is going to be executing in when tries to execute your code.

To get the CRM SDK assemblies I’ve referred to, you can download the latest version of the SDK.

Additional Resources:

• /platform Compiler Switch
• 64-bit Applications
• Migrating 32-bit Managed Code to 64-bit
• CorFlags.exe documentation

Cheers,

Nirav Shah



Источник: http://blogs.msdn.com/crm/archive/20...ssemblies.aspx