Перейти к вопросу →

Начиная с версии 4.3.2, StyleCop поддерживает возможность игнорирования правила с помощью стандартного атрибута SuppressMessage. Используется атрибут так:

[SuppressMessage("Категория правила", 
    "Идентификатор правила", Justification = "Пояснение")]

Где

• Категория правила — пространство имен, в котором определено правило, например, Microsoft.StyleCop.CSharp.DocumentationRules или Microsoft.StyleCop.CSharp.ReadabilityRules
• Идентификатор правила — уникальный идентификатор правила в формате КраткоеИмя:ПолноеИмя. КраткоеИмя можно увидеть в списке ошибок/предупреждений, а ПолноеИмя придется искать в документации. Например, SA1600:ElementsMustBeDocumented или SA1118:ParameterMustNotSpanMultipleLines
• Пояснение — текст, поясняющий причину игнорирования правила.

Атрибут SuppressMessage может быть применен к классу или методу. При этом будут игнорироваться сообщения для всего класса или для отдельного метода соответственно.

Перейти к вопросу →

Если нужно прочитать xml файл большого размера, и не хочется загружать весь этот файл в память, то нужно использовать XmlReader. Этот класс позволяет читать XML в манере близкой к SAX. Итератор пробегает по всем элементам дерева, а пользователю нужно определить как обрабатывать каждый из таких элементов. Пример:

XmlTextReader textReader = new XmlTextReader("file.xml");
while (textReader.Read())
{
    XmlNodeType nType = textReader.NodeType;
    if (nType == XmlNodeType.XmlDeclaration)
    {
        // ...
    }
    if (nType == XmlNodeType.Comment)
    {
        // ...
    }
    if (nType == XmlNodeType.Attribute)
    {
        // ...
    }
    if (nType == XmlNodeType.Element)
    {
        // ...                
    }
    if (nType == XmlNodeType.Entity)
    {
        // ...                
    }
    if (nType == XmlNodeType.Entity)
    {
        // ...                
    }
    if (nType == XmlNodeType.DocumentType)
    {
        // ...                
    }
    if (nType == XmlNodeType.Whitespace)
    {
        // ...                
    }
}

Перейти к вопросу →

Castle предоставляет пакет интеграции с Visual Studio — Castle Visual Studio Integration (CVSI). В текущей версии он содержит как раз только расширение для подсветки синтаксиса NVelocity. Есть один недостаток — считается что файл шаблона (*.vm) должен содержать XML. Поэтому, всю силу автодополнения можно почувствовать только если шаблон используется для генерации HTML/XML.

Перейти к вопросу →

Если у вас есть такой код (это из реального приложения):

TestIssue = new Issue(Id, ProjectId, ProjectName, Code, Title,  
    Description, CategoryId, CategoryName, PriorityId,
    PriorityName,PriorityImageUrl, StatusId, StatusName, 
    StatusImageUrl, IssueTypeId, IssueTypeName,IssueTypeImageUrl,
    ResolutionId, ResolutionName,ResolutionImageUrl, 
    AssignedDisplayName, AssignedUsername, AssignedUserId,
    CreatorDisplayName, CreatorUsername, CreatorUserId, 
    OwnerDisplayName, OwnerUsername, OwnerUserId, DueDate, 
    MilestoneId, MilestoneName, MilestoneImageUrl, 
    MilestoneDueDate, AffectedMilestoneId, AffectedMilestoneName, 
    AffectedMilestoneImageUrl, Visibility, TimeLogged, Estimation, 
    DateCreated, LastUpdate, LastUpdateUsername, 
    LastUpdateDisplayName, Progress, Disabled, Votes);

То, наверное, стОит задуматься о property injection) Кому интересно, но не хочется считать — конструктор принимает 47 аргументов.

Перейти к вопросу →

Microsoft выпускает кучу библиотек и тулов, покрывающих все аспекты разработки, но иногда это незрелые решения. Есть мнение, что зачастую в Microsoft пишут продукты «чтобы было» а не «чтобы сделать что-то полезное».

Вот как Scott Bellware (Microsoft MVP) объясняет, почему он не использует MsTest (спасибо за перевод, Alexander):

Лично я не использую MS Test. Этот продукт был создан людьми, которые весьма далеки от реальной практики тестирования. MS Test привлекает неопытных людей своим визуальным оформлением, людей, которые покупают вещи за их внешнюю красоту и глянец. VSTS довольно далека от современных cross-functional roles, которые все чаще используются разработчиками. Банальная переплата денег.

Создание расширений для MS Test - бесполезное занятие. Небольшое сообщество людей, которые занимались этим делом, по большей части следует рекомендациям Microsoft по тестированию, что означает следующее: они упускают из вида так называемую разработку, движимую поведением (BDD), в той же степени, в которой Microsoft упускает из вида TDD. В этой области мир открытого кода развивается значительно быстрее Microsoft, как в плане подходов к использованию инструментов тестирования, так и в плане развития самих инструментов тестирования.

Изоляция, в которой MS разрабатывала продукт и игнорирование практик TDD привели к тому что дефолтный интерфейс Visual Studio для запуска и просмотра результатов тестов очень неудобен.

Кроме того, есть серьезные проблемы со временем работы тестов:

Одна из главных причин медлительности MSTest — то, что для каждого запуска единичного теста, создаются копии ВСЕХ сборок в уникальной директории внутри папки "TestResults". Это может звучать не так страшно, но я заметил, что это замедляет выполнение тестов по крайней мере в 3-4 раза по сравнению с NUnit или TestDriven.NET (с MSTest). Я понимаю, что создание копий сборок каждого запуска позволяет накапливать историю о результатах тестирования для Team Foundation Server. Но, по крайней мере, эта фича должна быть опциональной. Крайне непрактично, что создается весь набор файлов для публикации в continuous integration сервере во время каждой сессии TDD (red-green-refactoring). Это полностью ломает ритм TDD.

Из статьи The fundamental problems and impracticality of using MSTest

Перейти к вопросу →

MSTest жестко связан с Visual Studio, поэтому есть серьезные проблемы с интеграцией тестов в систему continuous integration, если на машине ci-сервера не установлена VS. Конечно, если вы используете Team Foundation Server, то проблем скорее всего не возникнет)

Перейти к вопросу →

По информации, полученной от службы поддержки Яндекса, в настоящий момент (25 декабря 2009) Яндекс не учитывает теги link с rel=canonical.

Перейти к вопросу →

Проект MvcContrib.TestHelper содержит классы-заглушки большинства объектов инфраструктуры ASP.NET MVC. Также есть специальные расширения специально для тестирования роутинга. Эти расширения позволяют тестировать простой роутинг вообще без самописных заглушек:

[TestFixture]
public class RoutesTester
{
    [SetUp]
    public void Init() /*[Инициализация теста]*/
    {
        RouteTable.Routes.Clear();
        MvcApplication.RegisterRoutes(RouteTable.Routes);
    }

    [Test]
    public void DefaultTest()
    {
        "~/aboute".Route().ShouldMapTo<InfoController>(c => c.Aboute());
    }
}

Важный момент — перед каждым тестом таблица роутинга очищается и заполняется заново. За это отвечает вот этот код:

[SetUp]
public void Init()
{
    RouteTable.Routes.Clear();
    MvcApplication.RegisterRoutes(RouteTable.Routes);
}

Такой подход отлично работает если метод контроллера получает аргументы примитивных типов. Но если экшен принимает сложные объекты, требующие работу байндеров, то ShouldMapTo не может правильно определить параметры роутинга.

Перейти к вопросу →

Можно использовать XSLT для преобразования всех вариантов старых форматов к новому. То есть, для каждай новой версии создается файл, описывающий преобразования, которые необходимо произвести для конвертации xml предыдущей версии к текущей. Таким образом, если нужно конвертировать файл версии 2 к текущей версии 5, то необходимо выполнить цепочку преобразований 2->3->4->5, где каждое преобразование осуществляется соответствующим XSLT-файлом.

Перейти к вопросу →

Есть фреймворк, реализующий шаблон MVC специально для WinForms-приложений: koossery.MVCwin. Похоже, что в контексте этого фреймворка под MVC понимается классическая реализация, применявшаяся во времена Smalltalk. То есть для каждого елемента управления создается свой вид, свой контроллер и тд. Суть такого подхода хорошо описана Мартином Фаулером.