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.
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 -
Run64BitRunTime
sur False
.Après avoir effectué ce changement, les points d'arrêt ont frappé comme par magie.
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.
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.
À la fin, vous devez voir un cercle rouge sur votre tâche de script.
(Testé dans VS 2017.)
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).
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é.
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:
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.
Assez obscure mais mérite une mention.
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.
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.
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.
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.
D'après mon expérience, cela n'a pas d'importance:
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.
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é! :-)
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.