script not debug debugging ssis breakpoints

debugging - not - Tarea de depuración de SSIS: el punto de interrupción está habilitado pero no se activa



debug ssis script task (12)

Estoy trabajando en un paquete SSIS. El paquete tiene una tarea de script (lenguaje C #). Necesito depurar la tarea de script. Puse el punto de ruptura. La secuencia de comandos en el editor de secuencias de comandos (Visual Studio) y la tarea en el editor de paquetes SSIS, ambos muestran el punto de interrupción en color rojo, lo que significa que el punto de interrupción está habilitado. Sin embargo, cuando depuro el paquete, el punto de ruptura no llega.

El punto de ruptura no tiene condiciones, por lo que espero que llegue cada vez que se ejecute el paquete.

Estoy utilizando Visual Studio 2008 en Windows 2003 R2 SP2 de 64 bits.

Además de la sugerencia de Jeff, también cambie el Objetivo de la plataforma a "x86" (En la pestaña Construir de las propiedades del script. FINALMENTE conseguí depurar nuevamente en un sistema de 64 bits.

Después de más investigación y error de prueba, se encontró que el paquete SSIS ignora los puntos de interrupción en una tarea de script al depurar en una máquina de 64 bits. Arreglarlo -

  1. Ir al Explorador de soluciones
  2. Haga clic derecho en el nodo de su proyecto SSIS> Propiedades
  3. En Propiedades de configuración> Depuración> Opciones de depuración> Establecer Run64BitRunTime en False .

Después de hacer este cambio, los puntos de ruptura golpean como magia.

En mi caso, ninguna de estas soluciones funcionó. Finalmente llegué a saber que el Resharper fue el culpable. Después de desinstalarlo, comenzó a funcionar como charm.

En mi caso, tuve que deshacerme de todas las características de C # 6: interpolación de cadenas, operadores condicionales nulos ( ?. , ?() ?[] ) Y miembros con cuerpo de expresión ( => ) (puede haber más en su caso). Puedes consultarlos todos here . Por supuesto, lo mismo se aplica a las características de C # 7.

Los cambios de 32/64 bits de otras respuestas no ayudaron, así que hice retroceder esos y la depuración siguió funcionando bien.

En mi experiencia, no importa:

  • si Run64BitRuntime es verdadero o falso
  • Si construyes la versión de 32 o 64 bits de tu paquete.

Pero hay algo muy importante, que no se menciona en ninguna otra respuesta: debe ejecutar todo el paquete . Si ejecuta una tarea o un contenedor, el punto de interrupción se ignorará.

Estoy usando Visual Studio 2013, en una máquina de 64 bits.

Heredé un paquete SSIS donde, desafortunadamente, las respuestas anteriores no ayudaron.

Al final, encontré que las propiedades de compilación de la tarea de script para el modo de depuración tenían el código de optimización marcado. Asegúrese de que esto no esté marcado porque para mí Visual Studio se iniciaría para la depuración de secuencias de comandos y se cerraría poco después sin romper nada.

Bastante oscuro pero vale la pena mencionar.

Intenté todas las respuestas proporcionadas aquí sin éxito (utilizando VS2015). Después de buscar más, encontré esta pregunta que en realidad es una respuesta que indica que las características / sintaxis más nuevas de C # estaban causando que el depurador no se activara correctamente.

En su ejemplo (y también en el mío), el uso de la interpolación de cadenas hacía que los puntos de interrupción no fueran alcanzados.

Reemplazo

$"{someVariable} - {someOtherVariable}"

con

string.Format("{0} - {1}", someVariable, someOtherVariable);

hizo el truco para mí

Mis puntos de ruptura se negaron a golpear, no importa lo que hice. Terminé depurando y solucionando los problemas simplemente usando lanzamientos de excepción. Una vez que solucioné los problemas que estaba teniendo, ¡los puntos de ruptura comenzaron a llegar!

Así que mis puntos de interrupción solo llegarían una vez que el código no experimentara ningún problema de tiempo de ejecución ... lo que es extraño.

Nos topamos con el mismo problema recientemente. Para nosotros, la solución fue garantizar que el proyecto de tarea de secuencia de comandos estuviera marcado para ejecutarse como con el objetivo de la plataforma establecido en x86.

  1. Editar la tarea de script
  2. Haga clic en el proyecto y seleccione propiedades.
  3. Seleccione para establecer el objetivo de la plataforma a x86

Solo tuve un componente de Script donde no se alcanzaron puntos de interrupción (estaba haciendo algo de CRM sin necesidad de origen / destino). Tridé agregar un componente de Source con un simple fetchXML (incluso si no lo necesitaba). Entonces funcionó! :-)

Use la clase System.Diagnostics.Debugger para agregar puntos de interrupción programáticamente:

System.Diagnostics.Debugger.Launch(); System.Diagnostics.Debugger.Break();

Puede verificar si el depurador está adjunto o no:

if (System.Diagnostics.Debugger.IsAttached) System.Diagnostics.Debugger.Break();

Siga estos pasos:

  1. Mantenga su proyecto o solución abierta.
  2. Ejecute su aplicación para golpear el punto de interrupción.
  3. Seleccione su proyecto en Just-In-Time Debugger .

Actualización : Chicos, una vez perdí la capacidad de establecer puntos de interrupción (una solicitud a MS)
Mis arreglos anteriores están abajo.
Ahora estoy usando el registro y el rastreo en lugar de la depuración.

Se culpa a las nuevas características de C # (después de C # 4.0) por matar la depuración de la tarea de secuencia de comandos de SSIS.

Para devolver la capacidad de punto de interrupción hago lo siguiente.

  1. Eliminar C # nuevas características
  2. Ejecutar mi tarea de script una vez, con éxito. Es decir, sin un choque.
  3. Vuelva a abrir el Proyecto Vsta desde mi tarea de script y coloque puntos de interrupción allí.

Al final, tienes que ver un círculo rojo en tu tarea de secuencia de comandos.
(Probado en VS 2017.)

Nota Tengo que mencionar que la depuración funciona incluso si usa "Ejecutar tarea" solamente, no "Ejecutar paquete".

Eliminar C # nuevas características

Para eliminar las nuevas funciones de C #, puedo aconsejarle de dos maneras.

Primero , restrinja las propiedades del proyecto Vsta a C # 4.0 (los paquetes migrados pueden no admitir esto).

  1. Dobule haga clic en su "Tarea de script" para abrir el "Editor de tarea de script".
  2. Haga clic en el botón "Editar script ..." para abrir Visual Studio.
  3. En "Explorador de soluciones", seleccione el proyecto y haga clic en la tecla F4 de su teclado.
  4. En la ventana "Propiedades" abierta en la opción "C # Language Level" "C # 4.0"
  5. Construye tu proyecto y arregla errores de compilación .

En segundo lugar , los proyectos Vsta en paquetes antiguos / migrados pueden no mostrar la propiedad anterior "Nivel de idioma C #".
Así que puedes poner tu código en un proyecto falso en Visual Studio 2010 y compilarlo allí.

Ejecutarlo una vez con éxito

Después de que arregles tu C #, debes ejecutar tu tarea de script una vez con éxito.
Es posible que desee colocar la declaración de return al comienzo del método Main() para evitar cualquier ejecución real.
Lo sentimos , esto no siempre funciona y no me doy cuenta de por qué, pero definitivamente necesitas arreglar tu C # en primer lugar.
Al menos obtendrá una tarea de script que funciona y puede depurarla de una manera antigua (registros por Dts.Events... , excepciones, etc.)

TL; DR

Parece que incluso tuve casos graves cuando las nuevas características de C # forzaron las Tareas de script a fallar silenciosamente con un estado de finalización exitosa.

Como ejemplo, agregue lo siguiente a su tarea Script.

string Bug { get; } // Only getter properties. //... var str = $"Now is {DateTime.Now}"; // String Interpolation in C# //... var dummy = val?.ToUpper(); // ?. and ?[] null-conditional Operators

Y soluciones para esta lista no completa:

string Bug { get; set; } //... var str = string.Format("Now is {0}", DateTime.Now); // etc.

Lo que también hago, compilo mi código C # en Visual Studio 2010 . Simplemente no compila las nuevas características de .NET y no permite las versiones de .NET Framework por encima de 4.0. Hasta ahora tan bueno.

Por supuesto, otras respuestas de esta pregunta SO no me ayudaron.