在K2.net 2003的年代，K2应用系统的开发人员们从来也没有为开发出的应用系统的部署头痛过，简单的复制就可以使基于K2的Web Application部署在企业环境中的任意服务器上运行。

在64Bit的操作系统大规模部署以前，K2应用系统的开发人员们仍然不用为应用系统的部署痛苦，Visual Studio 2005/2008提供快捷方便的部署工具方便的进行Web Application的部署。

直到最近，有系统部署人员反映按照以前的经验部署自定义开发的Web Application时遇到无法正常加载所引用的K2相关的DLL的问题，在仔细分析问题现象后，发现此问题是一个BadImageFormatException异常：

系统部署人员也没有仔细查阅该异常的具体含义，简单的以为是缺少依赖项的引用，于是将许多K2相关的DLL引用了一次，并尝试将这些DLL放入到GAC中，还是不能正常运行，继而怀疑基于K2 Blackpearl的Web Application到底能否单独部署在独立的Web服务器上，还以为必须要在此服务器上安装K2组件才行。

经过一个简单的现场分析：整个企业环境中存在三套K2环境，一套开发环境，一套UAT环境，一套生产环境。每套环均由一台K2服务器、一台Web服务器、一台SQL服务器组成，三套环境均是64Bit的操作系统+64位的SQL Server 2005。由于应用拓展的需要，在企业外网区域安装了一台32Bit的服务器将应用系统发布在外网供广域网员工使用，问题出现在应用系统从开发环境到外网服务器的部署过程中，于是初步确定是32Bit与64Bit环境的影响造成BadImageFormatException异常。

仔细分析发现：IIS 6的应用程序池也存在32Bit和64Bit运行模式，这也是多版本的.net framework能运行的原因，同一个程序池在同一时刻是不能同时调用32bit和64Bit的程序的，这是出现BadImageFormatException异常的根本原因，至此找到原因，问题的解决也就简单了。

另：Windows 2008 R2中的IIS 7的程序池也有启用32Bit应用程序的功能，默认是不启用的，这点要特别注意。

为什么要启用32Bit应用程序呢？我让IIS以64Bit模式运行不是性能更好吗？答案取决于自定义WebApp中引用的K2相关DLL的运行模式，如下图所示(64Bit的windows 2008 R2环境)，大部分K2相关的DLL处理器架构是MSIL(公用语言运行时，如果你不清楚这个词意味着什么，赶紧Google一下)，有些是X86，有些事AMD64。MSIL意味着这个DLL由运行时加载该DLL的.net framework编译成合适的处理器架构来运行，而X86或AMD64则意味着该DLL只为32Bit或64Bit的.net Framework调用

常规的基于K2的WebApp应用系统均会引用Sourcecode.Workflow.Client.DLL，它存在一个依赖项：SourceCode.HostClientAPI.DLL，这两个DLL均非MSIL处理架构，IIS程序池是否要启用32Bit应用程序取决于承载的WebApp是否引用了32Bit的DLL。那么如何知道自己应用的K2相关DLL是32Bit还是64Bit的呢？在K2安装了路径中有两个Bin目录：c:\program files\k2 blackpearl\bin和c:\program file\k2 blackpearl\hostserver\bin，在64Bit的操作系统中安装的K2 Blackpearl，HostServer\bin目录下的DLL是64Bit的，K2 blackpearl\bin目录下是32Bit的DLL