Я хочу протестировать базовый класс плагина, напрямую ссылаясь на проект плагина и создав экземпляр класса плагина. Когда я создаю тестовый проект консольного приложения и добавляю ссылку на проект в проект плагина, я получаю значок предупреждения (желтый треугольник с восклицательным знаком) рядом со ссылкой в списке ссылок.
Когда я вместо этого добавляю ссылку на dll, вывод сборки сборки плагина, я не получаю такого предупреждения. Что это предупреждение пытается мне сказать?
Как упоминалось в комментариях к вопросу, это могут быть разные версии .NET Framework в разных проектах. Проверьте свойства вашего нового проекта, чтобы убедиться, что другая версия по умолчанию не используется.
Обнаружена та же проблема с веб-приложением ASP.Net и двумя проектами библиотечных классов, на которые необходимо ссылаться в веб-приложении. У меня не было информации о том, почему сборка не удалась, а ссылки были недействительными.
Решение заключалось в том, чтобы у всех проектов была одна и та же Target Framework:
В Visual Studio 2015: Щелкните правой кнопкой мыши проект> Свойства> Приложение> Целевая платформа.
Сохранить, очистить и восстановить решение. Ссылки на проект больше не должны отображаться в виде желтых предупреждений, и решение будет скомпилировано.
Мое веб-приложение было нацелено на .Net 4.5, тогда как два других проекта зависимых библиотечных классов были нацелены на .Net v4.5.2.
Для обоих (или всех) проектов, которые вы хотите использовать вместе:
Щелкните правой кнопкой мыши проект> Свойства> Приложение> Целевая платформа .NET.
Убедитесь, что оба (или все) ваши проекты используют одну и ту же версию .NET framework.
Убедитесь, что все версии одинаковы для каждого проекта. Щелкните каждый проект и посмотрите версию здесь. Проект ›Свойства› Приложение ›Целевая платформа .NET.
а. Перейдите в Инструменты ›Диспетчер пакетов Nuget› Тип консоли диспетчера пакетов Обновление-Пакет -Переустановить (если не работает, перейдите к 2.b)
б. ЭТО КРИТИЧЕСКАЯ, НО САМАЯ БОЛЬШАЯ ВОЗМОЖНОСТЬ, КОТОРАЯ БУДЕТ РАБОТАТЬ. Remove ‹Target› Может быть с несколькими строками ‹/ Target› обычно находится в нижней части .csproj.
Сохраните, загрузите и соберите решение.
Переустановите все пакеты во всех проектах текущего решения:
Update-Package -Reinstall
Убедитесь, что у вас есть проекты, ориентированные на одну и ту же версию платформы. В большинстве случаев причина заключается в том, что текущий проект (в котором вы добавляете ссылку на другой проект) указывает на другую версию .NET Framework, чем остальные.
Попробуйте закрыть и открыть VS.
Выглядит глупо, но после 1 часа выполнения вышеизложенного и обнаружения, что все в порядке. Я перезапустил VS 2017, и проблемы исчезли.
Что касается меня, я столкнулся с этой проблемой при обращении к библиотеке классов .NET Standard 2.0 в консольном приложении .NET Framework 4.7.1. Да, фреймворки разные, но они совместимы (.NET Standard должен работать как с .NET Core, так и с .NET Framework). Я пробовал очистить, перестроить, удалить и прочитать ссылку на проект и т. Д. Безуспешно. . Наконец, выход из Visual Studio и повторное открытие устранили проблему.
Проверьте NETFramework указанной DLL и проекта, в который вы добавляете DLL. Пример: DLL ==> supportedRuntime version = "v4.0" Project ==> supportedRuntime version = "v3.0"
Вы получите значок предупреждения. Решение: Сделайте версию dll согласованной.
Прошло много времени с тех пор, как этот вопрос задавали, но если кому-то все еще интересно - я недавно сталкивался с похожими значками. Я компилировал проект C # .net с помощью VS 2008. Я обнаружил, что VS не может найти сборки для этих ссылок. Когда я дважды щелкнул VS, обновил ссылки и удалил значки на некоторых из этих [РЕДАКТИРОВАТЬ: которые теперь можно было найти]. Для остальных ссылок мне пришлось скомпилировать соответствующие сборки.
Добавляя мои 2 цента к ответу @ kad81,
Перейдите в Visual Studio -> BUILD -> Configuration Manager.
В раскрывающемся списке «Активная платформа решения» в верхнем правом углу (у меня VS 2012), если это «Смешанные платформы», измените его на соответствующую платформу на основе ваших эталонных сборок сторонних производителей.
Затем в каждом проекте в списке убедитесь, что вы выбрали одну и ту же платформу для всего проекта. (если x86 не существует, выберите "", затем вы можете выбрать "x86".)
Перестройте сначала проекты библиотеки, а затем ссылки на проекты. Надеюсь это поможет.
Используя Visual Studio 2019 со всеми проектами, ориентированными на .Net Core 3.1, решение заключалось в следующем:
В ядре Asp.net иногда отображается предупреждение, если вы меняете пространство имен или имя проекта. Чтобы удалить подобные предупреждения, просто выгрузите проект и загрузите его снова. Если проблема все еще существует, значит, вы не можете найти ссылку на сборку.
Также происходит, если вы явно ссылаетесь на проект, на который уже неявно ссылались.
i.e
вы увидите восклицательный знак рядом с буквой b под ссылками на проекты.
Эти иконки у меня были по другой причине. У нас есть одно большое решение для всех наших проектов (около 100). Я сделал часть проектов, которые меня интересовали, и сделал новое решение. Однако ссылки, в которых содержатся ссылки на проекты, а не ссылки на скомпилированные dll ....
После некоторого исследования я обнаружил, что эта ссылка на GitHub, в которой объясняется, что это новое поведение в VS2015.
На странице GitHub объясняется обходной путь преобразования ссылок на проекты в двоичные ссылки.
Чтобы исправить некоторые неработающие вещи, имеет смысл иногда удалить некоторые библиотеки, как бы это не звучало странно.
В любом случае, я считаю, что проблема слишком велика и может быть вызвана разными факторами, поэтому хочу поделиться своей ситуацией / решением.
У меня был проект (привезенный заказчиком) с библиотеками Xamarin Forms и Telerik. В основном речь шла о компонентах, которые библиотеки не входят в папку пакетов и не доступны через Nuget (платные).
Весь проект Референсы были «желтыми», это выглядело ужасно и устрашающе.
Решение заключалось в том, чтобы просто удалить эти ссылки на Telerik (включая несколько элементов управления в коде, которые их использовали). Сразу после этого все ссылки волшебным образом приобрели свой обычный нормальный серый цвет, и ошибки (в основном) исчезли.
«В основном» - потому что «все вокруг красное» сообщения об ошибках «элемент нигде не определен» иногда все еще возникают. Это странно и доставляет неудобства, но я все еще могу скомпилировать и запустить проект (ы): просто нужно очистить решение, перезапустить Visual Studio, немного помолиться, снова очистить, удалить папки obj / bin, снова перезапустить, и он работает хорошо.
Главное - удалить ссылки на недоступные библиотеки, поскольку сообщения об ошибках говорят совсем другое. (Например, что-то вроде «Xamarin.Build.Download.XamarinDownloadArchives не найден или не может что-то найти» и т. Д., Но это может означать, что у вас нет доступных ссылок.
Затем удалите папку пакетов, перезагрузите / снова откройте проект / решение, перейдите в «Управление пакетами Nuget» и нажмите кнопку «Восстановить».
В многопроектном решении, если все остальное не удалось ... В проекте startUp проверьте. Зависимости-> Сборки и посмотрите, есть ли там проект, на который есть ссылка. Удалите его и соберите заново.
Я также столкнулся с той же проблемой, но мой случай немного отличался от приведенного выше. Я попытался открыть проект, созданный на другом компьютере. Я обнаружил, что путь к папке пакета не обновляется при добавлении ссылки, поэтому перезапуск VS, изменение версии .NET или любые упомянутые рекомендации не решают проблему. Я открыл файл csproj в блокноте ++ и исправил все относительные пути к папке пакетов. Потом; все предупреждения исчезли. Надеюсь, это поможет.
в VS 2017 Сделайте очистку, затем выполните сборку
Спасибо всем за помощь. Вот подробное описание того, как я решил свою проблему:
Щелкните правой кнопкой мыши свой проект> Свойства
В разделе «Приложение» измените целевую платформу. В моем случае ImageSharp использовал .Net 4.6.1. Вы можете найти его в файле packages.config.
Перейдите к ссылкам на ваш проект. Вы заметите, что у SixLabors есть желтый треугольник. Вам необходимо обновить пакет NuGet.
Щелкните правой кнопкой мыши Ссылки> Управление пакетами NuGet.
Обновите SixLabors.
У вас могут быть небольшие обновления кода (см. Ниже), но это устранило мою проблему.
Преобразовать ImageSharp.Image в ImageSharp.PixelFormats.Rgba32?
В Visual Studio 2019 целевой структурой одного из моих проектов было ядро .net, но он ссылался на другой проект, целевая среда которого была стандартом .net. Я изменил все проекты, чтобы они ссылались на стандарт .net, и значки исчезли. Чтобы узнать, что это за проект, щелкните его правой кнопкой мыши, выберите «Свойства» и посмотрите на Target framework. Вы также можете щелкнуть по самому проекту и посмотреть на тег ‹TargetFramework> в‹ PropertyGroup>
У меня была такая же проблема в решении с проектами, ориентированными на .NET Core 3.1, .NET Standard 2.0 и .NET Framework 4.8. Проблема была в последней.
Уловка, решившая для меня проблему, заключалась в изменении целевой платформы на .NET Framework 4.5, а затем обратно на .NET Framework 4.8.
Я понятия не имею, почему это устранило проблему, но это произошло.
IDE была Visual Studio 2019.
Я создал новый .sln, который был помещен в подпапку. Папка .nuget отсутствовала, откуда был добавлен этот файл .sln. Перемещение папки .nuget из корня в подпапку, где мой новый файл .sln решил проблему для меня.
Я вернулся позже, добавил файл .sln в корень и удалил подпапку. Первоначально это тоже решило бы проблему.
Основываясь на ответе @AljohnYamaro (извините, не смог прокомментировать ваш ответ, новая учетная запись еще без достаточной репутации, но поддержала вас), я проверил файл .csproj.
В моем файле, помимо стандартной ссылки на проект:
<ProjectReference Include="..\ProjectA\ProjectA.csproj">
<Private>true</Private>
<CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>
</ProjectReference>
Также была прямая ссылка на скомпилированную dll из указанного проекта:
<ItemGroup>
<Reference Include="ProjectA">
<HintPath>..\ProjectA\bin\Debug\netcoreapp3.1\ProjectA.dll</HintPath>
</Reference>
</ItemGroup>
Удаление этой второй ссылки решило проблему.
Одна из причин появления этого раздражающего желтого треугольника заключается в том, что вы дважды добавляете ссылку на проект, что означает:
Если удалить ссылку 2, желтый треугольник исчезнет.
Если вы используете проекты Sdk нового стиля, добавьте OutputType в элемент ProjectGroup со значением Library в проекте, на который вы ссылаетесь. Это также доставит вам горе, если оно находится в проекте, на который вы ссылаетесь, и ссылается на проект без настройки.
