Атрибут InternalsVisibleTo не работает

Вы абсолютно уверены, что в атрибуте указан правильный открытый ключ? Обратите внимание, что вам нужно указать полный открытый ключ, а не только токен открытого ключа. Это выглядит примерно так:

[assembly: InternalsVisibleTo("MyFriendAssembly,
PublicKey=0024000004800000940000000602000000240000525341310004000001000100F73
F4DDC11F0CA6209BC63EFCBBAC3DACB04B612E04FA07F01D919FB5A1579D20283DC12901C8B66
A08FB8A9CB6A5E81989007B3AA43CD7442BED6D21F4D33FB590A46420FB75265C889D536A9519
674440C3C2FB06C5924360243CACD4B641BE574C31A434CE845323395842FAAF106B234C2C140
6E2F553073FF557D2DB6C5")]

Это около 320 шестнадцатеричных цифр. Не уверен, почему вам нужно указывать полный открытый ключ - возможно, с помощью только токена открытого ключа, который используется в других ссылках на сборки, кому-то будет проще подделать удостоверение дружественной сборки.

Еще одна возможная проблема: имя дружественной сборки, которое вы указываете в InternalsVisibleToAttribute, должно точно совпадать с именем вашей дружественной сборки, как показано в свойствах проекта друга (на вкладке «Приложение»).

В моем случае у меня был проект Thingamajig и сопутствующий проект ThingamajigAutoTests (имена изменены для защиты виновных), которые оба производили неподписанные сборки. Я должным образом добавил атрибут [assembly: InternalsVisibleTo( "ThingamajigAutoTests" )] в файл Thingamajig \ AssemblyInfo.cs и закомментировал атрибуты AssemblyKeyFile и AssemblyKeyName, как указано выше. Проект Thingamajig построен отлично, но его внутренние участники упорно отказываются появляться в проекте автотеста.

После долгих размышлений я перепроверил свойства проекта ThingamajigAutoTests и обнаружил, что имя сборки указано как «ThingamajigAutoTests.dll». Бинго - я добавил расширение ".dll" к имени сборки в атрибуте InternalsVisibleTo, и части встали на свои места.

Иногда это мелочи ...

Если ваши сборки не подписаны, но вы по-прежнему получаете ту же ошибку, проверьте файл AssemblyInfo.cs на наличие одной из следующих строк:

[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]

На вкладке свойств ваша сборка по-прежнему будет отображаться как неподписанная, если присутствует одна (или обе) из этих строк, но атрибут InternalsVisibleTo рассматривает сборку с этими строками как строго подписанную. Просто удалите (или закомментируйте) эти строки, и все должно работать на вас.

Стоит отметить, что если сборка друга (тестов) написана на C ++ / CLI, а не на C # / VB.NET, вам необходимо использовать следующее:

#using "AssemblyUnderTest.dll" as_friend

вместо ссылки на проект или обычного оператора #using. По какой-то причине это невозможно сделать в пользовательском интерфейсе ссылки на проект.

Вы можете использовать инструмент AssemblyHelper который сгенерирует для вас синтаксис InternalsVisibleTo. Вот ссылка на последнюю версию . Обратите внимание, что это работает только для сборок со строгими именами.

Вот макрос, который я использую для быстрой генерации этого атрибута. Это немного взломано, но работает. На моей машине. Когда последний подписанный двоичный файл находится в /bin/debug. И т. Д. Двусмысленность и т. Д. Во всяком случае, вы можете увидеть, как он получает ключ, так что это даст вам подсказку. Исправляйте / улучшайте, когда позволяет ваше время.

Sub GetInternalsVisibleToForCurrentProject()
    Dim temp = "[assembly:  global::System.Runtime.CompilerServices." + _
               "InternalsVisibleTo(""{0}, publickey={1}"")]"
    Dim projs As System.Array
    Dim proj As Project
    projs = DTE.ActiveSolutionProjects()
    If projs.Length < 1 Then
        Return
    End If

    proj = CType(projs.GetValue(0), EnvDTE.Project)
    Dim path, dir, filename As String
    path = proj.FullName
    dir = System.IO.Path.GetDirectoryName(path)
    filename = System.IO.Path.GetFileNameWithoutExtension(path)
    filename = System.IO.Path.ChangeExtension(filename, "dll")
    dir += "\bin\debug\"
    filename = System.IO.Path.Combine(dir, filename)
    If Not System.IO.File.Exists(filename) Then
        MsgBox("Cannot load file " + filename)
        Return
    End If
    Dim assy As System.Reflection.Assembly
    assy = System.Reflection.Assembly.Load(filename)
    Dim pk As Byte() = assy.GetName().GetPublicKey()
    Dim hex As String = BitConverter.ToString(pk).Replace("-", "")
    System.Windows.Forms.Clipboard.SetText(String.Format(temp, assy.GetName().Name, hex))
    MsgBox("InternalsVisibleTo attribute copied to the clipboard.")
End Sub

В дополнение ко всему вышесказанному, когда все кажется правильным, но дружественная сборка упорно отказывается видеть какие-либо внутренние компоненты, перезагрузка решения или перезапуск Visual Studio может решить проблему.

При компиляции дружественной сборки (сборки, не содержащей атрибута InternalsVisibleTo) необходимо использовать переключатель / out: compiler.

Компилятору необходимо знать имя компилируемой сборки, чтобы определить, следует ли считать полученную сборку дружественной сборкой.

Вам необходимо создать новый полный открытый ключ для сборки, а затем указать атрибут для сборки.

[assembly: InternalsVisibleTo("assemblyname,
PublicKey="Full Public Key")]

Чтобы сгенерировать новый полный открытый ключ для сборки из Visual Studio.

Чтобы добавить элемент "Получить открытый ключ сборки" в меню "Инструменты"

В Visual Studio выберите Внешние инструменты в меню Инструменты.

В диалоговом окне "Внешние инструменты" нажмите Добавить и введите "Получить открытый ключ сборки" в поле "Заголовок".

Заполните поле «Команда», перейдя к файлу sn.exe. Обычно он устанавливается в следующем месте: C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v7.0a \ Bin \ x64 \ sn.exe.

В поле «Аргументы» введите следующее (с учетом регистра): -Tp $ (TargetPath). Установите флажок Использовать окно вывода.

Нажмите ОК. Новая команда добавлена ​​в меню «Инструменты».

Когда вам понадобится токен открытого ключа для сборки, которую вы разрабатываете, щелкните команду «Получить открытый ключ сборки» в меню «Инструменты», и токен открытого ключа появится в окне «Вывод».

В моем случае, использующем VS.Net 2015, мне нужно было подписать ОБЕ сборки (если должна быть подписана хотя бы одна сборка или вы хотите ссылаться на открытый ключ своей сборки).

В моем проекте подпись вообще не использовалась. Поэтому я начал добавлять знаковый ключ в свою тестовую библиотеку и использовать InternalsVisibleTo-Attribute в базовой библиотеке моего проекта. Но VS.Net всегда объяснял, что не может получить доступ к методам друзей.

Когда я начал подписывать базовую библиотеку (это может быть тот же или другой знаковый ключ - если вы подписываете базовую библиотеку), VS.Net сразу же смог работать должным образом.

Предыдущие ответы с PublicKey работали: (Visual Studio 2015: НЕОБХОДИМО быть в одной строке, иначе он жалуется, что ссылка на сборку недействительна или не может ссылаться. PublicKeyToken не работал)

[assembly: InternalsVisibleTo("NameSpace.MyFriendAssembly, PublicKey=0024000004800000940000000602000000240000525341310004000001000100F73F4DDC11F0CA6209BC63EFCBBAC3DACB04B612E04FA07F01D919FB5A1579D20283DC12901C8B66A08FB8A9CB6A5E81989007B3AA43CD7442BED6D21F4D33FB590A46420FB75265C889D536A9519674440C3C2FB06C5924360243CACD4B641BE574C31A434CE845323395842FAAF106B234C2C1406E2F553073FF557D2DB6C5")]

Спасибо @Joe

Чтобы получить открытый ключ сборки друга:

sn -Tp path\to\assembly\MyFriendAssembly.dll

Внутри командной строки Developper (Startup> Programs> Visual Studio 2015> Visual Studio Tools> Developer Command Prompt for VS2015). Благодаря @Ian G.

Тем не менее, последний штрих, который заставил меня работать после вышеизложенного, заключался в том, чтобы подписать проект библиотеки моего друга так же, как подписан проект библиотеки, к которой нужно поделиться. Поскольку это была новая тестовая библиотека, она еще не была подписана.

Другая возможность, которую может быть сложно отследить, в зависимости от того, как написан ваш код.

1. Вы вызываете внутренний метод, определенный в X, из другой сборки Y
2. В сигнатуре метода используются внутренние типы, определенные в Z
3. Затем вам нужно добавить [InternalsVisibleTo] в X И в Z

Например:

// In X
internal static class XType
{
    internal static ZType GetZ() { ... }
}

// In Y:
object someUntypedValue = XType.GetZ();

// In Z:
internal class ZType { ... }

Если у вас это написано, как указано выше, где вы не имеете в виду ZType непосредственно в Y, после добавления Y в качестве друга X вы можете быть озадачены, почему ваш код все еще не компилируется.

В этом случае ошибка компиляции определенно может быть более полезной.

Я пишу это от разочарования. Убедитесь, что сборка, к которой вы предоставляете доступ, названа так, как вы ожидаете.

Я переименовал свой проект, но это не приводит к автоматическому обновлению имени сборки. Щелкните проект правой кнопкой мыши и выберите Свойства. В разделе Приложение убедитесь, что Имя сборки и Пространство имен по умолчанию соответствуют вашим ожиданиям.

Применяется только в том случае, если вы хотите сохранить неподписанные сборки как неподписанные (и не хотите подписывать их по нескольким причинам):

Есть еще один момент: если вы скомпилируете свою базовую библиотеку из VS.Net в локальный каталог, она может работать должным образом.

НО: как только вы компилируете свою базовую библиотеку на сетевой диск, применяются политики безопасности, и сборка не может быть успешно загружена. Это снова приводит к сбою VS.NET или компилятора при проверке совпадения PublicKey.

НАКОНЕЦ, можно использовать неподписанные сборки: https://msdn.microsoft.com/en-us/library/bb384966.aspx Вы должны убедиться, что ОБЕИ сборки НЕ ПОДПИСАНЫ, а атрибут Assembly не должен содержать информацию PublicKey:

<Assembly: InternalsVisibleTo("friend_unsigned_B")>

У меня такая же проблема. Ни одно из решений не помогло.

В конце концов выяснилось, что проблема связана с тем, что класс X явно реализует интерфейс Y, который является внутренним.

метод X.InterfaceMethod был недоступен, хотя я не знаю почему.

Решением было преобразовать (X как YourInterface) .InterfaceMethod в тестовую библиотеку, и тогда все заработало.

В качестве примечания: если вы хотите легко получить открытый ключ без использования sn и выяснить его параметры, вы можете загрузить удобную программу здесь. Он не только определяет открытый ключ, но также создает строку «assembly: InternalsVisibleTo ...», готовую для копирования в буфер обмена и вставки в ваш код.

Я только что решил аналогичную проблему с атрибутом InternalsVisibleTo. Все казалось правильным, и я не мог понять, почему внутренний класс, на который я нацелился, все еще был недоступен.

Изменение регистра клавиши с верхнего на нижний регистр устранило проблему.

Если у вас более одной сборки, на которую ссылаются, убедитесь, что все необходимые сборки имеют атрибут InternalsVisibleTo. Иногда это не очевидно, и нет сообщения о том, что вам нужно добавить этот атрибут в еще одну сборку.

1- Подпишите тестовый проект. В Visual Studio перейдите в окно свойств тестового проекта и Подпишите сборку, установив флажок та же фраза на вкладке Подписание.

2- Создайте PublicKey для тестового проекта: откройте командную строку Visual Studio (например, командную строку разработчика для VS 2017). Перейдите в папку, в которой существует DLL-файл тестового проекта. Создайте открытый ключ через sn.exe:

sn -Tp TestProject.dll

Обратите внимание, что аргумент - -Tp, но не -tp.

3- Добавьте PublicKey в тестируемый проект: перейдите к файлу AssemblyInfo.cs в тестируемом проекте и добавьте эту строку с PublicKey, созданным в предыдущем шаг:

[Сборка: InternalsVisibleTo ( "<сильный> TestProjectAssemblyName , <сильный> ОткрытыйКлюч = 2066212d128683a85f31645c60719617ba512c0bfdba6791612ed56350368f6cc40a17b4942ff16cda9e760684658fa3f357c137a1005b04cb002400000480000094000000060200000024000052534131000400000100010065fe67a14eb30ffcdd99880e9d725f04e5c720dffc561b23e2953c34db8b7c5d4643f476408ad1b1e28d6bde7d64279b0f51bf0e60be2d383a6c497bf27307447506b746bd2075")]

Не забудьте заменить указанный выше PublicKey своим.

4- Сделайте закрытый метод внутренним: в тестируемом проекте измените модификатор доступа метода на внутренний.

внутренняя статика void DoSomething () {...}