Мы используем Azure Devops для создания наших проектов .NET и задачи Visual Studio build. Наш сервер сборки решил начать выводить все файлы в верхнем регистре. Это приводит к последующим сбоям в наших конвейерах сборки и выпуска.
Я могу воспроизвести это поведение на нашем сервере сборки, используя следующую команду:
MSBuild.exe OurSolution.sln /p:Configuration=Release /p:Platform = "Any CPU"
Каждый файл, выводимый в папку \bin, пишется ПРОПИСНЫМИ РЕГИСТРАМИ. В файлах .csproj нет ничего подозрительного, и это происходит во всех решениях и проектах, в которых несколько дней назад не было этой проблемы.
В качестве примечания я попытался обновить агент сборки Azure Devops и инструменты сборки Visual Studio 2022, установленные на сервере.
Редактировать:
Журнал MSBuild показывает правильный регистр в выходных файлах. В папке \obj также содержатся файлы с правильным регистром. Таким образом, похоже, что переименование в верхнем регистре происходит при копировании файлов из папки \obj в папку \bin.
Я попытался с помощью нового консольного приложения сделать журнал управляемым. MSBuild отображает выходные файлы в правильном регистре, однако выходные данные по-прежнему переименовываются в верхний регистр. Интересно, что свойства файла показывают исходное имя файла в правильном регистре.
Если в журнале MSBuild указан правильный регистр, возможно, это не MSBuild.
Согласен, но я в недоумении, что еще может быть причиной этого
Не могли бы вы попробовать запустить тот же код на агенте, размещенном Microsoft, чтобы проверить, сохраняется ли проблема? Это может помочь сузить проблему. Кроме того, вы можете проверить, установила ли ваша VS функцию свойства, чтобы преобразовать выходной файл в верхний регистр. Пожалуйста, обратитесь к этому вопросу.
Эта проблема не возникает ни на агенте, размещенном Microsoft, ни на моем компьютере, поэтому она, похоже, специфична для этого сервера сборки. Я не вижу никаких функций свойств, но теперь я также попробовал удалить все инструменты сборки VS и переустановить Visual Studio на сервере — все в порядке, если я собираю через VS, но проблема сохраняется, если я использую MSBuild напрямую («C: \Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\MSBuild.exe")
Кажется, на вашем сервере возникла какая-то проблема. Если есть возможность, можно попробовать перенастроить сервер. Кстати, вы также можете попробовать задачу DotNetCoreCLI@2 вместо задачи сборки Visual Studio, чтобы посмотреть, может ли это быть решением проблемы.
Привет @RobKite, могу ли я узнать, нашли ли вы причину проблемы?
К сожалению, пока нет. Задача DotNetCoreCLI@2 — это обходной путь для сборки решения, однако я все еще обнаружил, что наши пакеты NuGet (созданные как часть этой задачи) изменяются на верхний регистр при копировании в промежуточный каталог артефакта перед их отправкой в наш Сервер NuGet (процесс выпуска в настоящее время завершается неудачей, поскольку поиск файлов .nupkg чувствителен к регистру). Мы находимся в процессе настройки альтернативной машины с агентом сборки, поскольку она действительно зависит от машины, но нам не удалось решить проблему напрямую.
Спасибо за ваше обновление. Похоже, проблема возникает при копировании файлов в другую папку. Поскольку причина проблемы еще не найдена, и проблема возникает только на этом сервере сборки, перенастройка нового сервера сборки действительно является лучшим выбором.





Согласно проведенному вами устранению неполадок, мы можем резюмировать, что проблема возникает при копировании файлов в другую папку. И проблема не связана с Azure DevOps.
Задача DotNetCoreCLI@2 служит обходным путем для создания решения, но по-прежнему возникают проблемы с изменением пакетов NuGet на верхний регистр при копировании в промежуточный каталог артефакта.
Поскольку проблема возникает только на этом сервере сборки, перенастройка нового сервера сборки действительно является лучшим выбором.
к сожалению, в этом случае единственное решение, которое мы смогли найти, - это переконфигурировать новый сервер, надеясь, что это больше не повторится!
Попробуйте
msbuild.exe OurSolution.sln /p:Configuration=Release /p:Platform = "Any CPU" /verbosity:diagnosticполучить полную информацию о том, что там делает msbuild (если проблема может быть в msbuild или каком-то целевом файле)