我需要使用企业服务以 COM+ 组件的形式构建服务。
该服务现在正在运行。它获取一个字符串并进行一些拼写检查并返回一个字符串。
我的问题是:
该组件是在 .NET 1.1 中编译的,但我的环境很快就会更改为 .NET 3.5。因此,如果我在 .NET 3.5(实际上是 2.0)中编译代码,我会有什么好处吗?仅通过在 .NET3.5 中编译对性能有何影响?
请记住,我没有使用任何 .NET3.5 功能(甚至 WCF)!
谢谢您的帮助。
我需要使用企业服务以 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。