我需要使用 Enterprise Services 以 COM+ 组件的形式构建服务。
该服务目前正在运行。它获取一个字符串，进行一些拼写检查并返回一个字符串。
我的问题是：
该组件是在 .NET 1.1 中编译的，但我的环境很快就会更改为 .NET 3.5。 那么，如果我在 .NET 3.5（实际上是 2.0）中编译代码，我会有什么好处吗？仅在.NET3.5中编译对性能有何影响？
请记住，我没有使用任何 .NET3.5 功能（甚至 WCF）！
CLR 和库进行了优化（例如启动速度更快），但很难说您是否会看到任何真正的速度差异。 字符串操作意味着内存分配意味着垃圾收集器的压力，所以在 3.5 中应该会好一点。
抱歉，您只能通过测试和测量才能得到真正的答案。
速度方面 - 也许（但请注意，.Net 3.5 甚至比 1.1 还要大，因为它包含了 LINQ、WCF、CF、WPF 等新技术）
部署 - .net 3.5 会很好，因为最新的 Windows 操作系统已经将 .Net Framework 3.0+ 作为其系统上的一项功能提供。
维护 \ 未来考虑因素 - .net 3.5。现在迁移到 .Net 3.5 会更好，因此如果您需要对软件进行更改，您已经可以受益于可用的更新技术...
如果您不更改代码而使用更新的功能，例如通用集合，则不会有太大变化。而且大多数较新的操作系统无论如何都没有安装 .NET 1 或 1.1，而是使用 .NET 2 运行时（3.5 也使用该运行时）运行代码。因此，您仍然应该受益于更好的抖动、互操作等，这些可能在新版本的运行时中得到了增强。
对于普通应用程序，可以在配置文件中指定应使用哪个框架版本，这样即使对于 1/1.1 应用程序，您也可以强制使用 .NET 2 运行时。不过，不确定这是否以及如何适用于 COM 激活的东西。
加载程序集和 JIT 编译其代码已经在 .NET 1.0 中进行了大量优化。 非常重要，因为它直接影响任何 .NET 应用程序的启动时间。 2.0 CLR 并没有显着改善这一点。
然而，.NET 3.5 SP1 中对安全策略进行了更新。 当程序集位置可信时，不再检查程序集的强名称。 确切的规则记录在此处。 这可以使热启动速度加快 40%。 这是一个乐观的数字，YMMV。