.NET客户端框架值得针对吗?

8
我最近在研究为我正在构建的WPF应用程序定位.NET客户端配置文件。然而,我很沮丧地发现客户端配置文件仅适用于以下操作系统配置:
- Windows XP SP2+ - Windows Server 2003 编辑:看起来 客户端配置文件将无法安装在Windows Server 2003上。
此外,客户端配置文件对x64或ia64版本无效;如果已安装任何先前版本的.NET Framework,也不会安装。
我想知道将额外的操作系统配置添加到测试矩阵中的努力是否值得。是否有可用的指标表明可能从客户端配置文件中受益的用户的百分比?我相信一旦安装了.NET Framework,作为Web请求的一部分,会向Web服务器传递额外的信息,表示该框架可用。当然,我想象没有安装.NET Framework的Windows XP SP2用户将是大量的人。那么问题就在于我的应用程序是否专门针对这些个体。

有没有其他人确定针对这些特定用户进行额外努力是否值得?

编辑:似乎如果您使用客户端框架未包含的功能,可以获得编译器警告。由于我通常将警告视为错误运行,希望这足以最小化在此配置中的测试。当然,仍需要测试此配置,但应该只需测试安装/初始运行是否适用于XP SP2+。

3个回答

5
最终,如果你的目标是客户端框架(Client Profile),它不会对任何用户造成伤害。这是因为客户端框架是 .net framework v3.5 sp1 的子集,如果已经安装了v3.5 sp1,则不需要安装任何东西。
客户端框架中的程序集与完整框架中的二进制文件相同,因此除非动态加载程序集,否则您不需要进行任何其他测试。
我的想法是,除非您必须使用不在客户端框架中的程序集,否则您应该将其作为目标。
至于操作系统要求,WPF无法在XP sp2之前的版本上运行,因此如果您需要在其他操作系统上运行,则仍需使用WinForms。
编辑:
在IE上也是如此。它将.NET Framework版本作为UA字符串的一部分发送,例如:
实际上,FF3+3.5sp1也是如此:

3

我认为尽可能地面向更多用户很重要,你是否考虑过在不使用任何托管代码的情况下发布你的应用程序?你可以使用工具(如http://www.xenocode.com/http://www.remotesoft.com/linker/)将托管应用程序转换为纯机器代码,这样就完全不需要在客户端机器上安装.NET框架了。


2

我相信一旦.NET Framework被安装,作为Web请求的一部分会传递额外的信息给Web服务器,表示该框架已经可用。

在IE中,是的。它将.NET Framework版本作为UA字符串的一部分发送,例如:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; .NET CLR 2.0.50727).

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接