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

Нужно использовать метод ConfigureObject контекста. Например так:

ContextRegistry.GetContext().ConfigureObject(targetObject, objectName);

Где targetObject — объект, кторый нужно сконфигурировать; objectName — имя прототипа этого объекта в контейнере.

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

Если определить текстовые константы для тегов и атрибутов HTML и несколько extension-методов, которые работают с классом TagBuilder, то можно получить систему написания HTML-структур в fluent-манере. Это особенно удобно применять в helper`ах ASP.NET MVC:

return Html.Tag.Img
    .AddAttribute(Html.Attribute.Src, imageSource)
    .AddAttribute(Html.Attribute.Alt, imageAltText)
    .Render();

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

1. Установить нужное значение свойства AutoCompleteMode (например, SuggestAppend или Append);
2. Установить значение свойства AutoCompleteSource в CustomSource;
3. Заполнить строками коллекцию AutoCompleteCustomSource (обычная коллекция, можно заполнить из дизайнера или из кода).

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

Когда нужно привести объект к какому-то типу только чтобы вызвать один метод, очень раздражает синтаксис cast`а — слишком много скобочек приходится набирать и конструкция не очень читабельна:

((SomeType) target).DoWork();

В этом случае спасет такой простой extension:

public static T As<T>(this object @object)
{
    return (T) @object;
}

Теперь можно писать так:

target.As<SomeType>().DoWork();

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

Интересный способ форматирования строки. Extension:

public static string FormatWith(this string target, params object[] args)
{
    return string.Format(CultureInfo.CurrentCulture, target, args);
}

Этот extension позволяет удобнее форматировать строки:

var formatted = "This {0} template for {1}".FormatWith("is", "strings");

Трюк замечен в коде Kigg.

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

Вот отрывок из справки по Spring.NET

Команда Spring обычно оправдывает использование setter injection, потому что из-за большого числа аргументов конструктор может стать слишком громоздким, особенно когда некоторые параметры опциональны. Наличие setter-методов также дает возможность повторной инъекции зависимостей после создания объекта.

Считается, что настоящие мужчины неизменно выбирают constructor-injection, и на это есть причины. Передача ВСЕХ требуемых зависимостей означает, что клиент никогда не получит экземпляр, который инициализирован не полностью. Обратная сторона в том, что объект уже невозможно переконфигурировать.

Однако, строгого правила здесь нет. Доверьтесь Силе и выбирайте тот тип инъекции, который считаете подходящим; иногда, когда вы имеете дело со сторонними библиотеками, выбор уже сделам за вас — классы могут не иметь setter-методов и придется использовать конструктор.

Так как вы можете смешивать оба подхода, лучшее правило — использовать конструктор для необходимых зависимостей и сеттеры для опциональных.

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

Конечно предпочтительнее использовать constructor injection. Но есть некоторые проблемы.

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

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

Есть такой инструмент Altova UModel® 2010. Он хоть и платный, но если нужно срочно сгенерить несколько диаграмм, то подойдет идеально. Может импортировать исходники из папки или файла проекта (.NET или Java), может строить диаграммы из бинарных файлов. Генерирует картинки из диаграмм безо всяких водяных знаков и тп, то есть на картинке диаграммы не видно, что использована trial версия.

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

В статье Using MVVM with Menus in WPF рассказывается о том, как реализовать контекстное меню в рамках паттерна MVVM. Идея такая — создается собственный класс для хранения параметров пункта меню:

public class MenuItem
{
   public string Text { get; set; }
   public List<MenuItem> Children { get; private set; }
   public ICommand Command { get; set; }

   public MenuItem(string item)
   {
       Text = item;
       Children = new List<MenuItem>();
   }
}

Используя этот класс, создается дерево данных меню для определенного элемента:

public List<MenuItem> MenuOptions
{
    get  {

       var menu = new List<MenuItem>();
       if (SupportedFileFormats.Count > 0)
      {
          var mi = new MenuItem("O_pen");
          foreach(var fl in SupportedFileFormats)
          {
               var sff = fl;
               mi.Children.Add(new MenuItem(fl.Attributes.Description) 
                      { Command = new DelegatingCommand(() => { LoadFromFormat(sff); })});
          }
          menu.Add(mi);
       }

       menu.Add(new MenuItem("Close _All") { Command = new DelegatingCommand(OnCloseAll, () => FileList.Count > 0)});
       return menu;
    }

}

На стороне xaml создается стиль, который связывает элемент управления пункта меню и наш собственный класс данных:

<Style x:Key="ContextMenuItemStyle">
   <Setter Property="MenuItem.Header" Value="{Binding Text}"/>
   <Setter Property="MenuItem.ItemsSource" Value="{Binding Children}"/>
   <Setter Property="MenuItem.Command" Value="{Binding Command}" />
</Style>

Далее, стиль присваивается конкретному контролу и все работает:

<StackPanel Orientation="Horizontal">
    <Image Source="{Binding Image}" Width="16" Height="16" />
    <TextBlock Margin="5" HorizontalAlignment="Left" VerticalAlignment="Center" Text="{Binding Header}" />
    <StackPanel.ContextMenu>
        <!-- Собственно меню -->
        <ContextMenu ItemContainerStyle="{StaticResource ContextMenuItemStyle}" ItemsSource="{Binding MenuOptions}" />
    </StackPanel.ContextMenu>
</StackPanel>

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

Для запуска проверки StyleCop во время билда нужно импортировать target-файл Microsoft.StyleCop.targets (поставляется вместе с StyleCop) в файле проекта.

<Import Project="Путь к папке StyleCop\Microsoft.StyleCop.targets" />

Путь к папке, где лежит файл Microsoft.StyleCop.targets, естественно специфичен для конкретной машины. Это неудобно если проект находится в репозитории и используется несколькими разработчиками. Для преодоления этого недостатка можно воспользоваться переменными среды или написать путь относительно проекта и держать все инструменты StyleCop в репозитории.

Чтобы предупреждения StyleCop стали ошибками билда нужно установить свойство StyleCopTreatErrorsAsWarnings в false. Делается это тоже в файле проекта (он же MSBuild-скрипт):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <!-- ... -->
    <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>
  </PropertyGroup>

  <!-- ... -->

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="Путь к папке StyleCop\Microsoft.StyleCop.targets" />
</Project>