2011-08-25 9 views
8

estoy tratando de exponer algunos detalles internos a mi proyecto de prueba de la unidad mediante el uso de:¿Cómo puedo hacer que InternalsVisibleAtribuya el trabajo al firmar una clave pública de token de forma segura?

[assembly: InternalsVisibleTo("MyTest")] 

pero estoy consiguiendo el error:

Error 1 Friend assembly reference MyTest' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations. .../MyClass.cs...

Cuando le asigno un PublicTokenKey manualmente:

[assembly: InternalsVisibleTo("MyTest, PublicKeyToken=XxxxxYysakf")] 

La solución se genera sin ningún error.

  1. ¿Por qué tengo que incluir un token de clave pública?
  2. No estoy seguro si voy a romper algo en producción al incluir el token de clave pública.

Entonces, ¿cuál es la mejor y más segura forma de asignar una clave pública a mi proyecto de prueba?

+0

Usted debe necesitar para asignar un símbolo de clave pública. Pero debe asegurarse de que los nombres de los ensamblajes coincidan. – UrbanEsc

+0

Estoy copiando los nombres de los ensamblajes del campo Nombre del ensamblaje que se muestra en Propiedades del proyecto. Así que debería ser correcto, supongo ... – pencilCake

+0

Muy bien, así que no he encontrado ese problema yo mismo, pero este chico podría tener otra opción para ti http://blog.tylerholmes.com/2008/04/unit-tests-and -internalsvisibleto.html – UrbanEsc

Respuesta

7

me sorprende que PublicKeyToken funciona incluso - en mi máquina me obliga a utilizar PublicKey

  1. La razón de que se necesita un símbolo de clave pública se debe a que las asambleas con nombre seguro, se pueden poner en el GAC, que tiene una gran confianza. Sería un agujero de seguridad si cualquier ensamblado llamado 'MyTest' (que es potencialmente no confiable, por ejemplo, un control en el navegador) podría llamar al interior de un ensamblado GACed; quiere la clave pública para evitar este tipo de pirateo.

  2. Esto no debería romper nada en la producción, incluso si no se puede encontrar el conjunto. Este atributo se usa durante el tiempo de compilación y no en el tiempo de ejecución.

¿Cuál es la forma más segura?

Si está realmente preocupado por ello romper el código de producción, quitar el atributo en las versiones de lanzamiento:

#if (DEBUG || TEST) 
[assembly: InternalsVisibleTo("MyTest, PublicKeyToken=XxxxxYysakf")] 
#endif 

Si usted tiene un par de proyectos que necesitan el símbolo de clave pública (y que tiene un único par de claves , lo que debería) también se puede definir un archivo, como AssemblyInfo.global.cs y añadirlo como un archivo vinculado a todos sus proyectos:

class KeyTokens 
{ 
    public const string Global = ", PublicKeyToken=XxxxxYysakf"; 
} 

Esto simplifica las cosas a (sobre todo si tiene que utilizar la PublicKey cuales es muy larga):

#if (DEBUG || TEST) 
[assembly: InternalsVisibleTo("MyTest" + KeyTokens.Global)] 
[assembly: InternalsVisibleTo("HisTest" + KeyTokens.Global)] 
[assembly: InternalsVisibleTo("TheirTest" + KeyTokens.Global)] 
#endif 
+0

Desafortunadamente, el enfoque de concatenación evita que IntelliSense funcione en el proyecto "amigo" VS (https://connect.microsoft.com/VisualStudio/feedback/details/542121/intellisense-warns-red-sqiggle-incorrectly-for-internalsvisibleattribute- set-by-a-constant, https://connect.microsoft.com/VisualStudio/feedback/details/108537/internalsvisibleto-intellisense-signed-assemblies). Hasta/a menos que esto se solucione, es poco probable que el enfoque constante concatenado encuentre el favor de la mayoría de los usuarios potenciales. –

+0

@Nicole - extraño, me funciona, posiblemente porque hacemos referencia a los ensamblados por el archivo de salida aquí y no por el proyecto. –

+0

Solo afecta las referencias del proyecto. Desafortunadamente, los escenarios donde los ensamblados de amigos tienden a ser más útiles (API semiprivados, exposición interna para pruebas) también son escenarios donde la gente tiende a preferir usar referencias de proyectos en solución. –

Cuestiones relacionadas