Отладка кода SharePoint 2007
Как вы отлаживаете свой код SharePoint 2007? Поскольку SharePoint работает на удаленном сервере, а я разрабатываю на компьютере с Windows XP (с необходимыми файлами .dll, скопированными в мой GAC), мне не очень повезло с поиском простых способов отладки. Точки останова не работают и т. д.
Лучший способ, который я придумал, - включить трассировку страниц в файле web.config, писать сообщения трассировки во всем моем коде и обращаться к trace.axd всякий раз, когда мне нужно отлаживать.
Есть ли у кого-нибудь лучшие предложения по отладке? Я что-то упускаю?
Ответы 5
От Сообщение в блоге Эндрю Коннелла по теме:
Attaching the debugger to GAC'd assemblies: "Why aren't my breakpoints being hit?!?!" Ever been there? Me too... what a PITA that is! What's going on? Well, the assemblies are in the GAC and the Visual Studio debugger can't see the debugging symbols (aka: *.pdb). Unless you've gone through the trouble of setting up a symbol store where all your PDBs are going, you'll need to put the debugging symbols in the same location as the assembly. The trick is finding the folder that contains your DLL in the GAC.
The c:\windows\assembly folder is not a real folder, it's a virtual folder. To get to the REAL folder, do the following:
- Start » Run
- %systemroot%\assembly\gac [ENTER]
This will open the GAC folder. Now, poke around until you find a folder that looks like this (you might need to jump up one folder and dive into the MSIL folder): [assembly file name -.DLL extention][assembly version in format of > #.#.#.#]__[assembly public key token].
When you find that folder, open it up and you'll see your assembly. Copy the PDB file to that folder and then attach the debugger for some debugging joy!
Я рекомендую вам разрабатывать на сервере Windows 2003 с Sharepoint. Отладка на удаленном сервере затруднительна. Вы можете сделать это на виртуальной машине с VMWare или Virtual PC, если на вашей рабочей станции стоит XP.
Виртуальная машина - единственный выход. Вы не хотите посвящать разработке целую машину (если у вас нет дополнительных функций), а разработка на вашем производственном сервере просто вызывает проблемы. Я предпочитаю VMWare, но есть и другие, которые работают так же хорошо.
Трассировка работает хорошо, поскольку обычная отладка на самом деле не вариант.
Что еще я делаю, так это пытаюсь разработать всю логику (не зависящую от SharePoint) только на обычном сайте asp.net, а затем интегрировать ее в тестируемый SharePoint после.
Надеюсь, это имеет смысл.
Вы говорите о разработке веб-частей? Пользовательские страницы? Что-то другое?
Эмм - использование виртуальных машин не имеет отношения к вопросу об источнике (хотя они очень и очень полезны)
Почему нормальная отладка - не вариант? Кажется, у меня все время получается неплохо :)
Я знаю, я просто подумал, что брошу это туда. Я объяснял, что сначала пытаюсь выполнить отладку в моей обычной среде, отличной от SharePoint (Visual Studio), поскольку отладка в среде SP затруднена.
Лучший способ (даже тот, который одобрен Microsoft) - иметь Windows 2003 Server с Sharepoint в качестве локальной машины для разработки.
См. Также Эта тема.
Не помещайте свои сборки в GAC, помещайте их в каталог bin - тогда вы можете использовать удаленный отладчик VS. Google создает файлы .WSP для распространения.
Это также имеет то преимущество, что легче копировать ваши новые сборки на сервер после компиляции (этап после сборки), а также это рекомендуемый способ повышения безопасности.
Иногда отказ от сборки сборки - не лучший вариант. Особенно, когда вы говорите о необходимости переработать свой ПОБВ и повторно развернуть его. это может быть болезненный процесс, если вы просто пытаетесь отладить разовую ошибку, которую вы не можете найти другим способом (проблема, с которой я столкнулся сейчас).
Вы также можете отлаживать сборки в GAC удаленного компьютера при подключении к процессу, если этот PDB находится в выходном каталоге на вашем локальном компьютере текущего проекта. Я все время отлаживаю сборки MOSS в GAC на удаленных машинах, не копируя PDB в GAC.