Wenn die MSBuild-Variablen generell nicht unterstützt werden würde, wäre das ja noch zu verstehen. Aber nicht, wenn an einer stelle die Unterstützung da ist und an der anderen stelle dann wieder nicht.
Na ja, die eine Stelle, wo es unterstützt wird ist eben MSBuild selbst während des Compile-Vorgangs. Das stellt diese Variable implizit bereit und der Compiler kann die dann auch nutzen. Weder der Debugger noch die
IDE kann diese Variable sehen - wie auch.
Natürlich kann man diese MSBuild-Variablen innerhalb des Build-Prozesses nutzen, aber man kann dann nicht erwarten, dass das dann außerhalb des Build-Prozesses auch funktioniert. Selbst wenn man das jetzt für diese eine Variable implementieren würde, käme sicher bald die Frage auf: Warum nicht die anderen auch? Dann hätte man aber eine potentielle Abhängigkeit von der verwendeten MSBuild-Version. Das halte ich eher für kontraproduktiv.
Was in der Tat zu bemängeln ist: Die
IDE bzw. der Debugger lösen $(SanitzedProjectName) auch nicht auf, wenn es im Ausgabepfad für die EXE steht. Das ist nicht ganz, was in
RSP-38952 bemängelt wird, und
RSP-37401 erwähnt es nur intern.
Ich habe daher mal zwei neue Reports eingestellt, die diese Themen gezielt ansprechen:
Accept $(SanitizedProjectName) in EXE path when debugging
Move $(SanitizedProjectName) definition to main PropertyGroup