Не удалось получить открытый ключ для StrongNameKeyPair

Question

Я перенес разработку на другой компьютер, и если я запускаю проект, у меня есть следующее исключение:

Невозможно получить открытый ключ для StrongNameKeyPair.

HibernateException: создание экземпляра проксиОшибка

На оригинальном компьютере все работает нормально, без проблем.

Я обнаружил в Google, что это проблема с некоторым шифрованием, и я должен попробовать "sn -mn", но я нене знаю как.Файл sn.exe находится в других папках, я попытался запустить его из командной строки, но он пишет:

Не удалось открыть раздел реестра - невозможно отформатировать сообщение об ошибке 00000005

Я не знаю, если проблема в том, что NHibernate или нет, есть более похожие диалоги, и это исключение только в одном случае.

есть часть кода, исключающая исключение:

public IList<DTO> GetAll(GridSortOptions sortOptions, DTOListModel<DTO> listModel)
{
    return GetAllCriteria(sortOptions, CreateCriteria(), listModel).List<DTO>();
}

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

Answer 1

NHibernate динамически создает сборки .NET (динамические прокси) и должен подписывать их. По умолчанию ОС Windows настраивает хранилище криптографических ключей на уровне компьютера и хранит ключи в C: \ Documents and Settings \ All Users \ Application Data \ Microsoft \ Crypto \ RSA \ MachineKeys. Скорее всего, ваш пользователь может создать (например) текстовый файл в этой папке, но не удалить его, поскольку у вас нет полного контроля.

Ваши варианты

1. Получите полный контроль над C: \ Documents and Settings \ Все пользователи \ Application Data \ Microsoft \ Crypto \ RSA \ MachineKeys, изменив разрешения, которые могут быть не рекомендованы.

2. Измените хранилище крипто-ключей на уровень пользователя, запустив «sn.exe -m n» из Windows SDK. http://msdn.microsoft.com/en-us/library/k5b5tt23(v=VS.90).aspx Это поместит хранилища крипто-ключей под локальный профиль вашего пользователя, с которым вы всегда должны иметь полный контроль.

В Интернете есть несколько статей, в которых описана похожая проблема. Например, см. http://support.targetprocess.com/Default.aspx?g=posts&t=305.

Answer 2

Сегодня была похожая проблема с другим вариантом использования (служба .NET, работающая на коробке W2008R2), но точно такая же ошибка.

Используя procmon, я отследил его до неудачной записи на ключе в C: /ProgramData/Microsoft/Crypto/RSA/MachineKeys.

Следуя инструкциям по добавлению ВСЕХ со специальными разрешениями на папку, как указано здесь, исправлена ​​проблема: http://toastergremlin.com/?p=432

Кроме того, убедитесь, что вы добавили ВСЕХ @ локальный компьютер, а не ВСЕХ @ ваш домен!

Answer 3

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

Оказалось, что проблема с нехваткой места на диске, и динамические прокси-сборки не могут быть записаны на диск. Только понял это, потому что я случайно заметил значок Windows «мало места на диске», когда он появился ненадолго. : -Р

Очистка нескольких (больших) временных файлов устранила проблему.

Answer 4

У меня была такая же проблема сегодня, и мне не понравились предложенные решения. Это были:

• Наличие вашей собственной версии Castle.Core с удаленным кодом строгого именования. Ссылка
• Изменение прав доступа к папке. Ссылка: Этот вопрос
• Изменение хранилища криптографических ключей. Ссылка: Этот вопрос

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

/// <summary>
/// Ensures that NHibernate creates no strong named proxy assemblies.
/// Assumes usage of Castle.DynamicProxy. Needs to be revisited
/// after update of NHibernate or Castle.Proxy!
/// </summary>
private static void EnsureNHibernateCreatesNoStrongNamedProxyAssemblies()
{
    if (!StrongNameUtil.CanStrongNameAssembly)
    {
        Logger.Debug("NHibernate is not trying to strong name assemblies." +
                     "No action needed.");
        return;
    }

    const string FieldName = "canStrongNameAssembly";
    var type = typeof(StrongNameUtil);
    var field = type.GetField(FieldName, BindingFlags.Static
                                         | BindingFlags.NonPublic);
    if (field == null)
    {
        Logger.Warn(
            "No field with the name {0} exists in the type {1}."
            + "Can't change NHibernate to use weak named proxy assemblies.", 
            FieldName, type);
        return;
    }

    field.SetValue(null, false);

    if (StrongNameUtil.CanStrongNameAssembly)
    {
        Logger.Warn(
            "Couldn't change value of field {0} on type {1}. "
            + "NHibernate will continue to use strong named proxy assemblies.", 
            FieldName, type);
    }
    else
        Logger.Debug("Successfully changed NHibernate to use "
                     + "weak named proxy assemblies.");
}

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

Полагаю, реальным решением было бы перейти на NHibernate 3.3, который, к сожалению, больше не имеет этой проблемы, но сейчас это не вариант.