2010-03-11 14 views
5

Estoy intentando crear una prueba HttpContextBase simulada para la prueba unitaria.Problema StrongNameKeyPair al intentar usar MoQ

var fakePrinciple = new GenericPrincipal(
      new GenericIdentity(userId), 
      rolesList.ToArray());    
var mockHttpContext = new Mock<HttpContextBase>(); 
mockHttpContext.Setup(t => t.User).Returns(fakePrinciple); 
HttpContextBase mockedContext = mockHttpContext.Object; 

La prueba de la unidad falla en la última declaración con

tiramos excepción: System.ArgumentException : No se puede obtener la clave pública para StrongNameKeyPair ..

System.Reflection.StrongNameKeyPair .nGetPublicKey (Boolean exportado, Byte [] matriz, String contenedor) System.Reflection.StrongNameKeyPair.get_PublicKey() System.AppDomain.InternalDefineDynamicAssembly (AssemblyName nombre, el acceso AssemblyBuilderAccess, dir Cadena, evidencia Evidencia, PermissionSet requiredPermissions, PermissionSet optionalPermissions, PermissionSet refusedPermissions, StackCrawlMark & stackMark, IEnumerable`1 unsafeAssemblyAttributes) System.AppDomain. DefineDynamicAssembly (AssemblyName nombre, el acceso AssemblyBuilderAccess) Castle.DynamicProxy.ModuleScope.CreateModule (booleano signStrongName) Castle.DynamicProxy.ModuleScope.ObtainDynamicModuleWithStrongNam e() Castle.DynamicProxy.ModuleScope.ObtainDynamicModule (booleano isStrongNamed) Castle.DynamicProxy.Generators.Emitters.ClassEmitter.CreateTypeBuilder (ModuleScope modulescope, String nombre, tipo (bla bla SNIP)

I googled y no parecen las sugerencias aquí a trabajar (cambio de configuración de seguridad de carpetas RSA, etc.) http://groups.google.com.br/group/castle-project-users/browse_thread/thread/85685cf32a795158

Estoy en lo correcto al pensar que porque HttpContextBase es parte de System.Web.Abstraction, que es un montaje firmado. Moq intentará firmar el ensamblaje dinámico y ¿fallará?

+0

Fwiw, he utilizado para burlarse Moq HttpContextBase un montón de veces y nunca tuvimos ese problema.Cualquiera que sea su problema, no es general para la combinación de Moq y HttpContextBase. –

+0

El truco es que los permisos deben establecerse en la carpeta MachineKeys y no en RSA. La publicación de Ayende no lo hace completamente obvio si no eres cuidadoso lector. –

+0

Me alegro de haber encontrado esto, ugh, dos días y finalmente solucionado: D. Solo quería agregar algunas referencias más que me ayudaron, en caso de que alguien más se encuentre con esto: http://ansaurus.com/question/3154345-strong-name-keys-on-windows-7 | http://msdn.microsoft.com/en-us/library/bb909654(v=vs.90).aspx realmente me ayudó a concentrarme en la solución que funcionó para mí. –

Respuesta

9

MoQ usa Castle DynamicProxy para generar simulaciones en tiempo de ejecución. Rhino Mocks usa la misma biblioteca para el mismo propósito. Si marca aquí:

http://ayende.com/Blog/archive/2006/06/09/UnableToObtainPublicKeyForStrongNameKeyPair.aspx

verá que el tema es uno de los permisos para el almacén de claves de la máquina. Cualquiera que sea la cuenta de usuario que se ejecuta, la prueba debe tener permiso para crear y borrar claves en la tienda.

Puede encontrar mucho más detalles sobre este tema aquí: http://groups.google.co.uk/group/RhinoMocks/browse_thread/thread/26df68ff01567509/5ddebf407228edc4

+0

Comprobé los permisos en las carpetas RSA y Crypto, pero de alguna manera no está configurado para las teclas de máquina. Gracias Will. –

+0

¡Eso es porque es la carpeta MachineKeys lo que importa y no hereda los permisos! –

0

Salida this blog post por Scott Hanselman - que es un poco viejo, pero las MvcMockHelpers que muestra habrá probablemente le dará una buena idea de cómo llevar a cabo lo que está haciendo.

-1

Debería ver el sitio this video on asp.net que muestra un ejemplo sorprendente de implementación.

+2

La firma es el problema aquí, no cómo burlarse en mvc. – Will

+0

bien accedí a mi error –

Cuestiones relacionadas