在ASP.NET代码隐藏页中使用多种语言是否可以接受

本文关键字：是否 语言 NET ASP 代码隐藏页 | 更新日期: 2023-09-27 17:47:22

就本问题而言，代码库是一个ASP.NET网站，它有多个用C#和Visual Basic.NET编写的页面。主要语言是C#，Visual Basic.NET网页在项目中分叉时需要相同的功能。

是否应该花费时间来实际重写这些页面，包括再次经历测试和调试周期，还是认为可以接受？

在ASP.NET代码隐藏页中使用多种语言是否可以接受

您应该记住三点：

  1. 如果它没有坏，就不要修理它
  2. 团队组成和熟练程度
  3. 编码标准和统一性

首先，正如许多人所说，如果它没有被破坏，那么为什么要努力更改代码库呢。在语言转换过程中可能会添加错误，即使它们都是在ASP.Net.中运行的.Net语言

其次，我假设有一个合理的理由来分叉项目并使用VB.Net而不是继续使用C#。这种语言变化背后的原因是什么？这些理由不再有效吗？考虑一下导致使用不同语言的假设的有效性。

第三，所有团队成员都能胜任C#吗？如果几个团队成员不精通，那么将所有代码迁移到C#可能是一种负担

最后，我建议采用编码标准，并从这一点开始将所有新的开发集中在一种语言中。除了这些标准之外，您还可以考虑制定一项策略，规定如果需要修改/修复VB.Net页面，则应将此页面迁移到C#。

在这一点上，VB.Net页面不再"未损坏"，您很可能无论如何都要经过调试/测试阶段来验证修复/更改。所以，无论修复什么错误，都要增加迁移的成本。通过这种方式，您可以缓慢地将代码迁移到C#，而不会产生较大的一次性成本。

如果您不愿意迁移页面以及VB.Net页面中的任何错误修复或更改，请注意这一点。您很可能没有时间或资源来迁移所有VB.Net页面。由于大规模迁移将需要更多的时间，并且在迁移过程中会合理地要求您停止VB.Net页面上的所有工作/修复。这可能是一个指标，说明迁移到C#是否是一个选项，以满足您的业务需求。

您建议的是部分重写。

只有当现有代码的功能或体系结构出现严重错误时，我才能主张重写。

与VB相比，对C#的偏好不够充分。

您可能不想这样做。在这种情况下，可维护性将非常困难，因为团队通常具有单一语言的专业知识。

我们在这里有一些项目使用C#为某些页面编写，而VB.Net为其他页面编写。组建团队来维护这样的项目是很困难的。

谨致问候，Ashish

要回答第一个问题，是的，这是完全可以接受的，并且受到Microsoft的支持。

你应该换一下吗？如果你的开发人员了解项目情况，那么我认为你还好吗，但如果你开始看到namspace、引用或开发团队无法处理VB的问题(不太可能(。然后我会考虑重新写作。

但是，如果代码在那里并且有效，通常很难证明重写是合理的。

它得到了很好的支持。

对于页面来说，这没有什么区别。每一页都是单独编译的。

对于App_code目录中的代码，它是在每个文件夹的基础上编译的。因此，C#文件和VB.NET文件需要放在各自独立的子文件夹中。这些子文件夹需要在web.config的编译部分中注明，以便编译器知道如何区别对待它们。

<configuration>
<system.web>
    <compilation>
        <codeSubDirectories>
            <add directoryName="VB_Code"/>
            <add directoryName="CS_Code"/>
        </codeSubDirectories>
    </compilation>
</system.web>

这里有一个不错的链接。在App_Code文件夹中使用VB.NET和C#

我发现的唯一缺点是Intellisense似乎无法在两个App_Code子文件夹之间工作。不过，在页面中，intellisense运行良好。

相关文章：