那么，你可以混合网页的vb和c#只有当网站不是一个网站应用程序。
所以，这要看情况。
如果你的网站是作为一个网站应用程序设置的？那么不，你不能这样做。
当然，您可以从www.example.com应用程序中获取任何代码模块、类和业务逻辑vb.net，并在新的c#项目中引用这些程序集。
无论如何，不建议这样做（即：在一个项目中混合两种类型的页面-但是，你可以为网站这样做，但不能为网站应用程序）。
我认为简单地重写所有的代码几乎没有什么好处。它不像你会得到更多的功能，或任何有价值的东西。
如果你想迁移到.net core，MVC等？那么再一次，这些页面无论如何都不能使用-即使它们是用C#写的。
所以，要么你认为这是一个从webforms（和. net4.8）迁移出来的项目，要么你不这么认为。任何介于两者之间的东西都是在浪费时间和资源。如果那个网站要继续以webforms的形式运行，那么我真的不能把代码迁移到c# --我看不出这有什么好处。
因此，这可以适用于asp.net网站，但不适用于ASP.NET网站“应用程序”。
而且，我总是倾向于“应用程序”的选择，因为这样的话，像包括其他项目和代码（通常用c#编写）可以使用和支持。
但是，一个在www.example.com中有代码的页面vb.net，与c#中的页面和代码混合在一起？不，你不能在网站应用程序中这样做，我认为放弃应用程序选择（相对于网站）的代价太高了，因为你首先失去了asp.net应用程序选择的好处。
这听起来像是一笔好钱。除非你打算迁移到一个更新的框架？花时间+金钱迁移到C#是没有意义的，我看不到这样做有什么真实的的好处。
如果有问题的开发人员很了解asp.net+ webforms，那么使用www.example.com维护站点“原样”的学习曲线vb.net?我看不到任何优秀的c#开发人员需要一天左右的时间来熟悉vb.net。
c#或者vb.net都是没有实际意义的--重要的是.net framework中的一套好的扎实的技能，除非你跳到.net core，然后如前所述，我看不出这项工作的成本是合理的。它实际上相当于从那些支付转换费用的人那里偷钱，这意味着有人被误导了，或者错过了这里的信息。