我似乎无法在我的开发服务器上启动并运行我的应用程序，我不确定为什么。

我已经在VS 2008中用3.5的目标框架编译了我的代码。我使用3.5主要是因为我已经相当广泛地实现了LINQ。编译并在本地运行没有任何问题。

挂断的是我的服务器只有2.0 .Net框架，升级到3.5显然不会发生。

经过一些研究后，我的印象是，只要尝试执行已编译的代码，服务器就不需要安装3.5.

今天，我试图发布到服务器，但我的WEB.CONFIG中无法解决此错误。

配置错误

解析器错误消息：不允许子节点。

providerOption name =" CompilerVersion" value =" v3.5" /

根据问题编辑：
我已经看到一些关于可能将我的引用设置为"本地复制"的帖子，这可能使我可以在2.0服务器上运行。有什么想法吗？

解决方案

除非我们在服务器上安装了3.5，否则我们将无法在服务器上运行目标为3.5的代码。

问题不在于代码，而是所需的库将丢失。

没错，3.5可以在2.0 CLR上运行，但是3.5包含库，并且如果我们使用了其中的任何库，除非我们在该服务器上安装了3.5，否则我们很不走运。

有很多选项可以使3.5程序不能仅在2.0上正确运行，因此我考虑降级程序或者升级服务器。

关于本地复制的注意事项。即使我们复制了应用程序使用的所有3.5库，也无法保证它会正常工作，很有可能不会。即使这样，.NET许可证仍然明确禁止与应用程序一起分发库。

既然我们已声明使用LINQ，则使应用程序运行的唯一合法方法是安装3.5许可证。

或者，我们可以仅使用2.0重写应用程序。

这是不可能的。尽管CLR并没有改变(就像在v1.1和v2.0之间一样)，但库却有所改变。我们无法运行未安装3.5框架的3.5应用。 3.5框架使所有Linq功能成为可能。

我很确定LINQ是使3.5成为要求的要素之一。许多其他事情，例如lambda表达式等，只是编译器的ery俩。

由于System.Linq是3.5功能，因此该框架必须为该版本。

确定的一个好方法是将目标框架更改为2.0，然后查看它是否可以构建。

Web.Config中是一个错误。已发布的Web.Config设置为允许从.NET 3.5进行编译，这就是它包含生成提供程序信息的原因。

除此之外，代码将无法运行。通过使用LINQ，我们可以引用.NET 2.0中不存在的程序集。

我们可以将3.5个dll复制到服务器上。我们绝对可以在2.0服务器上运行3.5代码。

我们可以在定位.NET 2.0时使用某些C3功能。它的语言功能在与IL兼容时将在2.0 CLR上运行，而不管CLR是否是2.0或者更高版本框架安装的一部分。

因此，我们可以使用匿名类型，扩展方法和Lambda表达式，但是一旦我们执行LINQ之类的操作，便需要3.5的一部分的外部库。

如果仅对对象执行LINQ，则可以将LINQBridge添加到发行版中。

我们可能遇到的另一个问题是，如果要交付一个包含源代码的Web应用程序，例如源代码，例如文件后面的代码，行代码和App_Code文件夹中的.cs。

我们可以最终交付Csource代码，该代码在存在C3编译器的开发机器上编译，但无法在仅配备C2的服务器上编译。在这种情况下，我们也不能使用任何新的语言功能。

更糟糕的是，在Visual Studio中将.NET 2.0框架指定为目标并不能阻止我们使用C3语言功能。我们不会收到有关此类语法无法在2.0机器上编译的警告。

因此，如果要交付这样的Web应用程序，则首先需要编译几乎所有内容。

我只是想在我的代表那里发表评论而已。到目前为止，我与众不同意，并相信lassevk的答案是最好的，因此请给他代表。我想让我们知道的一个问题是，一旦在IIS服务器上安装3.5(6或者更高版本)。当我们转到IIS管理器并右键单击网站时，访问" ASP.Net"选项卡。在安装3.5 Framework之后，我们将看到没有可用的3.5选项。它将仍然显示为2.0.50727. 不用担心，它仍然可以正常工作。由于这种不一致(感谢Microsoft)，已经引起了一些混乱。实际上，我认为这就是为什么我们可能认为2.0可以很好地运行3.5代码的原因。希望这会有所帮助，任何人都请对其进行编辑，以使其更有意义。

针对3.0或者3.5编译的代码可以在2.0框架上运行，但前提是我们不使用任何特定于3.0+框架的库。查找导致代码失败的原因的一种好方法是将目标切换到2.0并进行更改以使其编译。由于目标安装之一是.NET 2.0，因此我们将必须编写.NET 2.0代码；因此，这不是.NET特有的。过去，编写同时在Win95和WinNT中执行的应用程序需要开发人员付出额外的工作，才能仔细确保使用了适当的API。

从技术上讲，以3.5为目标的代码可以在2.0上正常运行，但是我们需要注意一些陷阱。如果任何内容都访问.NET 2.0中不可用的内容，则将失败。在应用程序启动时不会发生这种情况，而在应用程序尝试进​​行呼叫时会发生这种情况。我通过制作一个控制台应用程序进行了测试，该应用程序执行一点输出，然后尝试显示WPF窗口。产生了输出，但是当应用程序尝试在仅.NET 2.0的计算机上显示窗口时，应用程序将引发异常。

另一个陷阱是VS 2008实际上是.NET Framework 2.0 SP1附带的，而SP1中有一些类型和方法不在普通的2.0 Framework中。 Visual Studio不会将这些方法标记为不安全。

最后，如果这是一个Web应用程序，则针对3.5的项目的默认web.config文件与针对2.0的项目的web.config文件非常不同。确保我们正在分发兼容的web.config。这可能是我们遇到的问题。一种便宜的解决方法是将目标更改为.NET 2.0，复制该web.config，然后在这种情况下使用它。请记住，如果我们使用任何特定于3.0+的语言功能或者类型，代码仍将失败，但这将使我们摆脱web.config的困扰。