All about IT

Сегодня вышел Community Technical Preview VSeWSS 1.1. Наконец-то появился инструментарий для создания solutions (.WSP-файлов), application-страниц (в папке _layouts) и еще несколько полезных фич.

Помимо встроенной трассировки (через TraceContext), в ASP.NET можно использовать стандартные возможности трассировки, предоставляемые .NET Framework’ом. К таковым относятся классы System.Diagnostics.Trace и System.Diagnostics.Debug. Каждый из этих классов содержит одинаковый набор статических методов (Write, WriteLine и т.п.), отмеченных атрибутом ConditionalAttribute. Атрибут работает следующим образом: если при компиляции символ, который был ему передан в качестве параметра, не определен, то все вызовы метода, на котором висит атрибут, зануляются (преобразуются в nop). Для методов класса Debug атрибут ConditionalAttribute инициализирован символом “DEBUG“, для Trace - соответственно, “TRACE“.

По умолчанию, для обычных проектов (WinApp, Library и т.п.) в конфигурации Debug определены оба символа, а в Release - только символ TRACE. Увы и ах, но это правило не распространяется на веб-проекты в Visual Studio 2005. Связано это с несколько извратной моделью компиляции веб-сайта, но вдаваться в подробности я не хочу. Скажу только, что по умолчанию, символ TRACE не определен ни в режиме сборки Debug, ни в Release, т.е. вызов к System.Diagnostics.Trace.Write…() не происходит. Как же с этим бороться? Есть три способа, разной степени сложности.

1. Web Deployment Projects (или любой собственноручно написанный MSBuild-файл). В таком проекте можно поиграться с автоматической заменой web.config’а или с различными опциями компиляции (но только напрямую в тексте файла, графический интерфейс VS2005 этого не умеет).
2. Web Application Project. По сути это шаблон проекта, позволяющий создавать web-приложения в VS2005 так же, как это делалось в VS2003. К сожалению, при этом мы лишаемся всех бонусов 2005-й студии, типа встроенного веб-сервера для отладки. (Upd.: Web Application Project теперь входит в VS 2005 SP1, отдельно его скачивать не надо).
3. Правка web.config’а нашего приложения. Для определения символа TRACE к нему надо добавить вот такой кусок кода (внутрь элемента ):

<system.codedom>
	<compilers>
		<compiler language="c#;cs;csharp"
			 extension=".cs"
			 compilerOptions="/d:TRACE"
		  	 type="Microsoft.CSharp.CSharpCodeProvider, System,
			      Version=2.0.3500.0, Culture=neutral,
			      PublicKeyToken=b77a5c561934e089" warningLevel="1" />
		<compiler language="VB"
			 extension=".vb"
			 compilerOptions="/d:Trace=true"
			 type="Microsoft.VisualBasic.VBCodeProvider, System,
			      Version=1.0.5000.0, Culture=neutral,
			      PublicKeyToken=b77a5c561934e089" />
	</compilers>
</system.codedom>

Таким же образом можно определять и другие символы (помимо DEBUG и TRACE). Есть только одна проблема: содержимое web.config’а не зависит от режима сборки (Debug/Release/…). В более сложных ситуациях может потребоваться несколько его копий, либо скрипт, заменяющий содержимое в зависимости от режима сборки проекта.

Трассировка веб-приложения, которая является крайне удобным средством отладки и мониторинга, выключена по умолчанию в VS 2005. К счастью, есть несколько вариантов решения этой проблемы; выбор одно из них зависит от условий разработки и личных предпочтений программиста. Надеюсь, что информация в этой записи позволит кому-то сэкономить несколько седых волос с головы и мучительных часов в отладке.

Technorati Tags: ASP.NET, Trace, Visual Studio

На днях угробил порядка 4 часов своей драгоценной жизни на то, чтобы обеспечить возможность удаленной отладки программы, запускаемой на виртуалке. Представленный ниже сценарий является результатом этих “танцев с бубном”, поэтому не претендует ни на полную достоверность, ни на необходимость выполнения всех пунктов. Это, с одной стороны, памятка лично мне, а с другой - вдруг кому пригодится?

Итак, имеем следующую ситуацию. Стенд разработки и отладки состоит из 3 машин:

1. WXP-HOST - основная машина (в моём случае это был ноутбук). На ней установлена Windows XP Pro SP2, Visual Studio 2005 и система виртуализации (Virtual PC/Server или VMWare, это не важно). Не является членом домена.
2. VR-DC - виртуальная машина - контроллер домена DOM1. ОС Windows Server 2003.
3. VR-2K - виртуальная машина - член домена DOM1. ОС Windows 2000 Pro SP4. Именно на этой машине должна производиться отладка.

Все 3 машины находятся в рамках одной сети, видят и пингуют друг друга. Это исходные условия, теперь перейдем к самому процессу настройки.

1. На WXP-HOST отключаем все файрволы. Формально это не обязательно, в MSDN написано, какие порты надо открывать. На практике же возиться с встроенным XP’шным файрволом нет никакого желания. Если на машине, где предстоит запускать программу для отладки, стоит Windows XP SP2, то так же отключаем файрвол.
2. Создаем учетным записи.
   1. Предположим, что на WXP-HOST я работаю под учетной записью WXP-HOST\Dmitriy.
   2. В домене создаем учетку DOM1\Dmitriy с тем же паролем, что и WXP-HOST\Dmitriy (здесь и далее, у одноименных учетных записей должны быть одинаковые пароли!). Заносим её в группу администраторов (Domain Admins).
   3. Локально на VR-2K создаем локальную учетную запись VR-2K\Dmitriy, заносим её в группу локальных администраторов (Administrators).
3. Настраиваем политики безопасности в домене и на локальных машинах.
   1. На контроллере домена, в Administrative Tools запускаем Domain Security Policy. Далее Security Settings (корень) -> Local Policies -> Security Options -> Network access: Sharing and security model for local accounts. Выбираем Classic - local users authenticate as themselves.
   2. На недоменной машине (WXP-HOST) те же настройки доступны через Control Panel -> Administrative Tools -> Local Security Policy.
4. Настраиваем DCOM на машине, где будет запускаться отладочная программа. Запускаем dcomcnfg. Для Win2K во вкладке “Безопасность по умолчанию” даём локальным и доменным админам все возможные права. Для WinXP: Component Services -> Computers -> My Computer -> Properties -> COM Security -> Access Permissions -> Edit Limits. Дать права всем заинтересованным лицам, т.е. тем же админам. В крайнем случае, может потребоваться дать права Remote Access ANONYMOUS LOGON’у.
5. Устанавливаем на отладочной машине (VR-2K) монитор удаленной отладки (в дистрибутиве Visual Studio в папке vs\Remote Debugger\x86 для 32-битной платформы). Принципиальной разницы между запуском его в контексте службы или в интерактивном режиме нет, но мне удобнее пользоваться службой. В любом случае, монитор должен быть запущен в контексте локальной учетной записи (в рассматриваемом сценарии - VR-2K\Dmitriy). Таким образом, у этой учетки должны быть права Logon as Service. Это настраивается либо в Local Security Policy, либо автоматически при настройке учетной записи службы.

После этих телодвижений удаленная отладка на моём стенде заработала.

Еще раз скажу, что всё, описанное выше, это результат танцев с бубном в течении 4 часов. Не факт, что все настройки обязательны. Можно не отключать файрволы, а аккуратно открыть на них необходимые порты. В общем, вариантов много, я лишь привел тот, который для моей конфигурации оказался работоспособным.

Technorati Tags: Visual Studio, Remote Debug