我已经接手了一个以 .net 1.0 框架为目标并用 C# 和 Visual Basic 编写的 Web 应用程序的开发。
我决定我们需要做的第一件事是改进构建过程，我为 C# 项目编写了构建文件，但是在为 Visual Basic 创建构建文件时遇到了很多问题。
诚然，我个人并不了解 VB，但似乎我必须对构建文件中的所有导入和引用进行硬编码才能使任何东西正常工作...当然不是最好的做事方式...
举个例子：如果我没有在构建文件中包含命名空间系统，我会得到几个常见未知类型的错误，例如：Guid
对于 VB 代码，NAnt 通常是否需要这个，或者 VB 代码是否需要可能的 NAnt-freindly 重构？
有人有 VB NAnt 技巧吗？
【问题讨论】：
对于使用 Visual Studio 开发的 VB.NET 项目的 NAnt 和 vbc 编译器，我有过类似的经验。我的解决方案是避免在 Visual Studio 中的项目级别导入命名空间（默认情况下），并在类/文件级别使用显式 Imports 语句。 C# 项目默认以这种方式工作（没有项目级命名空间导入），我喜欢在查看文件时显式命名空间指令提供的额外信息。
有趣的是，VB.NET 和 C# VS 项目在这方面是如此不同。
【讨论】：
我不确定，如果您谈论的是 VB 或 VB.Net。
不管怎样，看看Nant Contrib。也许他们有解决方案。
【讨论】：
您是在调用 msbuild 来构建吗？或者你是在调用 VS.NET IDE exe 来构建。我们的 c#/VB.NET 混合使用 CC.NET 和 NAnt 没有任何问题，并且不必在构建文件中指定引用的程序集。
我们所做的是使用 IDE exe 来构建包含我们想要构建的项目的解决方案。
【讨论】：
我建议您将特定语言的编译器排除在此之外。您仍然可以使用 NAnt 来执行此操作：
首先从使用 MSBuild 的目标开始，因为无论使用何种语言，它都会编译您的项目并为您处理依赖关系。这意味着您不需要硬编码它们。
例子：
<target name="WinBuild">
<exec program="msbuild.exe"
basedir="${DotNetPath}"
workingdir="${SolutionPath}"
commandline="MySolution.sln
/nologo /verbosity:normal /noconsolelogger
/p:Configuration=Debug /target:Rebuild" />
</target>
我认为一旦你搞定了——你可以花大量时间尝试让 NAnt 本地编译，但在我看来，这就是我将用于这个项目的，因为它似乎是一次性的？
希望对你有帮助，
干杯，
罗伯克
【讨论】：