用VS2010英文版开发环境 制作中文安装包 注意事项

关于这个安装包制作过程可以参考：http://wenku.baidu.com/view/bc4050df7f1922791688e867.html

用VS2010制作安装包简单、明了。这篇文章里还有一点没提及，如果你的vs开发环境是英文版的，那想发布一个中文的安装包就会出现问题。这时候需要到官方下载一个中文的.NET 客户端，像这个样子的——dotNetFx40LP_Client_x86_x64zh-Hans.exe，并放到路径C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client\zh-Hans下。读者需要根据自己的系统和软件安装位置找到相应的路径。最后再将安装包语言设置成简体中文就可以了。

另外如果是要使用35SP1的情况下，可能会出现下列错误:

[html]  view plain  copy

1. The install location for prerequisites has not been set to ‘component vendor’s web site’ and the file ‘DotNetFX35SP1/dotNetMSP/x86/NetFX3.0-KB936705-v6000-x86_RTM_en.msu’ in item ‘.NET Framework 3.5 SP1′ can not be located on disk. See Help for more information.  

解决方案参照了： http://blog.csdn.net/maths_bai/article/details/5626955

1. 先取得 .NET Framework 3.5 Service Pack 1 (Full Package) ( 231 MB )
2. 再下面进行修正即可!

具体方法

1. 先找到 [Program Files]/Microsoft SDKs/Windows/v6.0A/Bootstrapper/Packages/DotNetFX35SP1 目錄，若是 x64 架構 [Program Files] 請替換成 C:/ProgramFiles(x86)
2. 用「記事本」開啟該目錄下的 Product.xml 文件
3. 將以下片段插入到 <PackageFiles CopyAllPackageFiles=”IfNotHomeSite”> 這行下方：

[html]  view plain  copy

1. <PackageFile Name="TOOLS/clwireg.exe" />  
2. <PackageFile Name="TOOLS/clwireg_x64.exe" />  
3. <PackageFile Name="TOOLS/clwireg_ia64.exe" />  

4.找到<PackageFileName=”dotNetFX30/XPSEPSC-x86-en-US.exe” 這行與 <PackageFile Name=”dotNetFX30/XPSEPSC-amd64-en-US.exe” 這行，並將這兩行的 PublicKey 原本的值改成以下的值 ( 請注意複製的時候不要複製到空白字元 )：

[html]  view plain  copy

1. 3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D526C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD9706D0574476  
2. 5CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E3958977609BE7AD77C1378D33142F  
3. 13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D5074412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F27B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001  

5.將  Product.xml 存檔。

6.將已下載的  .NET Framework 3.5 Service Pack 1 (Full Package) 解壓縮到任意暫存目錄，解壓縮的方法必須透過指令執行：dotNetFx35.exe /x:  （或用WinRAR解压）

7.解壓縮後，該目錄會多出一個WCU目錄，在裡面又會有一個dotNetFramework目錄，請將WCU/dotNetFramework目錄下所有的目錄與檔案都移至 [ProgramFiles]/Microsoft SDKs/Windows/v6.0A/Bootstrapper/Packages/DotNetFX35SP1 目錄下。完成後的圖示如下：

8.如上圖標紅框的部分是  語言包( Language Pack) 的部分，各位在  Visual Studio 2008 SP1 讀我檔案 的  2.3.1. 章節裡也可以下載的到，照著目錄放置下載後的檔案即可。 以  Chinese (Traditional) 為例，檔案下載後的目錄結構會變成以下這樣：  （简体中文目录名是：zh-CHS）

Microsoft .NET Framework 4 自述文件

有关最新版本的自述文件，请单击此处。

1. 系统要求

1.1 支持的体系结构

• x86
• x64
• ia64（有些功能在诸如 Windows Presentation Foundation (WPF) 之类的 ia64 上不受支持）

1.2 支持的操作系统

• Windows XP SP3
• Windows Server 2003 SP2
• Windows Vista SP1
• Windows 7
• Windows Server 2008（在 Server Core 角色上不受支持）
• Windows Server 2008 R2（在 Server Core 角色上不受支持）

1.3 硬件要求

• 最少可用硬盘空间：
  • x86：850 MB
  • x64：2 GB
• 处理器和 RAM：
  • 最低要求：Pentium 1 GHz、512 MB RAM

1.4 其他系统要求

• Windows Installer 3.1
• Internet Explorer 5.01

2. 已知问题

2.1 安装

2.1.1 Full Framework（安装）

2.1.1.1 在安装了 .NET Framework 4 的情况下，修改 .NET Framework 3.5 后无法加载类型“System.ServiceModel.Activation.HttpModule”

此问题可能由下列情况引起：

• 在安装 .NET Framework 4 之后卸载 Windows 2003 Server 和 Windows XP 上的 .NET Framework 3.5。
• 在安装 .NET Framework 4 之后启用 .NET Framework 3.0 WCF HTTP 激活。
• 在安装 .NET Framework 4 之后安装或修复 .NET Framework 3.5。
• 在已安装预发行版本时安装 .NET Framework 4 的当前版本。

错误的完整文本如下：

未能从程序集“System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”加载类型“System.ServiceModel.Activation.HttpModule”。

说明：在执行当前 Web 请求的过程中发生未经处理的异常。 有关错误和代码中发出该错误的位置的更多信息，请查看堆栈跟踪。

解决此问题的方法：

• 在命令提示符处，定位到 %windows%\Microsoft.Net\Framework\<最新版本>\
• 执行下面的命令：aspnet_regiis.exe /iru

2.1.1.2 在 Windows Vista、Windows Server 2008 和 Windows 7 上，卸载 .NET Framework 4 Beta 2 会导致未使用的“isapiCgiRestriction”项保留在 applicationHost.config 文件中

在启用了 IIS 7 或 IIS 7.5 并且已安装 .NET Framework 4 的计算机上，卸载 Beta 2 版本会导致未使用的“isapiCgiRestriction”项保留在 applicationHost.config 文件中。 这种情况出现在 Windows Vista、Windows Server 2008 和 Windows 7 上。未使用的项不会影响 Web 服务器的功能。 较高版本的 .NET Framework 4 可安全地安装在同一台计算机上，因为后续安装将会更新“isapiCgiRestriction”项。

解决此问题的方法：

从 applicationHost.config 文件中删除未使用的“isapiCgiRestriction”项。 但是，由于卸载后留下的这些项并不会影响产品功能或安装较高版本的能力，因此此步骤不是必需的。

2.1.1.3 安装 .NET Framework 4 后无法安装 .NET Framework 1.0

在安装 .NET Framework 4 后无法安装 .NET Framework 1.0。  必须在安装 .NET Framework 4 之前安装 .NET Framework 1.0。

解决此问题的方法：

1. 转到控制面板，打开“程序和功能”。
2. 卸载 .NET Framework 4 Extended。
3. 卸载 .NET Framework 4 Client Profile。
4. 安装 .NET Framework 1.0。
5. 安装 .NET Framework 4。

2.1.1.4 .NET Framework 4 安装程序安装失败

未能安装 .NET Framework 4 安装程序。

解决此问题的方法：

参考 .NET Framework 4 安装程序疑难解答指南 (http://go.microsoft.com/fwlink/?LinkId=186690)

2.1.1.5 卸载 .NET Framework 4 后未彻底删除 Windows Presentation Foundation (WPF) 4 字体缓存服务 (Full Framework)

卸载 .NET Framework 4 后未彻底删除 Windows Presentation Foundation (WPF) 4 字体缓存服务 (Full Framework)。

注意：此问题对 .NET Framework 的 Full Framework 版本和 Client Profile 版本都会产生影响。

解决此问题的方法：

1. 在管理员模式下打开命令窗口。
2. 键入“sc delete WPFFontCache_v0400”

此时应显示“[SC] DeleteService SUCCESS”。

刷新服务控制台后不应显示字体缓存。  如果刷新操作未解决此问题，请重新启动计算机。

2.1.2 Client Profile（安装）

2.1.2.1 安装 .NET Framework 4 Client Profile 后无法安装 .NET Framework 1.0

在安装 .NET Framework 4 Client Profile 后无法安装 .NET Framework 1.0。  必须在安装 .NET Framework 4 Client Profile 之前安装 .NET Framework 1.0。

解决此问题的方法：

1. 转到控制面板，打开“程序和功能”。
2. 卸载 .NET Framework 4 Client Profile。
3. 安装 .NET Framework 1.0。
4. 安装 .NET Framework 4 Client Profile。

2.1.2.2 卸载 .NET Framework 4 后未彻底删除 Windows Presentation Foundation (WPF) 4 字体缓存服务 (Client Profile)

卸载 .NET Framework 4 后可能未彻底卸载 WPF 字体缓存服务。 

尽管 WPF 字体缓存服务在卸载后再也无法使用，但服务控制台中仍会显示“Windows Presentation Foundation 字体缓存 4.0.0.0”服务条目。

在 Windows Vista 和 Windows Server 2008 上，服务控制台“描述”字段将会显示：“<读取描述失败。 错误代码: 2 >”。  在 Windows XP 和 Windows Server 2003 上，“描述”字段仍将会显示正确的字符串。

重新安装 .NET Framework 将会修复此问题。 尚不确定是否还有任何其他影响。

注意：此问题对 .NET Framework 的 Client Profile 版本和 Full Framework 版本都会产生影响。

解决此问题的方法：

1. 在管理员模式下打开命令窗口。
2. 键入“sc delete WPFFontCache_v0400”

此时应显示“[SC] DeleteService SUCCESS”。

刷新服务控制台后不应显示字体缓存。  如果刷新操作未解决此问题，请重新启动计算机。

2.1.2.3 .NET Framework 4 Client Profile 安装程序安装失败

未能安装 .NET Framework 4 Client Profile 安装程序。

解决此问题的方法：

参考 .NET Framework 4 安装程序疑难解答指南 (http://go.microsoft.com/fwlink/?LinkId=186690)

2.2 卸载

2.2.1 Full Framework（卸载）

2.2.1.1 在 Windows Vista、Windows Server 2008 和 Windows 7 上，卸载 .NET Framework 4 Beta 2 会导致未使用的“isapiCgiRestriction”项保留在 applicationHost.config 文件中

在启用了 IIS 7 或 IIS 7.5 并且已安装 .NET Framework 4 的计算机上，卸载 Beta 2 版本会导致未使用的“isapiCgiRestriction”项保留在 applicationHost.config 文件中。 这种情况出现在 Windows Vista、Windows Server 2008 和 Windows 7 上。未使用的项不会影响 Web 服务器的功能。 较高版本的 .NET Framework 4 可安全地安装在同一台计算机上，因为后续安装将会更新“isapiCgiRestriction”项。

解决此问题的方法：

从 applicationHost.config 文件中删除未使用的“isapiCgiRestriction”项。 但是，由于卸载后留下的这些项并不会影响产品功能或安装较高版本的能力，因此此步骤不是必需的。

2.2.1.2 卸载 NET4 后未彻底删除 WPF 4.0 字体缓存服务 (Full Framework)

彻底删除此孤立的字体缓存服务的方法：

1. 在管理员模式下打开命令窗口
2. 输入：“sc delete WPFFontCache_v0400”

此时应显示：  “[SC] DeleteService SUCCESS”。

如果刷新服务控制台，则此时不应显示字体缓存。  如果刷新服务控制台并未解决此问题，则可能需要重新启动。

（注意：此问题适用于 Full Framework，与适用于 Client Profile 的 877240 自述文件问题相同）

解决此问题的方法：

彻底删除此孤立的字体缓存服务的方法：

1. 在管理员模式下打开命令窗口
2. 输入：“sc delete WPFFontCache_v0400”

此时应显示：“[SC] DeleteService SUCCESS”。

如果刷新服务控制台，则此时不应显示字体缓存。  如果刷新服务控制台并未解决此问题，则可能需要重新启动。

2.2.2 Client Profile（卸载）

2.2.2.1 卸载 NET4 后未彻底删除 WPF 4.0 字体缓存服务 (Client Profile)

从 Vista/XP/w2k3/W2k8 卸载 .NET 4.0 之后，未彻底卸载 WPF 字体缓存服务。 

尽管 WPF 字体缓存服务在卸载后再也无法使用，但服务控制台中仍会存在并显示“Windows Presentation Foundation 字体缓存 4.0.0.0”服务条目。

在 Vista 和 W2k8 上，服务控制台“描述”字段将会显示：“<读取描述失败。 错误代码: 2 >”。  在 XP/w2k3 上，“描述”字段仍将会显示正确字符串。

重新安装 Framework 将会修复此问题。 尚不确定是否还有任何其他影响。

注意：Net4 Client Profile 和 NET4 Full Framework 同时存在此问题

解决此问题的方法：

彻底删除此孤立的字体缓存服务的方法：

1. 在管理员模式下打开命令窗口
2. 输入：“sc delete WPFFontCache_v0400”

此时应显示：“[SC] DeleteService SUCCESS”。

如果刷新服务控制台，则此时不应显示字体缓存。  如果刷新服务控制台并未解决此问题，则可能需要重新启动。

（注意：此问题适用于 Client Profile，与适用于 Full Framework 的 888322 自述文件问题相同）。 

2.3 产品问题

2.3.1 一般问题

2.3.1.1 可再发行语言包的位置不正确导致 ClickOnce 发布失败。

如果在“系统必备”对话框中选中“从与我的应用程序相同的位置下载系统必备组件”选项，并选择以下任何组件作为系统必备组件，则当使用简体中文或繁体中文版本的 Visual Studio 2010 发布应用程序时，可能会显示生成错误：

1. Microsoft .NET Framework 4（x86 和 x64）
2. Microsoft .NET Framework 4 Client Profile（x86 和 x64）
3. Microsoft Visual F# Runtime for .NET 2.0
4. Microsoft Visual F# Runtime for .NET 4.0

对于“Microsoft .NET Framework 4 Client Profile（x86 和 x64）”，系统可能会显示下面的生成错误：

“MSB3152: 系统必备的安装位置未设置为‘组件供应商的网站’，无法在磁盘上找到项‘Microsoft .NET Framework 4 Client Profile (x86 和 x64)’中的文件‘DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe’。 有关详细信息，请参见‘帮助’。”

解决此问题的方法：

若要在简体中文版本中解决此问题，请按以下步骤操作：

导航到文件夹“%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client”。 对于 x64 操作系统，该路径位于 %ProgramFiles(x86)% 下。将 zh-Hans 文件夹复制到名为 zh-chs 的新文件夹导航到 zh-chs 文件夹。在管理员模式下打开 Package.xml。按如下方法将 >Culture< 的值更改为 zh-chs：

<String Name=”Culture”>zh-chs</String>

若要在繁体中文版本中解决此问题，请按以下步骤操作：

导航到文件夹“%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client”。 对于 x64 操作系统，该路径位于 %ProgramFiles(x86)% 下。将 zh-Hant 文件夹复制到名为 zh-cht 的新文件夹导航到 zh-cht 文件夹。在管理员模式下打开 Package.xml。按如下方法将 >Culture< 的值更改为 zh-cht：

<String Name=”Culture”>zh-cht</String>

2.3.1.2 ClickOnce 应用程序安装的可再发行语言包不正确。

如果在“系统必备”对话框中选中“从组件供应商的网站上下载系统必备组件”选项，并选择以下任何组件作为系统必备组件，则当使用简体中文或繁体中文版本的 Visual Studio 2010 发布应用程序时，可能会无法安装简体中文或繁体中文语言包：

1. Microsoft .NET Framework 4（x86 和 x64）
2. Microsoft .NET Framework 4 Client Profile（x86 和 x64）
3. Microsoft Visual F# Runtime for .NET 2.0
4. Microsoft Visual F# Runtime for .NET 4.0

解决此问题的方法：

若要在简体中文版本中解决此问题，请按以下步骤操作：

导航到文件夹“%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client”。 对于 x64 操作系统，该路径位于 %ProgramFiles(x86)% 下。将 zh-Hans 文件夹复制到名为 zh-chs 的新文件夹导航到 zh-chs 文件夹。在管理员模式下打开 Package.xml。按如下方法将 >Culture< 的值更改为 zh-chs：

<String Name=”Culture”>zh-chs</String>

若要在繁体中文版本中解决此问题，请按以下步骤操作：

导航到文件夹“%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client”。 对于 x64 操作系统，该路径位于 %ProgramFiles(x86)% 下。将 zh-Hant 文件夹复制到名为 zh-cht 的新文件夹导航到 zh-cht 文件夹。在管理员模式下打开 Package.xml。按如下方法将 >Culture< 的值更改为 zh-cht：

<String Name=”Culture”>zh-cht</String>

2.3.2 ASP.NET

2.3.2.1 在 Windows 7 上安装 .NET Framework 4 之后，无法再在 IIS 7.5 上为各个应用程序池配置 aspnet.config 文件

在运行 Windows 7 并且已启用 IIS 7.5 的客户端或服务器计算机上安装 .NET Framework 4 之后，用于为不同应用程序池配置 ASP.NET 配置文件的选项停止工作。 发生这种情况的原因是，安装 .NET Framework 4 后导致公共语言运行时 (CLR) 初始化的默认行为有了轻微改变。 当安装 .NET Framework 4 时，Windows 7 上的 IIS 7.5 将调入本机 ASP.NET 4 DLL 以执行 CLR 初始化，而此初始化逻辑不允许使用不同的配置文件。

解决此问题的方法：

由于 .NET Framework 4 和 IIS 7.5 的 CLR 初始化逻辑基本相同（配置文件副作用除外），因此您可以重新配置 IIS 7.5，使其不再将 CLR 初始化委托给 ASP.NET 4。可以按以下两种方式执行此操作。

方法 1
----------
在 IIS 7.5 applicationHost.config 文件中，将“managedRuntimeLoader”特性的默认值设置为一个空字符串，如以下示例所示：

<applicationPools>
  <applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>

方法 2
----------
在 IIS 7.5 IIS_Schema.xml 文件中，将名为“managedRuntimeLoader”的特性中的“defaultValue”设置为一个空字符串。 例如，该特性最初可能类似于以下示例： 

<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />

将该特性更改为以下标记：

<attribute name="managedRuntimeLoader" type="string" defaultValue="" />

2.3.2.2 在 Windows XP 和 Windows Server 2003 上注销和重新注册 ASP.NET 4 时，将会导致 IIS MMC 中 ASP.NET 属性选项卡上的 ASP.NET 版本值为空

在 Windows XP 和 Windows Server 2003（所有版本）上，如果您在从 IIS 中注销 ASP.NET 4 后重新注册它，IIS MMC 会在 ASP.NET 选项卡上的 ASP.NET 版本列表中显示空值。 下列步骤序列将导致出现此问题：

1. 使用 aspnet_regiis 的 ASP.NET 4 版本运行“aspnet_regiis -u”
2. 使用 aspnet_regiis 的 ASP.NET 4 版本运行“aspnet_regiis -i -enable”

解决此问题的方法：

在 IIS MMC 的 ASP.NET 版本列表中，手动选择所需的 ASP.NET 版本，然后单击“应用”按钮。

2.3.2.3 Windows Vista、Windows Server 2008 和 Windows 7 上的 ASP.NET 编译任务可能因 IIS 辅助进程没有对 Windows 临时目录的写权限而失败

由于 IIS 辅助进程没有对 Windows 临时目录 (%WINDOWS%\Temp) 的写权限，Windows Vista、Windows Server 2008 和 Windows 7 上的某些 ASP.NET 编译任务可能会失败。 在尝试编译依赖于 WSDL 文件的 Web 服务引用等项目时，您可能会看到诸如“分析器错误消息: 无法生成临时类”这样的错误。
 
如果计算机上启用了 IIS 并且安装了 .NET Framework 4，但尚未启用 ASP.NET 和 .NET 扩展性的功能，则会出现此错误。

解决此问题的方法：

方法 1
----------
为 IIS 辅助进程帐户显式授予对于 Windows 临时目录 (%WINDOWS%\Temp) 的写权限。 执行此操作的一种方法是，对一个包含辅助进程帐户的组（如 IIS_IUSRS 组）授予写访问权限。
 
方法 2
---------
启用 ASP.NET 和 .NET 扩展性的功能。 在 Windows 的“控制面板”中打开“程序”，然后在“程序和功能”下单击“打开或关闭 Windows 功能”。 在“Windows 功能”对话框中，依次打开“Internet Information Services”、“万维网服务”和“应用程序开发功能”节点。 启用以下功能：

     .NET 扩展性
     ASP.NET

2.3.2.4 以部分信任运行网站时，尝试加载在 GAC 中部署的预编译的 Web 程序集会失败并引发“SecurityException”异常

可以通过使用 aspnet_compiler.exe 命令行工具来预编译 ASP.NET 网站。 如果使用密钥对生成的程序集进行签名，则可以在 GAC 中而不是网站的 Bin 文件夹中部署这些程序集。

在 ASP.NET 4 中，如果以部分信任运行的网站尝试从 GAC 中加载程序集，则将引发“System.Security.SecurityException”异常。 出现这种情况的原因是，默认情况下 ASP.NET 4 使用比早期版本的 ASP.NET 新的代码访问安全性 (CAS) 实现。 在新的 CAS 实现中，必须使用“SecurityTransparent”特性显式标记在 GAC 中部署的预编译和经签名的程序集。

解决此问题的方法：

方法 1
--------
在编译程序集之前，先使用“SecurityTransparent”特性对其进行标记，如以下示例所示：

[assembly:System.Security.SecurityTransparentAttribute]

方法 2
--------
按照“如何：为预编译网站创建带有版本的程序集”(http://msdn.microsoft.com/en-us/library/ms228042.aspx) 一文所述，向网站的 Web.config 文件中添加“compilerOptions”设置。 作为此过程的组成部分，将下面的行添加到“compilerOptions”设置所引用的 AssemblyInfo.vb 或 AssemblyInfo.cs 文件中：

[assembly:System.Security.SecurityTransparentAttribute]

方法 3
--------
创建一个包含以下特性的虚拟类库：

[assembly:System.Security.SecurityTransparentAttribute]

将该类库编译到某个程序集，然后使用“copyattrs”选项对预编译网站输出运行 aspnet_merge.exe 命令行工具，如以下示例所示：

aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll

对于 DLL 名称，使用通过“SecurityTransparent”特性标记的虚拟类库的名称。

方法 4
--------
通过在网站的 Web.config 文件中将“trust”元素的“legacyCasModel”特性设置为“true”，临时恢复为旧的 CAS 模式，如以下示例所示：

<trust level="Medium" legacyCasModel="true"/>

在做出了此更改之后，建议您使用其他选项之一将“SecurityTransparent”特性添加到预编译的程序集。 然后，可以移除“legacyCasModel”特性并在新的 CAS 模式下运行网站。

2.3.2.5 ASP.NET 和 WCF 应用程序可能无法在 IIS 7 集成模式下启动

如果将新配置节添加到 ASP.NET 或 Windows Communication Foundation (WCF) 应用程序的 Web.config 应用程序文件，则启动在 IIS 7 集成模式下运行的应用程序将失败。

例如，如果将 <standardEndpoints> 配置节添加到 WCF 应用程序的 Web.config 文件中，则将不会启动在 IIS 7 集成模式下运行的应用程序。 而 IIS 7 将返回一个配置验证错误，因为 IIS 7 配置系统无法识别新的配置节。

解决此问题的方法：

针对此问题下载并安装一个公开提供的修补程序。 http://support.microsoft.com/kb/958854 提供了此修补程序。 或者，您也可以安装包含该修补程序的 Windows Vista SP 2。  Windows 7 和 Windows Server 2008 R2 没有此问题，因为这些操作系统已包含了必需的修补程序。

2.3.2.6 可能需要在 Windows Vista、Windows Server 2008、Windows 7 和 Windows Server 2008 R2 上重新注册 ASP.NET 4

在计算机上安装了 .NET Framework 4 之后，如果启用 IIS 7/7.5 或 IIS7/7.5 .NET 扩展性功能，则必须重新注册 ASP.NET 4。 当计算机上安装有 .NET Framework 4 时，如果移除 .NET 扩展性功能，也必须重新注册 ASP.NET 4。

对于以上两种情况，重新注册是必需的，因为对于计算机上已存在更高版本的 .NET Framework 这一情况，没有设计针对 IIS7 和 IIS 7.5 以及 .NET 扩展性功能的操作系统安装和卸载过程。

解决此问题的方法：

若要重新注册 ASP.NET 4，请运行下面的命令：

          aspnet_regiis -iru -enable 

确保使用安装在 .NET Framework 4 安装目录中的 aspnet_regiis.exe 版本。

2.3.2.7 管理远程 Web 服务器时可能不显示 ASP.NET 管理控制台 (MMC) 选项卡

如果您在管理远程 Web 服务器时在本地计算机上运行管理控制台 (MMC)，则可能不会显示 ASP.NET 选项卡。 当您使用 IIS 6 管理工具远程管理已安装 ASP.NET 的 Web 服务器时，如果本地计算机正在运行 Windows Server 2008 x64、Windows 7 或 Windows Server 2008 R2（x86 或 x64），则会发生此情况。

解决此问题的方法：

没有解决方法。

2.3.2.8 运行 ASP.NET 2.0 版的“aspnet_regiis -ua”时无法注销包括 ASP.NET 4 在内的其他版本的 ASP.NET

在 Windows Vista、Windows Server 2008、Windows 7 或 Windows Server 2008 R2 上运行 ASP.NET 2.0 版的“aspnet_regiis -ua”命令将导致出现以下错误： 

          不支持该请求。

出现此错误的原因是，ASP.NET 2.0 版的“aspnet_regiis”命令无法检测计算机上是否存在更高版本的 ASP.NET。

解决此问题的方法：

运行 ASP.NET 4 版的“aspnet_regiis -ua”命令以注销计算机上的 ASP.NET 的所有版本。

2.3.2.9 在 Windows Server 2003 上运行“aspnet_regiis -i”不会以递归方式强制将虚拟目录升级到 ASP.NET 4

对于 ASP.NET 2.0，“aspnet_regiis -i”命令以递归方式升级 Windows Server 2003 上的所有虚拟目录以使用 ASP.NET 2.0。 对于 ASP.NET 4，Windows Server 2003 上的“aspnet_regiis -i”命令只将 IIS 6 的根目录升级到 ASP.NET 4。如果将根目录下的任何虚拟目录显式设置为运行特定版本的 ASP.NET，则这些虚拟目录将保留显式设置的 ASP.NET 版本，而不是从根目录继承 ASP.NET 4 设置。

解决此问题的方法：

运行 ASP.NET 4 版本的以下任一命令：

          aspnet_regiis -s

          aspnet_regiis -r

这些命令强制按递归方式将所有虚拟目录更新为 ASP.NET 4。

2.3.2.10 注销 ASP.NET 2.0 后中断 ASP.NET 4 性能计数器

在已注册 ASP.NET 4 的任一操作系统版本上注销 ASP.NET 2.0 都会损坏 ASP.NET 4 的某些性能计数器注册。发生此情况的原因是，ASP.NET 2.0 注销过程无法检测计算机上是否安装有更高版本的 ASP.NET。 因此，当您使用 ASP.NET 4 的某些性能计数器时，应用程序事件日志中可能会显示类似下面的错误： 

          “无法在‘ASP.NET’服务的 DLL‘"%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll’中定位打开过程‘%pef_counter_name%’。”

          “‘ASP.NET’服务的性能计数器数据集合已禁用。原因是该服务的性能计数器库产生一个或多个错误。”

解决此问题的方法：

运行 ASP.NET 4 版的“aspnet_regiis -iru”命令。  这将重新注册 ASP.NET 4 性能计数器。

2.3.2.11 SQL Server Express 用户实例不适用于 IIS 6 或 IIS 7 下的 Web 应用程序项目或 IIS 7.5 下的应用程序

默认情况下，依赖于 SQL Server Express 用户实例的 ASP.NET 4 Web 项目和 Web 应用程序在以下情形下不适用：

1. Web 应用程序项目 (WAP) 作为虚拟目录承载于任一版本的 IIS 上。  这是因为 SQL Server Express 用户实例需要对用户的 Documents 文件夹的特定文件权限，但默认 IIS 服务帐户 (NETWORK SERVICE) 没有这些权限。
2. 网站承载于在 Windows 7 或 Windows Server 2008 R2 上运行的 IIS 7.5 中。 这是因为用于 IIS 7.5 应用程序池的默认安全凭据并不基于 NETWORK SERVICE。

解决此问题的方法：

有关如何解决这些问题的详细信息，请参见以下位置的文章：  

          http://go.microsoft.com/fwlink/?LinkID=160102

2.3.2.12 当应用程序级 Web.config 文件中存在相关节时 ASP.NET 4 或 IIS 7 引发配置错误

在 ASP.NET 4 中，已大大减少了默认 Web.config 文件的大小。 因此，IIS 7（在 Windows Vista 和 Windows Server 2008 上）和 IIS 7.5（在 Windows Server 2008 R2 上）将引发配置错误。 确切的错误取决于操作系统上已安装的更新和应用程序级 Web.config 文件中包含的配置信息的类型。

既未安装修补程序 KB958854 也未安装 SP2 的 Windows Vista SP1 或 Windows Server 2008 SP1。 在此配置中，IIS 7 配置系统通过比较应用程序级 Web.config 文件与 ASP.NET 2.0 machine.config 文件，错误地合并应用程序的托管配置。 为此，.NET Framework 3.5 或 .NET Framework 4 中的应用程序级 Web.config 文件必须具有一个 <system.web.extensions> 配置节，这样才不会导致 IIS 7 验证失败。  未精确匹配随 Visual Studio 2008 引入的原始样板配置节定义的手动修改的应用程序级 Web.config 文件项将导致出现配置错误。 （由 Visual Studio 2008 生成的默认配置项将起作用。） 常见的问题是：手动修改的 Web.config 文件会遗漏各种配置节定义中的配置特性“allowDefinition”和“requirePermission”。 因此，应用程序级 Web.config 文件中的简略配置节与 ASP.NET 4 machine.config 文件中的完整定义不匹配。 因此在运行时，ASP.NET 4 配置系统将引发配置错误。

安装有修补程序 KB958854 的 Windows Vista SP2、Windows Server 2008 SP2、Windows 7、Windows Server 2008 R2 以及 Windows Vista SP1 和 Windows Server 2008 SP1。 在这种情况下，IIS 7 和 IIS 7.5 本机配置系统会返回配置错误，因为该系统会针对为托管配置节处理程序定义的“type”特性执行文本比较。 因为由 Visual Studio 2008 和 Visual Studio 2008 SP1 生成的所有 Web.config 文件在 <system.web.extensions> 及相关配置节的类型字符串中都显示“3.5”，并且 ASP.NET 4 machine.config 文件在相同配置节的“type”特性中显示“4.0”，所以在 Visual Studio 2008 或 Visual Studio 2008 SP1 中生成的应用程序在 IIS 7 和 IIS 7.5 中的配置验证总是会失败。

解决此问题的方法：

对于第一种情况，通过包括 Visual Studio 2008 自动生成的 Web.config 文件中的样板配置文本，更新应用程序级 Web.config 文件。

对于第二种情况，从应用程序级 Web.config 文件中删除或注释掉所有 <system.web.extensions> 配置节定义和配置节组定义。

2.3.2.13 未曾向 System.Web.Hosting.IProcessHostPreloadClient.Preload 方法传递过任何参数数据

System.Web.Hosting.IProcessHostPreloadClient.Preload 方法采用一个字符串数组作为输入参数。 但无法设置此数据，并且未曾在此参数中传入任何信息。

解决此问题的方法：

早期的预览版 IIS 7.5 自动启动功能支持这样一种方法，即配置一个或多个字符串值以传入 ASP.NET 4 IProcessHostPerloadClient.Preload 方法。 但是，在最终发行 Windows 7 和 Windows Server 2008 R2 之前，已经移除了这一功能。

2.3.2.14 Windows Vista、Windows Server 2008、Windows 7 和 Windows Server 2008 R2 上的 IIS7/IIS7.5 .NET 扩展性功能未与 ASP.NET 4 集成

IIS 7 和 IIS 7.5 .NET 扩展性功能是“Windows 功能”对话框中提供的一个配置选项，用于安装或卸载 IIS 7 或 IIS 7.5 功能。 该功能位于下面的节点中：

Internet Information Services  > 万维网服务  > 应用程序开发功能  > .NET 扩展性 

在 Windows Vista、Windows Server 2008、Windows 7 和 Windows Server 2008 R2 上，.NET 扩展性功能只影响 ASP.NET 2.0 与 IIS 7 或 IIS 7.5 的集成。 它对在 IIS 7 或 IIS 7.5 中注册或注销 ASP.NET 4 没有影响。

解决此问题的方法：

若要管理 ASP.NET 4 与 IIS 7 或 IIS 7.5 的集成，请使用 ASP.NET 4 版的“aspnet_regiis.exe”命令。

2.3.2.15 运行在 IIS 6 上的 ASP.NET 2.0 应用程序可能生成类似“未能找到 System.Web.HttpException: Path '/[您的应用程序根]/eurl.axd/[值]'。”的错误

运行在 IIS 6 上的 ASP.NET 2.0 应用程序（在 Windows Server 2003 或 Windows Server 2003 R2 中）可能会生成类似下面的错误：

未能找到 System.Web.HttpException: Path '/[您的应用程序根]/eurl.axd/[值]'。

只在 IIS 6 上启用了 ASP.NET 4 之后才会出现此错误。出现此错误的原因是，当 ASP.NET 检测到某个网站配置为使用 ASP.NET 4 时，ASP.NET 4 的本机组件就会将无扩展名的 URL 传递给 ASP.NET 的托管部分进行进一步处理。

但是，如果将某个 ASP.NET 4 网站下的虚拟目录配置为使用 ASP.NET 2.0，则按这种方式处理无扩展名的 URL 将产生包含“eurl.axd”的修改后的 URL，该 URL 随后将发送给 ASP.NET 2.0 应用程序。 ASP.NET 2.0 无法识别“eurl.axd”格式。  因此，ASP.NET 2.0 将尝试找到一个名为“eurl.axd”的文件并执行该文件。  由于没有此类文件存在，因此请求将失败，并出现“HttpException”异常。

解决此问题的方法：

方法 1
--------
如果 ASP.NET 4 不是为了运行网站所必需的，请改为将网站重新映射为使用 ASP.NET 2.0。

方法 2
---------
如果需要 ASP.NET 4 才能运行网站，请将所有 ASP.NET 2.0 子虚拟目录移动到映射到 ASP.NET 2.0 的其他网站。

方法 3
---------
如果将网站重新映射到 ASP.NET 2.0 或更改虚拟目录的位置不可行，则在 ASP.NET 4 中显式禁用无扩展名的 URL 处理功能。请使用下面的过程：

1. 在 Windows 注册表中，打开下面的节点: 

     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.<build#>   

 注意：<build#> 是 .NET Framework 4 发行版的内部版本号。

2. 创建一个名为“EnableExtensionlessUrls”的 DWORD 值。

3. 将“EnableExtensionlessUrls”设置为 0。这将禁用无扩展名的 URL 的行为。

4. 保存注册表值并关闭注册表编辑器。

5. 运行“iisreset”命令行工具，这将导致 IIS 读取新的注册表值。

 注意：将“EnableExtensionlessUrls”设置为 1 后将禁用无扩展名的 URL 的行为。 这是未指定值时的默认设置。

2.3.2.16 使用 Entity Framework 并且是通过使用 ASP.NET 4 预发行版创建的网站因缺少程序集引用的缘故而停止工作

使用 Entity Framework 的 Web 项目所需的对命名空间和程序集的引用已从 RTM 版的 Web.config 根文件中移除。 因此，使用 EntityDataSource 的动态数据网站以及使用通过 ASP.NET 4 预发行版创建的 Entity Framework 的 Web 应用程序将失败并报告编译错误。

解决此问题的方法：

您可以将缺少的程序集和命名空间引用插入到应用程序的 Web.config 文件中。 下面的示例演示了必须手动插入到应用程序级 Web.config 文件中的程序集和命名空间元素。

<system.web>

<compilation>
        <assemblies>
            <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Web.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
            <add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Data.Entity.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />              
        </assemblies>
    </compilation>

    <pages>
        <namespaces>
            <add namespace="System.Data.Entity.Design" />
            <add namespace="System.Data.Linq" />
        </namespaces>
    </pages>

</system.web>

2.3.2.17 以集成模式在 IIS 7 或 IIS 7.5 上运行的预发行版的 ASP.NET 4 可能报告从 RoleManagerModule 类引发的未经处理的 NullReferenceException 错误

在 Windows Vista、Windows Server 2008、Windows 7 和 Windows Server 2008 R2 上按照某些顺序安装 .NET Framework 版本 2.0 和版本 4 之后，ASP.NET 4 应用程序从 RoleManagerModule 类引发未经处理的 NullReferenceException 错误。 如果 ASP.NET 4 是向 IIS 7 或 IIS 7.5 注册的唯一的 ASP.NET 版本，并且 ASP.NET 2.0 从未注册到 IIS，或 ASP.NET 2.0 已从 IIS 7 或 IIS 7.5 中注销，则会发生此情况。

在任一情况下，ASP.NET 4 的独立注册将导致配置文件中用在集成模式应用程序中的两个 HTTP 模块顺序不正确。

解决此问题的方法：

尽管 ASP.NET 4 发布版本中会修复此错误，但是预发行版的 ASP.NET 4 可能已为模块指定错误的顺序。 如果在已从 ASP.NET 4 预发行版升级到 RTM 版本的计算机上仍发生该未经处理异常，则请执行以下步骤：

1.  打开 applicationHost.config 文件，该文件位于下面的文件夹中：

%windir%\System32\inetsrv\config

2. 查找以下元素

<location path="" overrideMode="Allow">

在此元素中列出集成模式针对的 HTTP 模块。 相关信息位于 <modules> 元素中。

3. 找到以以下字符串开头的元素：

<add name="RoleManager"  ...

4. 将该元素移到以以下字符串开头的元素下面：

<add name="DefaultAuthentication"...

5. 保存该文件。

完成此操作后，<modules> 定义的一部分应类似于下面的示例：

<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />

2.3.2.18 使用 URL 路由的 MVC 2 和 ASP.NET 4 Web 窗体应用程序尝试在 IIS 7 和 IIS 7.5 上处理无扩展的 URL 时可能返回 HTTP 404 错误

使用无扩展的 URL 的 MVC 2 和 ASP.NET 4 Web 窗体应用程序在 Windows Vista、Windows Server 2008、Windows 7 或 Windows Server 2008 R2 上运行时可能会返回 HTTP 404 错误。 如果只有 .NET Framework 扩展性选项处于打开状态，而且 IIS 是通过“Windows 功能”对话框安装的，则会发生此情况。 最小安装的 IIS 将不包含某些 HTTP 模块。 由于 ASP.NET 和 IIS 管理 HTTP 管道事件转换的方式不同，缺少的 HTTP 模块将阻止 ASP.NET URL 路由模块在合适的时间运行。 因此，URL 路由模块不会处理对无扩展的 URL 的请求，404 错误将发生。

解决此问题的方法：

在 Windows“控制面板”中“程序和功能”应用程序的“打开或关闭 Windows 功能”对话框中， 
执行以下步骤：

1. 导航至以下节点：

“Internet Information Services”-->“万维网服务”-->“常见 HTTP 功能”

2. 确保选中“HTTP 错误重定向”选项。

- 或 -

1. 导航至以下节点：

“Internet Information Services”-->“万维网服务”-->“性能功能”

2. 确保选中“静态内容压缩”选项。

在选定以上任一选项后，请单击“确定”以保存更改。

重新启用 HTTP 错误重定向模块或静态内容压缩模块可确保 ASP.NET 和 IIS 正确同步 HTTP 管道事件。 这样，URL 路由模块就能够处理无扩展的 URL。

2.3.2.19 System.Web.Mobile.dll 已从 Web.config 根文件中移除

在早期版本的 ASP.NET 中，对 System.Web.Mobile.dll 程序集的引用包括在 Web.config 根文件的 <system.web><compilation> 下的 <assemblies> 部分中。 为了提高性能，移除了对此程序集的引用。

解决此问题的方法：

System.Web.Mobile.dll 程序集包括在 ASP.NET 4 中，但被弃用。 如果要使用 System.Web.Mobile.dll 程序集中的类型，请在 Web.config 根文件或 Web.config 应用程序文件中添加对此程序集的引用。 例如，如果要使用任何弃用的 ASP.NET 移动控件，您必须在 Web.config 文件中添加对 System.Web.Mobile.dll 程序集的引用。

2.3.2.20 已对浏览器定义文件和浏览器功能做出更改

已更新浏览器定义文件以包含有关新增和更新的浏览器和设备的信息。 已移除类似 Netscape Navigator 的较旧的浏览器和设备，并且已添加诸如 Google Chrome 和 Apple iPhone 等较新的浏览器和设备。

解决此问题的方法：

您可以将旧的浏览器定义文件用于 ASP.NET 4。旧的浏览器定义文件以及用于安装这些文件的文档包含在 http://go.microsoft.com/fwlink/?LinkID=186493 上发布的“ASP.NET 浏览器定义文件”中。

2.3.2.21 ScriptManager.EnableCdn 和本地化的 Microsoft Ajax 文件

本地化版本的 Microsoft Ajax JavaScript 文件（如 MicrosoftAjax.debug.ja.js）将不会添加到 Microsoft Ajax 内容传递网络 (CDN)，直至发布 .NET Framework 4 的本地化版本。 因此，当您使用本地化版本的 .NET Framework 和 CDN，请不要启用 ScriptManager.EnableCdn 属性。

解决此问题的方法：

等待发布本地化版本的 .NET Framework 4，然后再使用 Microsoft Ajax 内容传递网络 (CDN)。 在此之前，请确保您的应用程序中的 ScriptManager 控件未设置 EnableCdn="true"。

2.3.2.22 常规 ASP.NET 性能计数器只报告来自 ASP.NET 4 应用程序的数据

在安装 ASP.NET 4 之后，常规 ASP.NET 性能计数器将仅报告来自 ASP.NET 4 应用程序的数据。  如果将常规性能计数器用于 ASP.NET 1.1、ASP.NET 2.0 和 ASP.NET 3.5 应用程序，则性能计数器将不会报告任何数据。  运行早期版本的 ASP.NET 的应用程序的性能数据必须使用版本化的 ASP.NET 性能类别。

ASP.NET 的常规性能计数器包含以下性能计数器类别：  “ASP.NET”和“ASP.NET 应用程序”。

版本化的 ASP.NET 性能类别的名称类似于“ASP.NET v2.0.50727”和“ASP.NET Apps v2.0.50727”。

解决此问题的方法：

此行为是设计使然。  计算机上安装的最新版的 ASP.NET“拥有”常规性能计数器类别。  因此，当您从运行不同版本的 ASP.NET 的多个 ASP.NET 应用程序中收集性能数据时，建议您使用版本化的性能计数器类别。

2.3.3 Winforms

没有已知问题。

2.3.4 并行编程

没有已知问题。

2.3.5 Managed Extensibility Framework

没有已知问题。

2.3.6 Entity Framework

没有已知问题。

2.3.7 LINQ to SQL

没有已知问题。

2.3.8 Windows Communication Foundation (WCF)

2.3.8.1 在升级 Client Profile 后启动服务或重置 IIS 时出现“系统找不到指定的文件”错误

在将 .NET Framework 4 从 Beta 2 升级到 RTM 版本之后，当您启动服务或重置 IIS 时可能会发生以下错误：

“系统找不到指定的文件”

解决此问题的方法：

在控制面板的“程序”应用程序中修复 .NET Framework Client Profile。

2.3.9 Windows Presentation Foundation (WPF)

2.3.9.1 ia64 不支持 Windows Presentation Foundation (WPF)

ia64 计算机未安装或不支持 WPF 程序集。

解决此问题的方法：

没有解决方法。 不能在 ia64 上使用 WPF。

2.3.10 Windows Workflow Foundation (WF)

2.3.10.1 工作流验证不支持 sizeof 运算符

当验证包含 sizeof 运算符的工作流时，将会引发异常。

解决此问题的方法：

不要在工作流中使用 sizeof 运算符。

2.3.11 Client Profile（产品）

2.3.11.1 ia64 不支持 .NET Framework 4 Client Profile

ia64 不支持 .NET Framework 4 Client Profile。

解决此问题的方法：

如果在 ia64 上卸载 .NET Framework 4，请务必同时卸载 Full Framework 版本和 Client Profile 版本。

3. 相关链接

• Microsoft 感谢下列与我们一起帮助保护客户的人员：

              * Jeroen Frijters

• 若要查看要升级到 .NET Framework 4 的 ASP.NET 开发人员可能会进行的重大更改的列表，请参见：http://go.microsoft.com/fwlink/?LinkID=186526。 此列表随着新问题的发现而不断得到更新。

 

© 2010 Microsoft Corporation。 保留所有权利。

使用条款  | 商标  | 隐私声明