web-dev-qa-db-fra.com

Débogage de la tâche de script SSIS - Le point d'arrêt est activé mais ne touche pas

Je travaille sur un package SSIS. Le paquet comporte une tâche de script (langage C #). Je dois déboguer la tâche de script. Je fixe le point de rupture. Le script dans l'éditeur de script (Visual Studio) et la tâche dans l'éditeur de package SSIS affichent tous deux le point de rupture en rouge - signifie que le point de rupture est activé. Cependant, lorsque je débogue le package, le point d'arrêt n'est pas atteint. 

Le point de rupture n'a pas de conditions, je m'attends donc à ce qu'il se produise chaque fois que le package est exécuté.

J'utilise Visual Studio 2008 sur Windows 2003 R2 SP2 64 bits.

debuggingssisbreakpoints
18
HappyTown

Après davantage de recherches et d'erreur d'essai, nous avons constaté que le package SSIS ignorait les points d'arrêt d'une tâche de script lors du débogage sur un ordinateur 64 bits. Réparer -

  1. Aller à l'explorateur de solutions 
  2. Cliquez avec le bouton droit sur votre nœud de projet SSIS> Propriétés
  3. Dans Propriétés de configuration> Débogage> Options de débogage> Définissez Run64BitRunTime sur False.

SSIS Project configuration settings

Après avoir effectué ce changement, les points d'arrêt ont frappé comme par magie.

24
HappyTown

J'ai essayé toutes les réponses fournies ici sans succès (avec VS2015). Après quelques recherches supplémentaires, j'ai trouvé cette question qui est en fait une réponse qui indiquait que les nouvelles fonctionnalités/syntaxe C # empêchaient le débogueur de se déclencher correctement.

Dans leur exemple (et aussi le mien), l'utilisation de l'interpolation de chaîne empêchait les points d'arrêt d'être atteints.

Remplacement

$"{someVariable} - {someOtherVariable}"

avec

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

a fait le tour pour moi.

11
PTD

Mise à jour: Les gars, j’ai perdu toute possibilité de définir des points d'arrêt (demande à MS)
Mes corrections précédentes sont ci-dessous.
Maintenant, j'utilise la journalisation et le traçage au lieu du débogage.

Les nouvelles fonctionnalités C # (après C # 4.0) sont mises en cause pour avoir mis fin au débogage de la tâche de script SSIS.

Pour retourner la capacité du point d'arrêt, procédez comme suit.

  1. Supprimer les nouvelles fonctionnalités de C #
  2. Exécuter ma tâche de script une fois, avec succès. C'est à dire. sans accident.
  3. Rouvrez le projet Vsta à partir de ma tâche de script et mettez-y des points d'arrêt.

À la fin, vous devez voir un cercle rouge sur votre tâche de script.
(Testé dans VS 2017.)

 enter image description here

Remarque. Je dois mentionner que le débogage fonctionne même si vous utilisez uniquement "Exécuter la tâche", pas "Exécuter le paquet"!

Supprimer les nouvelles fonctionnalités de C #

Pour supprimer les nouvelles fonctionnalités de C #, je peux vous conseiller de deux manières.

First, restreignez les propriétés du projet Vsta à C # 4.0 (les packages migrés peuvent ne pas le supporter).

  1. Dobule cliquez sur votre "tâche de script" pour ouvrir "l'éditeur de tâche de script".
  2. Cliquez sur le bouton "Edit Script ..." pour ouvrir Visual Studio.
  3. Dans "Explorateur de solutions", sélectionnez le projet et cliquez sur la touche F4 de votre clavier.
  4. Dans la fenêtre "Propriétés" ouverte dans "Niveau de langue C #", choisissez "C # 4.0"
  5. Construisez votre projet et corrigez les erreurs de compilation .

Deuxièmement, les projets Vsta dans des packages anciens/migrés peuvent ne pas afficher la propriété "Niveau de langage C #" ci-dessus.
Vous pouvez donc insérer votre code dans un faux projet dans Visual Studio 2010 et le compiler ici.

Exécuter une fois avec succès

Après avoir corrigé votre C #, vous devez exécuter votre tâche de script une fois avec succès.
Vous voudrez peut-être mettre l'instruction return au début de la méthode Main() pour empêcher toute exécution réelle.
Désolé, cela ne fonctionne pas toujours et je ne comprends pas pourquoi, mais vous devez absolument réparer votre C # en premier lieu.
Au moins vous obtiendrez une tâche de script opérationnelle et pourrez la déboguer de manière ancienne (journaux par Dts.Events..., exceptions, etc.).

TL; DR

Il semble que j'ai même eu des cas graves où de nouvelles fonctionnalités de C # ont forcé les tâches de script à échouer en silence avec un statut d'achèvement.

Par exemple, ajoutez ce qui suit à votre tâche de 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

Et des solutions de contournement pour cette liste non complète:

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

Ce que je fais aussi, je construis mon code C # dans Visual Studio 2010. Il ne compile simplement pas les nouvelles fonctionnalités .NET et n'autorise pas les versions de .NET Framework supérieures à 4.0. Jusqu'ici tout va bien.

Bien sûr, les autres réponses de cette question SO ne m'ont pas aidé.

10
it3xl

Utilisez System.Diagnostics.Debugger class pour ajouter un point d'arrêt par programme:

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

Vous pouvez vérifier si le débogueur est attaché ou non:

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

Suivez ces étapes:

  1. Gardez votre projet ou votre solution ouverte.
  2. Exécutez votre application pour atteindre le point d'arrêt.
  3. Sélectionnez votre projet dans le débogueur Just-In-Time .  Just-In-Time Debugger snapshot
5
Shadmehr

J'ai hérité d'un paquet SSIS où, malheureusement, les réponses ci-dessus n'ont pas aidé. 

Finalement, j'ai trouvé que les propriétés de construction de la tâche de script pour le mode débogage avaient le code d'optimisation coché. Assurez-vous que cela n'est pas coché, car pour moi, Visual Studio se lancerait dans le débogage du script et se fermerait peu de temps après sans se rompre.

 Make sure Optimize code is not ticked

Assez obscure mais mérite une mention.

4
Jeff

Nous avons rencontré le même problème récemment. Pour nous, la solution consistait à nous assurer que le projet de tâche de script était marqué pour s'exécuter comme avec la cible de plate-forme définie sur x86.

  1. Modifier la tâche de script
  2. Cliquez sur le projet et sélectionnez les propriétés
  3. Sélectionnez pour définir la cible de la plate-forme sur x86.
3
Ben Watt

Dans mon cas, je devais me débarrasser de toutes les fonctionnalités de C # 6: interpolation de chaîne, opérateurs conditionnels nuls (?., ?(), ?[]) et membres avec expression (=>) (il pourrait y en avoir plus dans votre cas). Vous pouvez les vérifier tous ici . Bien entendu, il en va de même pour les fonctionnalités C # 7.

Les modifications 32/64 bits des autres réponses n’ont pas aidé, aussi j’ai annulé ces modifications et le débogage a continué à bien fonctionner.

3
Andrew

Dans mon cas, aucune de ces solutions n'a fonctionné. J'ai finalement appris que le Resharper était le coupable. Après l'avoir désinstallé, il a commencé à fonctionner comme un charme. 

3
Sumanth

En plus de la suggestion de Jeff, changez également la cible de la plate-forme en "x86" (dans l'onglet "Construire" des propriétés du script. Ceci m'a finalement permis de déboguer à nouveau sur un système 64 bits.

2
Kurt S

D'après mon expérience, cela n'a pas d'importance:

  • si Run64BitRuntime est true ou false
  • si vous construisez la version 32 ou 64 bits de votre paquet

Mais il y a quelque chose de très important, qui n'est mentionné dans aucune autre réponse: vous devez exécuter le package complet . Si vous exécutez une tâche ou un conteneur, le point d'arrêt sera ignoré.

J'utilise Visual Studio 2013 sur une machine 64 bits.

0
JotaBe

Je n'avais qu'un seul composant de script pour lequel aucun point d'arrêt n'avait été touché (je faisais des choses de CRM sans avoir besoin de source/cible) . .__ Ensuite, cela a fonctionné! :-)

0
Marius Holm Enerud

Mes points d'arrêt ont refusé de frapper, peu importe ce que j'ai fait. J'ai fini par déboguer et résoudre les problèmes en utilisant uniquement des exceptions. Une fois que j'ai résolu les problèmes que je rencontrais, les points d'arrêt ont commencé à frapper!

Ainsi, mes points d'arrêt ne frappaient que lorsque le code ne rencontrait aucun problème d'exécution ... ce qui est bizarre.

0
creatiive