Ошибка CVT1108 не может открыть RES....tmp для записи, периодически появляющаяся в конвейере DevOps
У меня есть конвейер создания приложения C# с использованием Visual Studio 2019. Иногда при создании решения я получаю следующую ошибку.
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\al.exe /cultural:da /out:obj\Release\da\MyApp.resources.dll /platform:AnyCPU / шаблон:obj\Release\MyApp.exe /embed:obj\Release\MyApp.Properties.Resources.da.resources
##[ошибка]CVTRES(0,0): ошибка CVT1108: невозможно открыть C:\Users\WP2BUI~1\AppData\Local\Temp\RES161C.tmp для записи
Имя файла всегда разное (но это всегда RESxxxx.tmp), и если я смотрю на сервере в указанном каталоге, то вижу большое количество этих файлов RES....tmp, однако все те, о которых сообщается в этом сообщении об ошибке, появляются. иметь размер 0 байт.
Поиск сообщения об ошибке в Интернете обнаруживает несколько совпадений, но в каждом случае это означает, что агент сборки имеет права записи в этот каталог. Я не думаю, что это ответ в данном случае, поскольку я проверил, и у пользователя, похоже, есть права на запись, и я предполагаю, что если бы это была проблема, каждый раз происходил бы сбой.
Еще две вещи, которые я должен отметить.
Многие разработчики используют этот конвейер — это конвейер непрерывной интеграции, используемый для запросов на включение.
Когда я создаю приложение на своей машине и отслеживаю тот же каталог, файл RES....tmp ненадолго появляется и исчезает, что заставляет меня думать, что VS следует удалить его после использования. Однако на сервере сборки остались сотни таких файлов после нескольких месяцев сборок.
Редактировать
Эта ошибка появляется под приведенной выше. Не уверен, вызвано ли это вышеуказанной ошибкой или является ее причиной, но если это имеет значение:
CVTRES: фатальная ошибка CVT1108: невозможно открыть C:\Users\WP2BUI~1\AppData\Local\Temp\RES161C.tmp для записи [c:\agent_work\56\s\src\MyApp\MyApp.csproj]
##[error]ALINK(0,0): Ошибка AL1019: Ошибка метаданных при создании сборки — указанный файл изображения не содержал раздел ресурсов.
Еще одно редактирование
Всегда al.exe завершается с ошибкой, указанной выше, и всегда в файлах ресурсов. Приложение поддерживает 12 разных языков, и al.exe запрашивает ресурсы на каждом из них. Тот, на котором это терпит неудачу, кажется случайным.
However, on the build server, there are hundreds of these files left over from a few months' worth of builds - см. Visual Studio 2022 добавляет огромное количество папок в %TEMP%: безопасно ли их удалять?.
@gunr2171 — Пользователь является администратором. В настоящее время активен только один агент (есть второй, использующий того же пользователя, но он отключен).
Привет @komodosp, не могли бы вы попробовать построить решение непосредственно на агенте, не используя конвейер Azure Devops? Вы можете использовать Visual Studio 2019, msbuild или dotnet build. Это помогает сузить проблему. Кстати, в конвейере, если вы используете задачу VSBuild@1, вы можете попробовать использовать задачу DotNetCoreCLI@2, чтобы посмотреть, произойдет ли та же ошибка.
@MiaoTian-MSFT - я уже несколько раз собирал решение на сервере (но используя своего пользователя, а не пользователя агента сборки) с помощью msbuild и не столкнулся с ошибкой. Иногда (не во всех сборках) у меня случается, что один из файлов RES*.tmp остается в моей папке Temp.
Запустил DirectoryMonitor в папке, и было создано множество файлов RES*.tmp, которые сразу же были удалены (я полагаю, один раз для каждого запуска al.exe), однако один из них был отмечен как «Новый», а затем «Измененный», а не удален. ... это тот, который остался в папке Temp после завершения сборки. Интересно, почему этот был изменен, а все остальные удалены.
Хм... теперь интересно, возможно ли, что при большом количестве запущенных экземпляров al.exe они выполняются одновременно, и поскольку они, похоже, берут «следующее» доступное имя файла RES*.tmp, они конфликтуют. Или, наоборот, он выполняется так быстро, что иногда к моменту запуска следующего файловая система не обновляется вовремя, чтобы отразить, что предыдущая уже создала определенный файл, и она также конфликтует? Мне интересно, можно ли как-нибудь приказать msbuild распределить вызовы на al.exe.
Привет @komodosp, ты можешь попробовать добавить -maxcpucount:1 к команде msbuild, чтобы запретить MSBuild работать параллельно . Кстати, я тоже нашла этот вопрос с таким же Error Message: CVT1108. Это решается путем предоставления учетной записи полного контроля над папкой Temp, и вы можете попробовать.
@MiaoTian-MSFT — спасибо за вашу помощь — я внес -maxcpucount:1 изменение, и пока все хорошо, но, как я уже сказал, это происходит с перерывами, поэтому пройдет некоторое время, прежде чем я узнаю, сработало ли это! Что касается другого вопроса - учетная запись уже имеет полный контроль над папкой Temp, и я думаю, что если бы это была проблема, она бы терпела неудачу каждый раз, а не просто случайно, как сейчас - она может создавать и удалять множество этих RES. ..tmp файлы без проблем, прежде чем случайно падать.
Спасибо за напоминание и обновление. Я не заметил, что эта проблема возникала в конвейере время от времени. С нетерпением ждем ваших обновлений о мониторинге в течение нескольких дней, чтобы узнать, поможет ли -maxcpucount:1 вам решить эту проблему.
Привет @komodosp, прошло несколько дней с тех пор, как мы обсуждали этот вопрос. Может ли -maxcpucount:1 помочь с этой проблемой?
@MiaoTian-MSFT - да, похоже, это помогло, спасибо за предложение - если вы опубликуете это как ответ, я приму его
Привет @komodosp, рад слышать, что это работает. Я добавил ответ. Приятного кодирования! :)
Ответы 1
Судя по нашему обсуждению в комментариях, вы заметили необычное поведение файла RES*.tmp с al.exe и подумываете, можно ли как-то приказать msbuild распределить вызовы al.exe.
Итак, я предлагаю вам добавить -maxcpucount:1 к команде msbuild, чтобы запретить MSBuild работать параллельно. Похоже, это сработало после нескольких дней наблюдения.
Какой тип пользователя запускает службу Windows для агента? Есть ли на одном компьютере несколько агентов и используют ли они одного и того же пользователя? Является ли пользователь администратором этого ящика?