Папка Roslyn bin, созданная в c: \ bin \ roslyn - PullRequest
1 голос
/ 07 апреля 2019

Я взял на себя обслуживание веб-решения, содержащего несколько проектов на c #.При компиляции один проект создает папку bin в Roslyn в своей папке bin выходного каталога, как и ожидалось, другой создает папку bin в Roslyn в C: \ bin \ roslyn.Я искал в файлах проекта какие-либо подсказки относительно того, почему это происходит, но не могу найти какую-либо ссылку на него.В журнале сборки показано, что когда проект, который создает папку Roslyn под выходным каталогом, файлы копируются с абсолютным целевым путем (C: \ project output dir \ bin \ Roslyn), тогда как в проекте, который создает его вC: \ bin \ Roslyn, файлы перечислены как только что скопированные в \ bin \ Roslyn.Если настройка проекта указывает на выходной каталог ($ (OutputDir) установлен).Любые указатели будут с благодарностью.

Ответы [ 2 ]

0 голосов
/ 09 апреля 2019

Спасибо за указатели, Icepickle правильно расспрашивает, если есть проблема, решение работает, но есть просто резервная папка, помещенная с корневого диска, поэтому она не идеальна.Я решил проблему, выполнив сборку решения (в разделе «Диагностическая многословность»), и во всех проектах, копирующих файлы в корневую папку, я добавил следующее в их файлы проектов.Это указывает на правильный путь и будет копироваться только в том случае, если файлов еще нет.

<Target Name="CopyRoslynCompilerFilesToOutputDirectory" AfterTargets="AfterBuild">
<ItemGroup>
  <RoslynFiles Include="$(CscToolPath)\*" />
</ItemGroup>
<MakeDir Directories="$(SolutionDir)$(SolutionName)\bin\roslyn" />
<Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(SolutionDir)$(SolutionName)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />

0 голосов
/ 07 апреля 2019

Мне известны 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 в техслучаев).В любом случае, стоит попробовать, если другие два метода, описанные выше, не помогают.

...