本文列出了使用 Microsoft Visual Studio 2005 时可能遇到的问题。有关与安装产品相关的问题，请参考 readme.htm。
有关最新的已知问题，请参见联机 Visual Studio 2005 已知问题，网址为：http://go.microsoft.com/fwlink/?LinkId=51326
2. .NET Framework
2.1 运行时没有正确显示 DBCS（双字节字符集）的手动测试文件
当运行名称为 DBCS 的手动测试文件时，您将看到手动测试结果窗口。然而，手动测试没有在该窗口中正确显示。如果您右击该窗口的下半部分并选择“刷新”，该部分将挂起几分钟，然后变成空白。
解决此问题的方法
用 SBCS（单字节字符集）命名手动测试文件。如果需要，您可以在手动测试的说明中使用“DBCS”。
2.2 在运行 32 位 Visual Studio 2005 和 SQL Server 2005 的 64 位计算机上启动了 msvsmon.exe 的错误版本
当 64 位计算机上安装了 Visual Studio 2005 (x86) 和 SQL Server 2005 (x86) 时，SQLCLR 调试会失败。将显示以下消息：
---------------------------
Microsoft Visual Studio
---------------------------
无法调试 .NET 代码。未能附加到“<计算机名>”上的 SQL Server 进程。Visual Studio 远程调试监视器 (MSVSMON.EXE) 的 64 位版本无法调试 32 位进程或 32 位转储。请改用 32 位版本。
---------------------------
确定
---------------------------
msvsmon.exe 的 64 位版本将自动运行，因为计算机的操作系统是 64 位的。应当启动 32 位版本，因为两个应用程序都是 32 位的。这是一个结构问题，目前无法解决。
解决此问题的方法
当试图在本地计算机上进行 SQLCLR 调试时，用户可以手动启动 32 位版本的 msvsmon.exe。
建议您不要将 32 位版本的 msvsmon.exe 注册为自动启动，因为这将中断其他 64 位调试方案。
2.3 AuthorizationStoreRoleProvider：从授权管理器返回不正确或不明确的错误
AuthorizationStoreRoleProvider 依赖于授权管理器。不是所有从授权管理器返回的错误信息都指出了问题的根本原因。以下列出的是已知不正确或不明确的错误信息。
“COMException (0x8007052b)：无法更新密码。提供作为当前密码的值不正确。”
此错误实际上是拒绝访问错误。如果所有以下条件都符合，将发生此错误：ASP.NET 在 IIS 5.0、Windows XP IIS 5.1 上部署或以 IIS 5.0 模式在 Windows Server 2003 上部署，应用程序被配置为使用集成 Windows 身份验证，并且策略文件位于当前 ASP.NET 应用程序的目录结构内。如果 ASP.NET 作为本地计算机帐户运行并尝试访问远程 AD 或 ADAM 实例中的策略存储，也会发生此错误。
“更多数据可用”
此错误实际上意味着无法找到策略存储。如果连接字符串指向 ADAM 实例，但连接字符串引用的 ADAM 分区不存在，可能发生此错误。例如，在下面的连接字符串“LDAP://localhost:4000/Cn=storename, DC=Partition1”中，如果 ADAM 实例中不存在 Partition1，将发生此错误。
“指定的服务器无法运行请求的操作”
此错误实际上意味着无法找到指定的服务器。如果连接字符串指向不存在的服务器或使用 AD 或 ADAM 没有侦听的端口号，可能发生此错误。
“ArgumentException：此参数不正确”
此错误信息实际上表示授权管理器中用于确定用户是否处于某一角中的 LDAP 查询组无效。
解决此问题的方法
对于上面列出的每种错误情况，检查可能的原因。如果应用程序的配置匹配其中一种可能的原因，根据上面列出的信息更改或修复应用程序的配置。
2.4 应该在共享宿主计算机上禁用 SQL Server Express 用户实例
ASP.NET 2.0 集成了 SQL Server Express 2005 以自动创建 ASP.NET 2.0 的许多新应用程序服务所需的数据库。此功能依赖于 SQL Server Express 对生成服务器进程的支持，这些进程使用交互式用户标识或 ASP.NET 的宿主辅助进程标识运行。在不受信任的环境中，如共享宿主服务器上，不要启用生成 SQL Server 辅助进程的能力，因为这样可能会不小心在 ASP.NET 应用程序之间共享数据。
解决此问题的方法
如果使用独立的安装程序安装 SQL Server Express，可以使用高级安装选项显式禁用用户实例支持。
或者，可以手动禁用现有 SQL Server Express 安装的用户实例，如下所示：
1. 以本地框管理员身份登录，运行 cmd.exe 以打开命令窗口。
2. 如果 PATH 环境变量列出的所有目录中都不存在 osql.exe，将目录更改到包含 osql.exe 的 SQL Server Express 目录。
3. 连接到 SQL Server 的父实例：osql –E –S ."sqlexpress
4. 发出以下 Sql 命令：
exec sp_configure \'show advanced option\', \'1\'
go
reconfigure with override
go
exec sp_configure \'user instances enabled\', 0
go
reconfigure with override
go
2.5 Forms 身份验证的持久性 Cookie 现在和基于会话的 Cookie 使用相同的超时设置
在 ASP.NET 的早期版本中，持久性 Forms 身份验证 Cookie 有 50 年的硬编码生存期。在 ASP.NET 2.0 中，持久性 Forms 身份验证 Cookie 将到期日期设置为当前日期时间加上配置中的“timeout”属性值。默认情况下，这意味着持久性 Cookie 将有 30 分钟的生存期。如果希望有更长的生存期，需要增加“timeout”属性的值。在 ASP.NET 2.0 中，这意味着存储在基于会话的 Cookie 和持久性 Cookie 中的 Forms 身份验证票证将使用新的超时值
解决此问题的方法
如果持久性 Cookie 需要不同的超时值，开发人员在最初使用类似 FormsAuthentication.SetAuthCookie 的方法设置 Forms 身份验证 Cookie 后，可以获取对该 Cookie 的引用。开发人员可通过下面的调用获取对该 Cookie 的引用：Response.Cookies[FormsAuthentication.FormsCookieName]。在产生的 HttpCookie 中，开发人员可以将 Expires 属性设置为不同的值。
2.6 AuthorizationStoreRoleProvider 的 DeleteRole 方法的行为不正确
如果试图删除不存在的角色，提供程序的 DeleteRole 方法将错误地引发异常“找不到元素”。相反，提供程序应返回 false。同样，如果试图删除包含现有用户的角色，提供程序将返回 false 而不是引发异常。
解决此问题的方法
1. 将提供程序的所有 DeleteRole 方法调用都包装在 try-catch 块内。这可确保如果将来的修复程序在删除填充的角色时重新引发异常，不会影响现有代码。
2. 在尝试删除角色之前，检查角色是否已存在。
2.7 当使用 Xml 序列化和非默认应用程序标识时，ASP.NET 配置文件功能可能失败
ASP.NET 配置文件功能的默认属性序列化机制是 Xml 序列化。如果 ASP.NET 进程标识既不是 ASPNET（在 IIS 5.0 和 IIS 5.1 上）也不是 NETWORK SERVICE（对于 IIS 6），则 Xml 序列化进程将失败并显示异常“InvalidOperationException：无法生成临时类”。如果使用应用程序模拟，将出现同样的问题。由于 XmlSerializer 将临时类文件写入 %windir%"temp 目录，所以会发生这些异常。默认情况下，此目录仅将“列出文件夹/读取数据”权限授予默认的 ASP.NET 帐户。非默认 ASP.NET 帐户可以将临时文件写入此目录，但是没有随后查找 XmlSerializer 使用的临时类所需的权限。
解决此问题的方法
对于安全环境，开发人员应使用其他序列化机制，二进制序列化或字符串序列化。对于在应用程序间意外共享临时类文件的可能性不大的应用，可以给辅助进程或应用程序模拟标识授予 %windir%"temp 目录的“列出文件夹/读取数据”权限。
2.8 使用 SSE 时的 ASP.NET 会话状态限制
由于 Sql Server 代理服务不会随 SSE 一起安装，因此只有在会话状态基于 ASP.NET Sql Server 的开发环境中才应使用 SSE。正因为如此，会话状态清除作业从不运行，会话状态数据将累积在数据库中。可以通过连接到 SSE 并运行以下命令，手动清除过期会话：“EXECUTE DeleteExpiredSessions”。
解决此问题的方法
在生产应用中使用一个标准的 Sql Server 2005 版本。
2.9 AuthorizationStoreRoleProvider：ApplicationName 的默认值导致授权管理器返回错误
授权管理器不允许在应用程序名中使用“/”字符。如果配置中缺少 applicationName 的设置，AuthorizationStoreRoleProvider 将按照其他 ASP.NET 提供程序所使用的相同逻辑来确定 applicationName 的默认值。当在 ASP.NET 中运行时，这将产生以“/”字符开头的值。
解决此问题的方法
在 ASP.NET 应用程序中使用 AuthorizationStoreRoleProvider 时，始终在配置中设置 applicationName 属性。
2.10 在 Windows 98 和 Windows ME 上，调试使用 Web 服务的应用程序导致该应用程序挂起
在 Visual Studio 2005 中，当在 Windows 98 或 Windows ME 上调试使用 Web 服务的应用程序时，应用程序将会挂起。
解决此问题的方法
禁用调试器组件 csm.dll，使用断点在 Web 服务中停止。
要禁用 csm.dll，请按照以下说明执行：
1} 在 Windows“开始”菜单上，选择“运行”。
2) 在“运行”对话框中，键入“regedit.exe”。
3) 转到 HKEY_CLASSES_ROOT"CLSID"{12A5B9F0-7A1C-4FCB-8163-160A30F519B5}。
4) 通过检查 InprocServer32"(default) 的值是否为“<drive>:"Program Files"Common Files"Microsoft Shared"VS7Debug"csm.dll”，确认是否位于正确的注册表项上。
5) 删除注册表项 (HKEY_CLASSES_ROOT"CLSID"{12A5B9F0-7A1C-4FCB-8163-160A30F519B5})。
2.11 C# 代码段快捷方式不能包含无空格标记
C# 代码段在 .snippet 文件中以 XML 形式定义。一种可能的架构标记是 <Shortcut></Shortcut> 标记。可以使用快捷方式快速插入代码段。为此，用户只需键入快捷方式字符串然后按 Tab。
快捷方式字符串中允许使用许多 Unicode 字符，但复杂脚本语言中存在的无空格标记不被识别为有效的快捷方式字符。这意味着复杂脚本语言中的某些字符串不能用作快捷方式。如果快捷方式中包含无空格 标记，则在键入快捷方式字符串并按 Tab 时，将插入制表符而不是插入代码段代码。
注意：代码段快捷方式仍将出现在 IntelliSense 中。
解决此问题的方法
1. 选择一个不包含无空格标记的 Unicode 快捷方式名称。
2. 通过代码段选择器用户界面（而不是使用快捷方式）插入代码段。
2.12 System.Net 已删除了此逻辑：当超时值小于非托管 API 中由 System.Net 调用以执行解析的超时值时，使 DNS 解析超时
在以前的 .NET Framework 版本中，System.Net 的 DNS 向 DNS 类型中添加超时逻辑以避开过长的本机超时时间。如果没有精确的 DNS 超时时间，就不可能为其他 Web 请求设置精确的超时时间。但是，为实现此超时，DNS 解析任务被转移到一个单独的线程上。如果线程池级别较低，DNS 解析可能会一直等待可用线程直到超时，从而导致引发异常。为避免此异常，已删除了 DNS 超时逻辑。
解决此问题的方法
没有已知的解决方法。
2.13 SqlCacheDependency 必须用 System.Data.SqlClient.SqlDependency.Start 调用初始化
由于 SQL Server 2005 中的查询通知的工作方式发生了变化，开发人员在使用 SqlCacheDependency 之前，必须至少调用一次 SqlDependency 的 Start 方法。调用 Start 的逻辑位置在 Web 应用程序的 Application_Start 方法中（位于 global.asax）：
void Application_Start(object sender, EventArgs e)
{
System.Data.SqlClient.SqlDependency.Start("connection string");
}
连接字符串必须与发出与 SqlCacheDependency 一起使用的命令时所使用的连接字符串相同。
2.14 System.Net 在调用 WebClient.UploadValues() 时不再添加 CRLF 字符
在以前的 .NET Framework 版本中，调用 WebClient.UploadValues() 时会在上载的内容中添加 CRLF 字符，从而导致服务器应用程序失败。CRLF 字符违反了 application/x-www-form-urlencoded 内容类型编码方案，详见 HTML 4.01 规范中的描述。不再添加 CRLF。
解决此问题的方法
使用 WebClient.UploadData() 添加 CRLF 字符并重新编译应用程序，或修复服务器应用程序以不再需要 CRLF 字符。
2.15 设置 Fragment 或 Query 属性后，UriBuilder 不再清除它们
UriBuilder 是一个允许逐段生成 Uri 实例的类型。在以前的 .NET Framework 版本中，不能同时设置 Query 属性和 Fragment 属性。此错误已在 2.0 版中修复。现在，设置 Query 属性和 Fragment 属性时不会不小心清除任何字段。已解决以前行为的应用程序可能需要调整它们的逻辑以避免错误行为。
解决此问题的方法
没有已知的解决方法。
2.16 应用存在于应用程序配置文件的 system.net 元素中的值这一操作所需的权限已更改
应用存在于应用程序配置文件的 System.Net 元素中的设置所需的权限已不同于以前的 .NET Framework 版本。应用配置文件中的值所需的权限现在和那些在更改代码中的设置时相关属性所需的权限相同。
解决此问题的方法
没有已知的解决方法。
2.17 发送一个 FTP 请求后，如果又接着通过 SSL (FTP) 将另一个 FTP 请求发送到相同的目录，将引发“无法找到文件”异常
如果应用程序向服务器发送一个 FTP 请求后，又接着将另一个启用 SSL 的 FTP 请求发送到相同的服务器和路径，则第二个请求将失败。将引发无法找到文件异常。但是，如果第二个请求不发送到相同的路径，则请求将成功。
2.18 只有在相关服务点是代理服务器时，WebRequest.ServicePoint.Address 才要求不受限制的 Web 权限
此新要求将阻止以部分信任运行的应用程序发现网络代理服务器地址。如果地址指向代理服务器，使用 ServicePoint.Address API 的部分受信任应用程序可能收到 SecurityException。
解决此问题的方法
使用 HttpWebRequest.Address
2.19 Visual Studio 和 .NET Framework 的 32 位和 64 位行为之间的奇偶校验异常
1. 用于 IA64 WOW64 的 Front Page 服务器扩展。
当使用 .NET Framework 1.1 在运行 .NET Framework 1.1 的远程 IA64 计算机上创作网站时，FrontPage 机制不受支持。一些基本功能将通过文件共享机制运行。
2. J# 不支持在 64 位平台上本机运行。J# 代码只能在 64 位平台上的 WOW64 中运行。
3. 在 64 位平台上运行的 .NET Framework 2.0 不支持 SQL Server Express。
4. 在 IA64 上的 WOW64 中，运行于 .NET Framework 1.1 上的高负载 ASP.NET 应用程序的性能和可伸缩性没有保证。
5. 在 WOW64 中，数据断点在运行在 IA64 上的 Visual Studio 2005 中无效。
6. 在 Visual Studio 2005 中，“编辑并继续”调试器功能在 64 位平台上无效。
7. 在 Visual Studio 2005 中，VC ATL 异常：
- 生成系统不在 wow64 上注册面向 64 位的 dll
- 在 64 位计算机上调试默认 ATL Server 项目时出现错误“%1 不是有效的 Win32 应用程序”
- 没有为 64 位配置的 ATL Server 项目预填充要调试的可执行文件和 URL
- 在调试 64 位 ATL Server 项目时，Internet Explorer 不提供用户指定的 .srf 文件
- ATL Server 64 位配置的调试器类型默认为本地 Windows 调试器，而不是 Web 服务调试器
- 调试属性没有传播到项目中的新配置。例如，这意味着如果以 x86 下的 ATLServer 项目为起点，然后为它创建一个 64 位的配置，则如果调试对象不更改为 Internet Explorer，调试将无法进行
8. 64 位平台不支持互操作调试（托管 + 非托管混合模式调试）。
9. 64 位平台不支持某些 MDA，例如：Re-entrancy、LoaderLock、PInvokeStackImbalance。
10. IA64 和 x64 C++ 编译器不支持 MMX 内部函数。
11. IA64 和 x64 C++ 编译器不支持内联程序集。
12. x64 MASM 不支持大多数高级别语言构造。
MASM 不支持 IA64，但我们提供了 Intel 的汇编程序 (ias.exe)
13. 在 Visual Studio 2005 中，x64 和 IA64 VC++ 编译器不支持 VC++ 编译器开关 /ARCH:SSE。
14. 如果运行在 WOW64 下的 64 位子进程上，System.Diagnostics.Process.MainModule 和 System.Diagnostics.Process.Modules API 将失败。
15. 无法同时注册具有相同 GUID/CLSID 的 32 位和 64 位 COM+ 服务组件。
16. 64 位 SDK 不包括本机 DBGCLR。DBGCLR 为仅 WOW64。
17. 64 位 SDK 不包括本机 DEXPLORE.EXE。DEXPLORE.EXE 为仅 WOW64。
18. 没有 x64 和 IA64 的引导程序清单包。
ClickOnce 或其他应用程序没有 64 位引导程序。在任何已安装 .NET Framework 的 64 位计算机上尝试安装 ClickOnce 应用程序都将失败，并显示消息“64 位操作系统不支持此版本的 .NET Framework 2.0。请与您的应用程序供应商联系”。
对于仅编写为 32 位并且已在 WOW64 中运行的应用程序，也会发生这种情况。
19. Visual Studio 2005 不会在 IA64 平台上安装。
Visual Studio 2005 不会在 IA64 平台上安装（没有 IA64 设计时支持）。Visual C++ 将有一个本机 IA64 命令行工具安装程序。
20. 只有 Visual Studio Team System 允许生成面向 IA64 的应用程序
21. 具有可直接复制到本机结构中的类型的 P/Invoke 签名在 64 位平台上按不同的方式处理，因为 P/Invoke 在 64 位平台上以不同的方式实现，因此存在不正确的 P/Invoke 签名在 32 位平台上偶尔有效，但在 64 位平台上无效的情况。
22. 64 位平台不支持 Visual Studio 2005 Tools for Office。
2.20 在 C# 网站中执行重构操作时，当实际上不存在任何错误时可能报告生成错误
在某些情况下，在不包含生成错误的 C# 网站中执行重构命令时，用户可能会收到一条警告，指示当前未生成项目或其中一个依赖项，并且可能不能更新引用。
可以单击“继续”或“预览”按钮，放心忽略此对话框。重构将成功，并且所有引用将被更新。
以下是将会显示此警告的常见项目配置的示例：
- 从 Visual Studio 早期版本迁移的 Web 项目，此项目的 Web 目录中包含一个 global.asax 文件，App_Code 目录中包含一个 global.asax.cs 文件。
- Web 项目包含的网页引用 Web 用户控件，而 Web 用户控件又引用 App_Code 目录中声明的类型。
解决此问题的方法
没有已知的解决方法。不过，可以放心忽略此警告。
2.21 System.Net 现在注册了一个默认的 FtpWebRequest 实现，它可能导致使用自己的 FTP 组件的应用程序中断
在 .NET Framework 2.0 版之前，应用程序可以注册组件以使用 System.Net 的可扩展、可插入协议框架来处理 FTP 请求。通过将组件与特定的 URI 前缀关联，可注册用于处理不同 Web 请求的组件。与此前缀匹配的任何 Web 请求都由该组件处理。在 .NET Framework 2.0 中，System.Net 现在支持一个 FtpWebRequest 组件，默认情况下该组件注册使用“ftp:”前缀。由于此前缀 (FTP) 已被使用，注册使用此前缀的所有应用程序（此版本之前）现在可能中断。
解决此问题的方法
更新应用程序配置文件，在注册您自己的 FTP 组件前移除默认的 FTP 协议组件：
<system.net>
<webRequestModules>
<remove prefix = “ftp:”/>
</webRequestModules>
</system.net>
2.22 在 .NET Framework 2.0 中，当 machine.config 文件中存在空的 System.Net 标记时，GlobalProxySelection.Select 的行为与版本 1.1 中的不同
在 .NET Framework 1.1 版中，如果在 machine.config 文件中指定空的 System.Net 元素，则 GlobalProxySelection.Select 将返回空的 Web 代理实例，指示没有可以使用的代理。在 2.0 版中，新的默认设置是，在此情况下将使用系统代理设置（与 Internet Explorer 中指定的相同）。
解决此问题的方法
如下所示修改 machine.config 文件以禁用默认代理。
<system.net>
<defaultProxy enabled=”false” />
</system.net>
2.23 System.Uri 不包括主机的 IPv6 范围 ID
在以前的 .NET Framework 版本中，如果使用 IPv6 地址创建 Uri 实例，主机地址中始终包括范围 ID。范围 ID 是指本地网络适配器的索引，对远程主机没有意义。范围 ID 还在语法中使用“%”字符，该字符与“%hh”的 Uri 转义格式冲突。在主机中包括范围 ID 会破坏 System.Uri 与其他 URI 分析器和解析器交互的能力。在 2.0 版中，System.Uri 不再在 Uri 实例中包括 IPv6 主机的范围 ID。System.Uri 还添加了一个新属性 DnsSafeHost，它返回 IPv6 主机地址的范围 ID。
解决此问题的方法
使用 Uri.DnsSafeHost，它将返回 IPv6 主机地址的范围 ID。
2.24 通过 System.Transactions 配置将群集指定为远程代理可能会在群集故障转移时引发 TransactionException
如果通过在配置中将 DistributedTransactionManagerName 设置为群集来将群集指定为远程代理，则在群集故障转移时可能引发 TransactionException。
解决此问题的方法
若要将群集指定为远程代理，请使用组件服务 MMC 来配置 MSDTC，以将群集用作远程 MSDTC。
2.25 在 IDE 中执行各种操作时，可能会出现消息：“Microsoft C# 2005 IntelliSense 遇到了问题”
某些情况下，在编辑器中执行各种操作时，可能会出现消息：“Microsoft C# 2005 IntelliSense 遇到了问题。我们对由此造成的不便深表歉意”。大多数情况下，原因是检索源数据失败。
可能触发此消息的一些操作示例包括：
- 重命名外部别名。
- 在没有“runat="server"”的 Web 项目中执行“查找所有引用”操作。
这是一个非致命条件。单击“发送报告”按钮将允许用户安全地按预期继续工作，不会丢失任何数据。
解决此问题的方法
有两个可能的选项可从 C# 语言服务中关闭所有非致命错误信息的显示。为此，在以下注册表路径下修改注册表：
[HKEY_CURRENT_USER"Software"Microsoft"VisualStudio"8.0"CSharp"Options"Editor]
(1) "Watson_ReportExceptions"=dword:00000001
添加以上具有指定值的注册表项可彻底禁用错误报告。
注意：使用此注册表项从 C# 语言服务中关闭所有非致命错误信息有可能防止收集与此错误无关的方案的反馈。
(2) "Watson_DeferSendingUntilLater"=dword:00000000
添加以上具有指定值的注册表项可关闭消息的显示，但仍会向 Microsoft 发送反馈。当收集要发送的信息时，IDE 在短时间内将没有响应。
2.26 在事务提升期间尝试获取事务的 DistributedIdentifier 时引发 NullReferenceException
在事务正在提升时尝试获取事务的 DistributedIdentifier 可能导致引发 NullReferenceException。
解决此问题的方法
有两种方法可以解决此问题。
确保对事务的访问是同步的。
-或-
确保在检查 DistributedIdentifier 属性前已提升事务。
2.27 使用“添加 Web 引用”生成的 ASP.NET Web 服务代理全都使用配置文件中的同一 URL，即使该服务有多个终结点使用不同的 URL
在 Visual Studio 2005 中添加 Web 引用时，自动从配置文件的 AppSettings 节选出服务的 URL。如果 Web 服务有多个终结点使用不同的 URL，将生成多个代理类型，但它们全都使用从配置文件选出的同一 URL 值。
解决此问题的方法
有两种可能的方法：
1. 编辑 WSDL 文档，将每个服务拆分为一个单独的文档。
-或-
2. 编辑配置文件，为每个 Web 服务添加一项，然后使用 System.Configuration.ConfigurationSettings.AppSettings 将值读出到代码中。使用这些值设置代理实例的 URL 属性。
2.28 生成的 ASP.NET Web 服务代理中的默认 Nullable<T> 支持会在重新生成代理时中断现有代码
当导入的 ASP.NET Web 服务架构包含 nullable="true" 属性时，生成的代理将包含 Nullable<T> 类型，而以前此属性将被忽略。此更改可能导致应用程序中发生设计时或运行时中断。
解决此问题的方法
可能的解决方法是避免重新生成代理类型，使用新的 Nullable<T> 模式重新编译代码，或更改架构以不使用 nullable="true" 属性。
2.29 将 Web 服务代理实例的 Proxy 属性设置为空并未导致请求直接转到服务器
将 Web 服务代理实例的 Proxy 属性设置为空应该可以强制请求跳过所有 Web 代理服务器设置而直接转到服务器。但是，目前不能使用此功能。空值将被忽略，并改用任何已配置的 Web 代理服务器设置。
解决此问题的方法
可以通过从代理类型派生并重写 GetWebRequest 方法，直接设置基础 WebRequest 的 Proxy 属性：
protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}
2.30 在不同的 .NET Framework 版本之间使用 .NET 远程处理和运行时序列化
如果在运行于不同的 .NET Framework 版本上的应用程序之间交换数据（使用 .NET 远程处理或运行时序列化），在序列化或反序列化某些 Framework 类型时，可能会遇到异常。这些异常表明这些类型在不同的 Framework 版本之间不兼容，即无法将它们从 Framework 的一个版本发送到另一个版本。
.NET Framework 2.0 中包括一项称为“版本容错序列化”的技术，它可以消除这个问题。但是，以前的 Framework 版本仍面临这个问题。因此，将提供一个修补程序，它为 .NET Framework 1.1 增加了某些版本容错序列化功能。此修补程序需要 Service Pack 1。安装此修补程序后，在修补过的 Framework 上运行的应用程序将可以与 .NET Framework 2.0 上运行的应用程序进行通信，而不会遇到此版本问题。尚未计划为 .NET Framework 1.0 提供此类修补程序。
值得注意的是，只有在使用二进制序列化（直接或通过 .NET 远程处理）时，版本容错序列化才能解决版本问题。在 Framework 的不同版本之间使用 SOAP 序列化（直接通过 SoapFormatter 类或通过 .NET 远程处理）时，可能仍会遇到上述版本问题。
解决此问题的方法
若要获得此修补程序，请参见下面的知识库文章：http://support.microsoft.com/?kbid=907262。