visual-studio-2010 - las mejores extensiones para visual studio 2017
¿Cómo puedo hacer un perfil de los ensamblados firmados con VS 2010 o VS 2013? (6)
El perfilador probablemente cambia el ensamblaje y porque fue firmado previamente. Al parecer, debe agregar una acción posterior al instrumento que vuelva a firmar el ensamblaje.
Esto podría ser un problema porque no tiene el archivo sn que se utilizó para firmar los ensamblados de terceros.
Tengo un sitio web que utiliza AjaxControlToolkit.dll y Log4Net.dll.
Cuando intento ejecutar la herramienta de generación de perfiles de rendimiento en VS 2010, aparece la siguiente advertencia:
AjaxControlToolkit.dll está firmado e instrumentando invalidará su firma. Si continúa sin un evento posterior al instrumento para volver a firmar el binario, es posible que no se cargue correctamente.
Ahora, si elijo la opción para continuar sin volver a firmar, el perfilado se inicia pero el ensamblaje no se carga y da una excepción de ASP.NET.
La forma más sencilla de obtener el trabajo de instrumentación en binarios firmados, que no se hayan vuelto a firmar, es deshabilitar por completo los controles de firmas. Esta es una configuración para toda la máquina que puede activar registrando una excepción para el patrón * :
sn.exe -Vr *
Este comando debe ejecutarse desde un símbolo del sistema elevado. Encontrará sn.exe en el SDK (en mi caso, lo encontré en C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Bin ).
Cuando haya terminado con las pruebas, debe anular el registro de la excepción:
sn.exe -Vu *
o de lo contrario, su máquina podría ser vulnerable a códigos maliciosos, ya que los ensamblajes serán confiables incluso si se han manipulado.
Vea también Acceso denegado ejecutando sn.exe en Windows 7 .
La respuesta se describe aquí . Debe utilizar un evento posterior al instrumento en cada ensamblaje firmado.
No pude lograr que funcionara "tal como está" con mi instalación de VS 2010. Tuve que llamar a esta línea de comandos como un evento posterior a la compilación en cada dll:
"C:/Program Files/Microsoft Visual Studio 10.0/VC/vcvarsall.bat" & sn -Ra [pathOfDll] [pathOfSNK]
Tenga en cuenta que [pathOfDll] se encuentra en el directorio obj / Debug asociado al proyecto.
Podría haber tomado la forma de aprender cosas nuevas sin hacer nada, pero terminé resolviendo esto escribiendo un script de powershell para anular todos los proyectos en mi solución, funcionó bien. Como parte del script, guardo los archivos csproj originales para poder revertirlos después. (También podría simplemente deshacer los cambios en el control de código fuente).
debe poder revertir llamándolo pasando el interruptor -revert.
ghusse vinculado a una entrada de blog dando la respuesta . La respuesta se describe allí. Como él señala, usted tiene que usar un evento post-instrumento en cada ensamblaje firmado.
Es más fácil llamar a sn.exe directamente:
"C:/Program Files/Microsoft SDKs/Windows/v7.0A/bin/sn.exe" -R [pathOfDll] [pathOfSNK]
Tenga en cuenta que [pathOfDll] se encuentra en el directorio obj / Debug asociado al proyecto.
Si está haciendo esto en una máquina de desarrollo, puede deshabilitar la verificación de nombre sn -Vr * conjunto con sn -Vr * . Si haces esto, no tienes que renunciar a nada. Este enfoque puede ser un riesgo de seguridad, pero si se siente cómodo con él , es más fácil que renunciar.
Específicamente, desde MSDN , dice:
Registros de montaje para la verificación de saltos. Opcionalmente, puede especificar una lista de nombres de usuario separados por comas. Si especifica infile, la verificación permanece habilitada, pero la clave pública en infile se usa en las operaciones de verificación. El ensamblaje se puede especificar en la forma *, strongname para registrar todos los ensamblajes con el nombre seguro especificado. Strongname debe especificarse como la cadena de dígitos hexadecimales que representan la forma en token de la clave pública. Consulte las opciones -t y -T para mostrar el token de clave pública.
Y el riesgo de seguridad:
Precaución: Utilice esta opción solo durante el desarrollo. Agregar un ensamblaje a la lista de verificación de omisión crea una vulnerabilidad de seguridad. Un ensamblaje malintencionado podría usar el nombre del ensamblaje completamente especificado (nombre del ensamblado, versión, cultura y token de clave pública) del ensamblado agregado a la lista de verificación de omisión para falsificar su identidad. Esto permitiría que el ensamblaje malicioso también omita la verificación.