Moles 0.94.51023.0 error en VS 2010 SP1

Question

Estoy intentando topo v4 System.ServiceModel en VS 2010 SP1 con lunares 0.94.51023.0 y me siguen dando la siguiente errror: El tipo o espacio de nombres 'IHttpCookieContainerManager' hace no existe en el espacio de nombres 'SSM' :: System.ServiceModel.Channels (¿falta una referencia de ensamblado?) [mi-test-project.Test \ obj \ Debug \ Moles \ SSM \ mgcsproj] mi-test-proyecto. Prueba \ mgcs 293022 43

Parece que esta interfaz se ha eliminado de System.ServiceModel.dll en .NET 4.0 ya que solo puedo encontrarlo en System.ServiceModel.dll v2.0.5.0 (Silverlight) cuando buscar en el buscador de objetos.

Puedo reproducir esto a través de la línea de cm usando moles.exe y he intentado modificar el archivo de moles para generar solo los nombres de tipo que especifico pero no parece hacer ninguna diferencia. Esto estaba funcionando bien antes de mi actualización a VS2010 SP1, así que sospecho que es un error, pero cualquier ayuda sería apreciada.

Gracias Nick

Answer 1

I depurado esto por mi cuenta, así y se encontró que la causa principal parece ser que VS2010 SP1 (y el relacionado GDR KB update for .NET 4) actualizar un conjunto de archivos DLL, pero no otro:

El System.ServiceModel.dll en% ProgramFiles (x86)% \ Referenced Assemblies \ no coincide con el de la instalación de .NET v4 en% windir% \ Microsoft.NET \ Framework64 \ v4.0.30319 ...

Publicar VS 2010 SP1 actualización:

% Archivos de programa (x86)% \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.0 \ System.ServiceModel.dll -> Versión de archivo 4.0.30319.1

% windir% \ Microsoft.NET \ Framework64 \ v4. 0.30319 \ System.ServiceModel.dll -> Versión de archivo 4.0.30319.225

Al comparar estos dos dlls en el Examinador de objetos en VS y en Reflector, se obtiene el resultado de que la interfaz IHttpCookieContainerManager se ha eliminado en el archivo más reciente. Así que sospecho que esta es una combinación de la detección de .NET que busca la DLL y los Moles más recientes que se reflejan en la anterior al hacer la generación de mole/stub. Pude generar manualmente un dll de Moles para la DLL más nueva ejecutando el exe de Moles manualmente sin rutas de referencia de ningún tipo en comparación con el objetivo de MSBuild que agrega un montón de rutas de referencia durante una compilación.

Answer 2

no sé qué que sucede, pero no tenía el mismo problema, y ​​lo resuelve mediante el uso de filtros de tipo Moles, y sólo incluyendo los que realmente necesita (que tiene el agradable efecto secundario de acelerar la compilación bastante !!). Este es un ejemplo de archivo .moles que estoy usando:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/"> 
    <Assembly Name="System.ServiceModel"/> 
    <StubGeneration> 
    <Types> 
     <Clear/> 
     <Add Namespace="System.ServiceModel.Description!"/> 
    </Types> 
    </StubGeneration> 
</Moles> 

Answer 3

Parece que había un conflicto entre los conjuntos del sistema y system.serviceModel que Moles estaba utilizando para la compilación.

que había instalado recientemente el Microsoft .NET Framework 4.5.

Después de desinstalar esto y volver a instalar 4.0 todo funcionaba.

Answer 4

Bueno, en caso de que alguien esté trabajando con un código heredado y esté arrinconado en el uso de Microsoft Moles, he investigado mucho sobre este tema y espero salvar algo del enojo y la frustración que encontré.

Intenté usar la sugerencia de la respuesta aceptada, lo que significaba ir al directorio de Moles (en C: \ Archivos de programa ...) y ejecutar la utilidad de línea de comandos (moles.exe) como Administrador. Hay muchas opciones, una de las cuales le permite incluir ensambles referenciados (como se sugirió anteriormente).

Sin embargo, incluso cuando intento ejecutar la utilidad sin los ensamblados a los que se hace referencia, finalmente llama al compilador de C# (csc.exe) con rutas de ensamblaje referenciadas predefinidas, que es donde concluyo que la confusión entre versiones de .NET Framework ocurre. No pude conseguirlo no para incluir estas rutas de ensamblaje.

Mi situación específica era que estaba intentando crear un ensamblado personalizado, sin embargo porque, aparentemente, tenía .NET 4.5 instalado en esta máquina, se quejaba al compilar sobre System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary y yo piensa uno otro.

Solución: La solución única llegué al trabajo era utilizar filtros Mole, que leí acerca de otros mensajes y en el sitio web de Microsoft Moles (hay un link especial para .NET 4.5 Solución de problemas en la principal página). En Visual Studio, simplemente agregué el ensamblado de Moles a mi proyecto de prueba unitaria para el conjunto personalizado de referencia haciendo clic con el botón derecho en Solution Explorer. Luego intenté construir. Por cada error que he recibido, he observado las clases ofensivas y los excluidos de ser calzar o del pie aplastado añadiendo lo siguiente a los topos del archivo:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/"> 
    <Assembly Name = "MyCustomAssembly" /> 
    <StubGeneration> 
    <Types> 
     <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" /> 
    </Types> 
    </StubGeneration> 
    <MoleGeneration> 
    <Types> 
     <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" /> 
    </Types> 
    </MoleGeneration> 
</Moles> 

Ahora claramente que no va a funcionar si necesidad las clases que estás excluyendo de la generación mole/stub, sin embargo, para mi caso funcionó bien porque las clases ofensivas no eran importantes y no necesitaría Stub o Shim nada en esas clases.