Миграция сайта на .NET 4.0

Published at November 19, 2010 ·  3 min read

Люди всегда делились на две категории: одни всегда “впереди планеты всей”, вторые их догоняют. В мире программирования всё происходит аналогично: одни используют новое ПО начиная с ранних CTP (Community Technology Preview) версий, вторые переходят на них, в лучшем случае, уже после релиза. Так сложилось и в ноём текущем проекте: .net framework 4.0 вышел достаточно давно, но перейти на него получилось только сейчас, и то не полностью.

Несмотря на то, что, как правило, переход на новую версию .net framework не вызывает особых проблем (код с 3.5 успешно работает в среде 4.0), некоторые нюансы всё же есть. Нише привожу описание шагов и проблем, с которыми столкнулся.

Visual Studio Debugger: одна интересная особенность

Published at July 21, 2010 ·  2 min read

Когда приложение работает в дебаггере, но не работает в релизной сборке и/или не тестовом сервере - достаточно частое явление, а вот чтоб наоборот - значительно реже. Вернее я на днях с этим столкнулся чуть ли не в первые.

Ситуация была довольно таки простая: есть некий wizard, шаги которого хранятся в поле типа Stack для удобного перемещения вперёд-назад. Естественно, в зависимости от текущего номера шага, нужно было выполнять определённые действия. И вот, после очередного багфикса, пришлось с помощь дебаггера разбираться что же там происходит… Но, при дебагге время от времени (в начале мне было абсолютно непонятно из-за чего это происходит) я получал: System.InvalidOperationException: Stack empty. И это при том, что без дебаггера всё работало! Чтоб разобраться в чем дело, я решил написать маленькое консольное приложение (исходники, как всегда, прикреплены к посту), которое состояло из объявления стека, его наполнения и свойства класса StackItem:

Visual Studio 2010 and .NET Framework 4 Beta 1 доступны для скачивания

Published at May 20, 2009 ·  0 min read

...

Visual Studio 2008: проблемы с генерацией .designer.cs для Web Application

Published at April 16, 2009 ·  1 min read

Вчера столкнулся с интересным моментом при генерации *.designer.cs-файлов. Сначала подумал что это баг, но после недолгих размышлений пришел к выводу, что это не баг, а фича (“багофича” (с)). 

Всё началось с того, что на одной из страниц сайта нужно было создать некоторую функциональность, которая уже была доступна дадругой странице. Сразу же было решено поместить эу функциональность в UserControl.После достаточно стандартных действий, copy&pase нужной разметки из страницы в только что созданный контрол, уже собирался писать в нём логину, но… Но студия ругалась на любое упоминание о вебконтроле, расположенном в mycontrol.ascx. “Странно” - подумал я и посмотрел содеримое файла mycontrol.ascx.designer.cs. В нём оказалось пусто. Тут же вспомнились похожие баги Visual Studio 2005 без установки на неё Service Pack 1 и было принято решение (как озакалось потом - ошибочное) руками дописать нужный код. Дописал. Сайт скомпилировался и даже попытался запуститься, но run-time ошибка не дала ему нормально функционировать.

Делаем Build правильно

Published at March 20, 2009 ·  2 min read

Осталось реализовать ещё несколько методов… Сейчас допишу последнюю строчку… Проект пока что не компилируется… Ура! Вот эта заветная строчка в окне Output Visual Studio:

========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

 Теперь предстоит запустить проект. Но все не так просто. Часто для проектов, которые больше чем знаменитый “Неllo World!” и который пишет команда из нескольких человек, необходимы какие-то условия для запуска:

- скопировать конфигурационный файл;			
- запустить веб-службу;			
- отправить письмо о успешном билде;			
- и т.д. и т.п.

Unit тесты и наследование

Published at December 23, 2008 ·  1 min read

При разработке unit тестов в Visual Studio часто хочется создать какой-то базовый клас для тестирования базовой лоники. Например у нас есть такой класс:

        [TestClass]         public class PersonTestBase         {             [TestMethod]             public virtual void GetNameTest()             {

                //…             }         }

 и его класс наследник:         [TestClass]     public class CustomerTest: PersonTestBase     {         [TestMethod]         public override void GetNameTest()         {             base.GetNameTest();         }     }

Configuration Section Designer - дизайнер настроек

Published at October 9, 2008 ·  1 min read

Почти год назад я писал о плагине для Visual Studio, под названием Visual Local History 2005 - мини система контролей версий на локальном компьютере. Не так давно на www.codeplex.com был найден очередной интересный, а главное - полезный, проект под названием Configuration Section Designer. 

После установки плагин добавляет новый тип проекта в Visual Studio, к котором подобно class diagram можно “рисовать” диаграммы конфигурационных файлов. После чего, плагин автоматически сгенерирует класс, который будет содержать в себе конфигурационную секцию, сделанную в диаграмме, доступ к настройкам будет состоять из доступа к свойствам класса.

Миграция unit tests на Visual Studio 2008

Published at March 3, 2008 ·  1 min read

При миграции unit-тестов с Visual Studio 2005 на 2008 (.net 2.0) обнаружил интересный баг. Студия радостно отрапортовала об успешной конвертиции проектов, но при запустке тесты проваливались с такой ошибкой:

Method SampleTest.ClassDBTest.MyClassInitialize has wrong signature. Parameter 1 should be of type Microsoft.VisualStudio.TestTools.UnitTesting.TestContext. 

WebApp и Visual Studio 2008

Published at January 20, 2008 ·  1 min read

В новой студии, по умолчанию, при создании веб-приложения на master page добавляется ещё один ContentPlaceHolder:

<br />
<head runat="server"><br />
<asp:ContentPlaceHolder ID="head" runat="server"><br />
</asp:ContentPlaceHolder><br />
</head><br />

<br />
<title> Untitled Page </title> <title>My page</title>


<br />
<li>Явно присвоить в коде свойству Title страницы название:<br />
Title = “My page”;</li><br />
<li>Указать атрибут страице:<br />
<%@ Page Language="C#" MasterPageFile="~/MyMaster.Master" AutoEventWireup="true" CodeBehind="MyPage.aspx.cs" Inherits="MySite.Pages" Title="My Page" %></li><br />
<li>Установить тег title:<br />
<blockquote>
	<br />
	<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server"><br />
	<title>My Page
</blockquote>
</li>

Локальная система контроля версий

Published at November 15, 2007 ·  2 min read

Если над проектом работает более одного человека, то рано или поздно наступает момент , когда им необходимо как-то обмениваться исходниками. Тут на помощь приходят CVS, SVN, Visual Source Safe, Team Foundation Server и другие. Одной из особенностей этих систем является то, что они хранят разные версии одних и тех же файлов. Стандартая ситуация: сдать файл в хранилище, сделать в нём изменения и… и достать себе более старую, но правильную версию. Эта система работает до одного момента: исходники не компилируются, а текущее их состояние надо зафиксировать. Раньше мне приходилось копировать изменяемые файлы в отдельные папки, чтобы иметь возможность в любой момент выбрать нужную мне версию. Недавно на www.codeplex.com/ нашел маленький (41), но очень полезный прокет - Visual Local History 2005. Он хранит все изменения файлов и даёт возможность в любой момент восстановить любую из доступных версий. После установки плагина для VS (поддерживается как Visual Studio 2005, так и 2008 Beta) в меню Tools появляется новый пункт меню, после выбора которого перед нами появляется окно плагина. При открытии или создании проекта или solution в его папке создаётска скрытая папка с именем “.history”, куда после каждого сохранения файла записывается его предыдущее состояние. Для восстановления нужной копии досточно лишь сделать правый клик по нужному файлу в окне Local History выбрать Restore. Простой интерфейс, скромный набор функций, но очень полезный плагин. Пользуюсь им уже около месяца и теперь не представляю как я раньше работал без него. Вместе с intellisense он экономит не только время, но и нервы. Всегда есть возможность посмотреть на то, как изменялся файл и вернуться к предыдущей точке. Как говорится, лучше один рах попробывать самому, а потом пользоваться этим каждый день.