Comment déboguer solution Sharepoint/fonctionnalité par le biais de Visual studio?

Récemment, j'ai essayé d'installer une webpart par wspbuilder utilitaire pour le Site Sharepoint. J'ai créé, construit et déployé un projet de la ruche 12. Après avoir installé la solution par le biais de l'Administration Centrale du Site et activé dans la collection de sites.

Je me demande juste comment puis-je déboguer le complexe fonctionnalité/solution ? Parce que les deux processus (build-déployer et activer) totalement indépendant, comment puis-je joindre un processus avec le processus de travail ?

Vous pouvez trouver ce que Sharepoint processus de attatch en utilisant les conseils dans la suite de blog-post par Abhijit Jana: abhijitjana.net/2010/07/15/...

OriginalL'auteur pointlesspolitics | 2010-04-05

  1. 3

    Dans le WSPBuilder menu contextuel, il ya une option "Attacher aux processus de travail IIS". Tant que l'application est chargé (signifie généralement que vous avez accédé à une page dans le site SharePoint avant d'essayer de les joindre) et le code déployé dans SharePoint est le même que le code que vous avez dans Visual Studio, vous devez être en mesure de définir des points d'arrêt et pas à travers le code.

    OriginalL'auteur Tom Clarkson

  2. 2

    Tout d'abord, vous devez ouvrir votre navigateur web et accédez au site web SharePoint en question. Puis, Dans Visual Studio, aller à Debug --> Attacher au Processus, et de trouver les w3wp.exe processus associé avec le site web Sharepoint que vous souhaitez déboguer. Cliquez sur (le processus), puis cliquez sur le bouton Joindre. Vous devriez maintenant être en mesure de débogage toutes les activités associées à votre fonctionnalité SharePoint.

    N'oubliez pas de mettre un point d'arrêt quelque part dans votre code!

    OriginalL'auteur jeremcc

  3. 2

    Parfois c'est un peu de douleur de comprendre le processus w3wp à vous attacher. Essayez d'ajouter les éléments suivants à votre code de percer dans le débogueur:

    System.Diagnostics.Debugger.Break();

    Donc, en utilisant le Système.Diagnostics.Débogueur.Pause(); signifie que vous n'avez pas à déterminer qui w3wp.exe processus est associé avec le site web Sharepoint? Sont là de toute façon pour déterminer ce le contraire?
    C'est correct, c'est tout automatique.
    Dois-je être en mode de débogage pour l'utiliser?
    Je crois que oui, mais je ne suis pas sûr à 100%. Je ne l'utilise que lors de l'exécution de Débogage.

    OriginalL'auteur Jeroen Ritmeijer

  4. 1
    System.Diagnostics.Debugger.Break()

    Comme Muhimbi suggéré, c'est effectivement très utile dans certains cas. Dites que vous souhaitez déboguer le code personnalisé (par exemple, feature_deactivating cas) quand il peut être invoquée avec stsadm et pas le navigateur. (par exemple, vous devrez utiliser la commande stsadm pour fonction de désactivation lorsque la fonctionnalité est caché dans l'INTERFACE utilisateur).Lors de l'utilisation de la commande stsadm vous ne pouvez pas vous joindre à cmd.exe parce que c'est un processus distinct. Si vous tapez la commande et appuyez sur entrée, puis trouver son id de stsadm.exe processus de connecter, c'est trop tard. Dans de telles situations, la commande ci-dessus est les plus faciles et la meilleure solution

    OriginalL'auteur Punit Vora

  5. 1

    J'ai essayé les étapes mentionnées ici

    aller à Debug --> Attacher au Processus, et de trouver les w3wp.exe processus associé avec le site web Sharepoint que vous souhaitez déboguer

    Mais je reçois des "points d'arrêt ne sera pas touché, pas de symboles ont été chargés de ce document". Dois-je enregistrer personnalisé déployé la solution dll à l'aide de GACUTIL ? Devrais-je avoir à copier les fichiers PDB à un endroit en particulier ?
    Ce qui me manque ici ?

    OriginalL'auteur Harish