Оказывается, это не все VB.NET, которое сломано - только CodeDomProvider (который используют и ASP.NET, и Snippet Compiler).
Имеется простой исходный файл:
Imports System
Public Module Module1
Sub Main()
#If DEBUG Then
Console.WriteLine("Debug!")
#End If
#If Not DEBUG Then
Console.WriteLine("Not Debug!")
#End If
End Sub
End Module
Компиляция с vbc.exe версии 9.0.30729.1 (.NET FX 3.5):
> vbc.exe default.vb /out:out.exe
> out.exe
Not Debug!
Это имеет смысл ... Я не определял DEBUG, поэтому он показывает "Not Debug!".
> vbc.exe default.vb /out:out.exe /debug:full
> out.exe
Not Debug!
И, используя CodeDomProvider:
Using p = CodeDomProvider.CreateProvider("VisualBasic")
Dim params As New CompilerParameters() With { _
.GenerateExecutable = True, _
.OutputAssembly = "out.exe" _
}
p.CompileAssemblyFromFile(params, "Default.vb")
End Using
> out.exe
Not Debug!
Хорошо, опять же - это имеет смысл. Я не определил DEBUG, поэтому он показывает «Не отладка». Но что, если я включу символы отладки?
Using p = CodeDomProvider.CreateProvider("VisualBasic")
Dim params As New CompilerParameters() With { _
.IncludeDebugInformation = True, _
.GenerateExecutable = True, _
.OutputAssembly = "C:\Users\brackett\Desktop\out.exe" _
}
p.CompileAssemblyFromFile(params, "Default.vb")
End Using
> out.exe
Debug!
Not Debug!
Хм ... Я не определил DEBUG, но, может быть, он определил это для меня? Но если он это сделал, он должен был определить его как «1» - потому что я не могу получить такое поведение с любым другим значением. ASP.NET, использующий CodeDomProvider, должен определить его так же, как .
Похоже, CodeDomProvider отключается по глупым псевдологическим операторам VB.NET .
Мораль этой истории? #If Not
не очень хорошая идея для VB.NET.
И теперь, когда этот источник доступен, я могу проверить, что он действительно установил его равным 1 , как я и ожидал:
if (options.IncludeDebugInformation) {
sb.Append("/D:DEBUG=1 ");
sb.Append("/debug+ ");
}