Переопределение ссылки DLL решения NuGet на базовую библиотеку
Я работаю над программой Windows C# .NET 4.5, которая использует несколько проектов NuGet, чтобы уменьшить объем кода, который мне нужно написать (зачем изобретать велосипед?). Один из этих проектов NuGet по какой-либо причине имеет зависимость, которая переопределяет один из методов MSCORLIB, используемых где-то еще в моей программе.
ReSharper предупреждает меня о двусмысленной ссылке (и я, очевидно, не могу скомпилировать), и я не могу, хоть убей, понять, как указать использование метода MSCORLIB для этой зависимости проекта NuGet. Я потратил пару часов на поиски в Google и чтение разных вещей, но не нашел решения.
Часть моей программы с ошибкой неоднозначной ссылки не в любом случае полагается на зависимость пакета NuGet, поэтому, если я смогу просто реализовать метод MSCORLIB именно в этом месте, я буду золотым.
Это вообще возможно? Я попытался явно добавить ссылку на MSCORLIB в проект с помощью ReSharper «Использовать эту сборку ...», но выбор любой из них не помог, а также вкладка «Ссылки» в Visual Studio.
Вы пробовали использовать в верхней части файла: using NugetRef = NugetPackage.Namespace; для псевдонима ссылки на пакет nuget, чтобы устранить неоднозначность вызова?
Будет ли это работать в этом случае, поскольку они ссылаются на одно и то же пространство имен? Смотрите это изображение: i.imgur.com/rNHtmOg.png
Возможно, не в этом случае ... Вы можете динамически загрузить один из них в новый AppDomain и удалить статическую ссылку.
У меня нет опыта в этом (Обновлено: динамическая загрузка, о которой вы говорите, - это то, о чем я говорю). Есть ли у вас под рукой какой-нибудь материал, который я мог бы прочитать, чтобы узнать, является ли это потенциальным решением?
Спасибо много. Сможете ли вы создать ответ, чтобы, если я получу решение из ваших комментариев, я мог бы поблагодарить вас за решение?
Это проблема, для решения которой используются псевдонимы. Стандартный вариант использования для них - это ссылка на две разные версии одной и той же сборки, которые будут иметь типы с одинаковыми полными именами. Подробнее см. этот вопрос.
Что вы имеете в виду под точно, говоря «имеет зависимость, которая отменяет один из методов MSCORLIB, используемых где-то еще в моей программе»? Не могли бы вы привести конкретный пример?
Ответы 1
Вы можете решить эту проблему, используя псевдонимы сборки и extern alias. Чтобы решить эту проблему, вам нужно будет вручную отредактировать файл .csproj вашего проекта.
Если вы используете packages.config, найдите в своем файле .csproj элемент <Reference>, который соответствует проекту, вызывающему конфликтующий тип, и назначьте ему псевдоним.
<Reference Include = "bouncy_castle_hmac_sha_pcl, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\BouncyCastle-PCL.1.0.0.6\lib\bouncy_castle_hmac_sha_pcl.dll</HintPath>
<Aliases>bouncy_castle</Aliases>
</Reference>
Если вместо этого вы используете PackageReference, прямого элемента <Reference> не будет, поэтому вместо этого вам нужно добавить цель для присвоения этого значения.
<Target Name = "AssignAliasesToAssemblies" BeforeTargets = "FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition = "'%(FileName)' == 'bouncy_castle_hmac_sha_pcl'">
<Aliases>bouncy_castle</Aliases>
</ReferencePath>
</ItemGroup>
</Target>
Затем вы можете перезагрузить свой проект. В вашем C# добавьте extern alias bouncy_castle; в начало файла. Это проинструктирует компилятор, как устранить неоднозначность между двумя типами.
extern alias bouncy_castle;
using System.Security.Cryptography;
namespace ClassLibrary2
{
public class Class1
{
public HMACSHA1 Algorithm { get; }
public bouncy_castle::System.Security.Cryptography.HMACSHA1 TheOtherOne { get; }
}
}
Кстати, смотрите этот выпуск: https://github.com/NuGet/Home/issues/4989
Кроме того, если я смогу найти обходной путь, и он сломает этот пакет NuGet, мне, очевидно, придется найти совершенно новое решение.