Мне известны 3 способа исследования проблем MSBuild:
В общем, я считаю, что двоичные журналы (binlogs) наиболее полезны.Создайте его, передав -bl
, затем откройте сгенерированный файл в MSBuild Structured Log Viewer .Он показывает очень похожие данные в журнале сборки, но имеет хороший поиск и показывает, что произошло в древовидном представлении, которое очень помогает понять.
Я думаю, что, вероятно, будет наиболее полезным для вас для этой конкретной проблемы, являетсявывод предварительно обработанного файла с помощью команды msbuild -pp
или dotnet msbuild -pp
.Это в основном находит все операторы MSBuild Import
и заменяет их фактическим содержимым импортированного файла.Я считаю, что MSBuild всегда оценивает сверху вниз.Таким образом, если свойство1 определено, то используется для оценки свойства2, а затем изменяется свойство1, значение свойства2 сохранит свое значение с момента его оценки.Помните, что выполнение целей приводит к тому, что цель оценивается, поэтому она может использовать свойство, которое было определено ниже по файлу, если сначала была запущена нижняя целевая цель, или свойства или элементы, определенные ниже, являются глобальными (не в цели).
Наконец, если ничего не помогает, вы можете попытаться установить в выводе журнала наивысшую детализацию, диагностику.Обратите внимание, что msbuild -v:d
- это подробная детализация, вам нужно msbuild -v:diag
, чтобы установить диагностическую детализацию.Я не уверен, выводит ли это на самом деле что-то большее, чем то, что находится в binlog, но я думаю, что, возможно, был один или два раза, когда я был в отчаянии, и вывод diag помог (но я не могу вспомнить, использовал ли я binlog в техслучаев).В любом случае, стоит попробовать, если другие два метода, описанные выше, не помогают.