No se puede obtener la clave pública de StrongNameKeyPair

Question

He portado en desarrollo a otro equipo y si corro proyecto, tengo esta excepción:

No se puede obtener la clave pública de StrongNameKeyPair.

HibernateException: Creación de una instancia de proxy no

El equipo original funciona bien y sin problemas.

Encontré en google que es un problema con algunas criptas y debería intentar "sn-m n", por no sé cómo. sn.exe se encuentra en varias carpetas, i tryed algunos corren desde la línea de comandos, pero se escribe:

No se pudo abrir la clave de registro - No se puede formatear el mensaje de error 00000005

No sé si El problema es que NHibernate o no, hay más diálogos whitch similares y lanza esta excepción solo en un caso.

no forma parte del código générale tiro excepción:

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

Nadie proyecto de utilización solución de firma. No entiendo qué significa exactamente este error y qué debería buscar.

Answer 1

NHibernate crea dinámicamente ensamblados .NET (proxies dinámicos) y necesita firmarlos. De forma predeterminada, el sistema operativo Windows configura el almacenamiento de la clave criptográfica para que sea a nivel de máquina y almacena las claves en C: \ Documents and Settings \ All Users \ Application Data \ Microsoft \ Crypto \ RSA \ MachineKeys. Lo más probable es que su usuario pueda crear (por ejemplo) un archivo de texto en esta carpeta, pero no eliminarlo porque no tiene control total.

Sus opciones son

1. obtener el control total de C: \ Documents and Settings \ All Users \ Datos de programa \ Microsoft \ Crypto \ RSA \ MachineKeys mediante la modificación de permisos que podrían no ser recomendado.

2. Cambie su almacenamiento de clave crypto a nivel de usuario ejecutando el "sn.exe -m n" desde el SDK de Windows. http://msdn.microsoft.com/en-us/library/k5b5tt23(v=VS.90).aspx Esto colocará almacenes de clave de cifrado bajo el perfil local de los usuarios, que siempre debe tener contorl completo.

Hay varios artículos en línea que describen un problema similar. Por ejemplo, vea http://support.targetprocess.com/Default.aspx?g=posts&t=305.

Answer 2

Tuve un problema similar hoy con un caso de uso diferente (un servicio .NET que se ejecuta en un cuadro W2008R2) pero exactamente el mismo error.

Usando el comando procmon lo remonté a una escritura fallida en una clave en C:/ProgramData/Microsoft/Crypto/RSA/MachineKeys.

Siguiendo la orientación de añadir a todos con permisos especiales en la carpeta que señalar aquí solucionado el problema: http://toastergremlin.com/?p=432

También, asegúrese de agregar TODOS @ máquina local y no todo el mundo @ su dominio!

Answer 3

Tuve el mismo problema hoy y no me gustaron las soluciones proporcionadas. Estos fueron:

• Tener su propia versión de Castle.Core con el código de nomenclatura fuerte eliminado. Reference
• Modificación de permisos en la carpeta. Referencia: esta pregunta
• Cambiando el almacenamiento de la clave crypto. Referencia: Esta pregunta

Lo siguiente puede ser un hack sucio pero funciona bastante bien y no tengo que explicarle a IT por qué quiero que se reconfiguren todas las computadoras de los usuarios finales.

/// <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."); 
} 

Simplemente asegúrese de llamar a este método desde el principio de su programa antes de que se genere el primer proxy.

Supongo que la solución real sería actualizar a NHibernate 3.3, que supuestamente ya no tiene este problema, pero esa no es una opción en este momento.

Answer 4

Para cualquier otra persona que se encuentre con esto, acabo de tener la misma excepción, en una máquina física. Nada cambió de la noche a la mañana, pero esta excepción comenzó a presentarse por la mañana.

Resultó ser un problema de poco espacio en disco y los ensamblados de proxy dinámico no se pudieron escribir en el disco. Solo me di cuenta de esto porque me di cuenta de que el ícono de Windows tenía poco espacio en disco cuando apareció brevemente. :-P

Limpiar un montón de archivos temporales (grandes) hizo que el problema desapareciera.