it3xl.ru

Обычное исключение из компиляции не изменяемых проектов через  Build -> Configuration Manager (колонка Build напротив каждого проекта)  не единственный подход для ускорения компиляции в Visual Studio (VS). Другой способ, строится на том, что нужно отключить поведение Visual Studio по умолчанию, когда VS копирует сборки проектов, в проекты которые ссылаются на первые. Почему и как: Если проект A ссылается на проект B, то проект B компилируется первым. По умолчанию, сборка проекта B дублируется и кладется вместе со сборкой проекта A. Подход предлагает отключить копирование сборок проектов в Solution с помощью установки свойства референса на сборку Copy Local равным False, а также помещать все сборки в общую папку. Когда применять: Я бы использовал только для крайне больших солюшенов, когда более 5 - 10 проектов. Думаю, не стоить без нужды запутывать разработку. Реализация. Общее описание, которое подойдет для существующих проектов и для вновь создаваемых. Внимание! Не приступайте к р

 Merging assemblies приятная задачка, позволяющая на выходе получить один исполняемый файл или одну dll. Слияние (мерджинг) сборок можно выполнить двумя основными способами: Использовать утилиту слияния. Самая распространенная и бесплатная утилита, это утилита командной строки  ILMerge . Чтоб ее использовать, например, бросьте в папку главного проекта ILMerge.exe, потом зайдите в свойства этого проекта и в Buil Events пропишите в поле Post-buid events command line вызов этой утилиты, например так: "$(ProjectDir)ilmerge" /out: "$(ProjectDir) !Output \$(TargetFileName)" "$(TargetPath)" "$(TargetDir)Prived.Midved.dll" "$(TargetDir)WindowsProcessManager.dll" del "$(ProjectDir)!Output\$(ProjectName).pdb" Где ключ /out указывает куда класть не по умолчанию готовую сборку или экзешник. В нашем случае это будет папка  !Output в корне проекта. Потом перечисляются сборки, который нужно запихнуть в итоговый файл. Команда del в

Ну надо же, как приятно снова встретить старинный баг, плавно перекачевавшый теперь уже в Visual Studio 2010. Окно Watch не умеет интерпретировать XPath выражения содержащие &lt; и подобрые вещи, например выражение ServiceRow[position() &lt; = $Count] в окне Watch отобразиться как недопустимое. Полностью в XSLT файле это выглядит вот так: <xsl:variable name="MyVar" select=" ServiceRow[position() &lt; = $Count] "/> В тоже время то, что будет работать в Watch, нельзя вставить в XSLT / XPath, т.к. является некорректным XML: ServiceRow[position() <= $Count] Так что не профукайте ваше время впустую. Лично мой давний запрос, по поводу этого бага, тех. поддержка Microsoft плавненько слила. :)

Если IIS 6.0 не выгружает файлы с расширением .exe, то проверьте, чтоб в настройках каталога / сайта у вас НЕ стояло "Execute permissions" равное "Scripts and Executables". В этом случае еще ошибка "HTTP Error 404" будет отображаться.

На днях, встретил замерзшего индийского программиста в районе Ситроникса (Москва, метро Новослободская). У Ситроникса давние терки с Индией, поэтому я уверенно направил человека туда. При этом добрый индус с уверенностью сказал, что знает что такое МТС и Форис (для тех, кто в курсе). Оказалось соврал :) . Выяснилось, что человек шел устраиваться на работу в друге место и я самолично проводил его в евоную контору. Показательно, что конторка, видимо, маленькая.

Нашел баг XSLT и XPath в MSXML 4 . Видимо в версиях ниже он тоже есть. Если в XSLT-переменную xsl:variable положить набор нод, полученный с помощью XPath выражения preceding-sibling , то набор строк (Node Set) в этой переменной будет храниться не в том порядке, в котором он представлен в XML. Вроде, порядок нод будет обратный тогда. При этом, если перебирать Node Set напрямую в xsl:for-each, без присвоения набора в переменную xsl:variable, то все будет работать правильно. Утверждать не стану, т.к. уже не помню точно, но вроде это так. Получается в MSXML 4, preceding-sibling можно использовать только для получения количества элементов в наборе нод или для прямого перебора, но не для выборки элементов в переменную. Проиллюстрирую баг кодом. В следующей переменной FirstSecondThirdTables.Rows получим набор элементов ServiceRow, лежащих до ноды из переменной $FourthTable.Rows.First. Но порядок элементов в ней будет не такой, какой он в XML: <xsl:variable name="FirstSecon