VS 15.8.2 зламав інструменти побудови - відсутній RuntimeIdentifier

Останнє оновлення Windows розірвало весь наш ланцюжок збірки, і я трохи не знаю, що це спричиняє.

У мене є застарілий проект, який є рішенням VS 2017 зі значною кількістю проектів (winform, пара в Інтернеті, лише деякі Webapi).

Місцево все працює чудово. Я можу їх просто побудувати.

На сервері проект почав виходити з ладу, і помилка:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): Error : Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore.

Process 'msbuild.exe' exited with code '1'.

Я додав

<RuntimeIdentifiers>win</RuntimeIdentifiers>

До ряду проектів. Без змін. Я втрачаю, тому що повідомлення про помилку навіть не вказує мені, який проект.

У певний момент перед спробою побудови потрібно видалити папку obj. Не одна людина показала це для вирішення проблеми.

https://developercommunity.visualstudio.com/content/problem/312180/projects-fail-to-build-in-1580-due-to-errors-from.html

Додайте це: <RuntimeIdentifier>win</RuntimeIdentifier> у файл проекту, наприклад після елемента TargetFrameworkVersion. Переконайтесь, що назва елемента є одниною. RuntimeIdentifiersз іншого боку, використовується в новому форматі csproj

Незважаючи на те, що відповідь @ Señor CMasMas мені допомагала в минулому, зараз я знаходжу (з моменту встановлення .NET Core SDK v2.2 - не знаю, якщо це пов'язано), що мені також потрібно закрити та знову відкрити Visual Studio . Отже, для мене рецепт:

• Чистий розчин
• Видалити objпапки
• Видаліть .vsпапку (необов’язково, якщо з’являються червоні лінії, але все в порядку)
• Закрийте та знову відкрийте Visual Studio
• Тоді будуйте

Або ви можете просто запустити в кореневому каталозі вашого проекту сценарій у PowerShell, який ви повинні запускати як адміністратор.

Get-ChildItem .\ -include bin,obj -Recurse | foreach { remove-item $_.fullname -Force -Recurse }

цей скрипт видалить усі папки obj та bin

ви повинні зрозуміти, які проекти у вашому рішенні викликають цю помилку. Ви можете знайти це, якщо поглянути на панель помилок. перейдіть до цих проектів і видаліть як папку bin, так і obj. потім відновити. повинно бути добре

Я маю подібний випадок. Я намагаюся створити рішення за допомогою msbuild, не встановлюючи Visual Studio 2017, просто встановіть останню версію інструментів збірки vs 2017. Ось мої кроки:

1. dotnet restore a.sln (у цьому рішенні є деякі проекти .Net Standard Library, інші - це проекти .NET 4.7.2).
2. зателефонуйте msbuild.exe, щоб побудувати це рішення.
3. Я отримав помилку "відсутній RuntimeIdentifier".

У вашому файлі проекту "win" не вказано як "RuntimeIdentifier". Вам слід додати 'win' до властивості "RuntimeIdentifiers" у файлі проекту, а потім повторно запустити відновлення NuGet.

Здається, проблема в старій версії Nuget. Будь ласка, зверніться сюди . Нарешті, я вирішив це через пакети відновлення за допомогою останньої версії Nuget (v5.0.2). кроки:

1. Видаліть папки obj та bin
2. nuget.exe відновити a.sln
3. зателефонуйте msbuild.exe

У мене була подібна проблема. Моя помилка була

помилка: у файлі проекту "win10" не вказано як "RuntimeIdentifier". Вам слід додати 'win10' до властивості "RuntimeIdentifiers" у файлі проекту, а потім повторно запустити відновлення NuGet.

Ну, виявилося, мені просто довелося змінити цільовий компонент з "Будь-якого процесора" на щось інше (наприклад, x64) ...

RuntimeIdentifier має виглядати приблизно так, як описано тут: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog .

Враховуючи, що це, здається, побудова просто знаходити локально, я б порівняв файл .csproj на вашій локальній машині з таким на вашому сервері збірки. Щось мені підказує, вони не однакові.

FWIW, рядок 186 у зазначеному файлі Microsoft.NuGet.targets, виконує завдання ResolveNuGetPackageAssets, і ви можете бачити, як аргумент RuntimeIdentifier передається як властивість NuGetRuntimeIdentifier. Можливо, ви можете простежити це в журналі діагностики робочої збірки, щоб побачити, як воно призначається.

Але враховуючи, що це працює в одному вікні, а не в іншому, я б просто перевірив файли вашого проекту на dbl і переконався, що тег RuntimeIdentifier ідентичний в обох системах.

З повагою,

У мене виникла така сама проблема перемикання між ланцюжками побудови vstools (VS2017 / VS2019) - ось що мені це виправлено - груба сила очищена через rimraf

У вашому файлі проекту "win" не вказано як "RuntimeIdentifier". Вам слід додати 'win' до належного типу "RuntimeIdentifiers" у файлі проекту, а потім повторно запустити відновлення NuGet

Видаліть вихідні артефакти посередницької збірки

rimraf *\obj\**

Для мене це було так просто, як компіляція програми Windows IoT з x86платформою замість ARM.

У моєму випадку це відбувалося у збірці Azure.

Я зміг це вирішити, змусивши побудувати використовувати інструменти Visual Studio 2019.

Я змінив наш файл build.cake так, що кроки MSBuild включали UseToolVersion для VS 2019 наступним чином:

     MSBuild(_solutionFile, settings => settings.SetConfiguration(_configuration)
         .UseToolVersion(MSBuildToolVersion.VS2019));

Єдине, що мені вдалося, це видалити ВСІ файли проекту та завантажити їх знову з контролю версій. Потім проблема зникла.

Якщо ви націлюєтесь на Azure Service Fabric або інше 64-розрядне середовище, переконайтеся, що у вас є узгодженість <PlatformTarget>x64</PlatformTarget>у всіх конфігураціях, визначених у файлі CSPROJ. У моєму випадку він добре працював локально, але не вдався на сервері CI, оскільки була одна з багатьох конфігурацій <PlatformTarget>AnyCPU</PlatformTarget>.

Я отримував ту ж помилку, що і оригінальний плакат, з Msbuild v15.9.21

Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore

Мої проекти - .net Framework v4.6.2. Проекти добре створюються локально, використовуючи VS 2017, але не вдалося, будуючи TeamCity Enterprise 10.0.5. Нещодавно я перетворив свої проекти з .package на PackageReference - це спричинило збій збірки.

Моїм рішенням було додати новий крок збірки для явного відновлення nuget-пакетів рішення перед побудовою рішення. Здається, що перед перетворенням проектів у PackageReference це було зроблено на етапі побудови неявно.

Я завжди отримую цю помилку в конвеєрі Azure. Дотепер я помічав таке, що виправлено для мене в різних випадках: 1. не фіксувати .suo-файл - якщо так, видаляти та повторно вводити 2. не фіксувати папки bin або obj - якщо так, видаляти та повторно вводити 3. якщо додано новий проект, встановіть залежність проекту від властивостей рішення - збережіть і зафіксуйте файл .sln

У мене була та ж проблема з одним із проектів модульного тесту, який не вдалося скомпілювати після того, як я перейшов на VS до 15.9.27, і рішення для видалення папки obj працювало для мене

Просте відновлення nuget перед викликом MSBuild працювало для мене. У мене є проекти, націлені на .NET Framework 4.7.2 (не SDK-стиль, застарілий стиль), який я переніс із синтаксису package.config.