На тот случай, если требуется инструкция — вот она:

1. Установите NuGet (это плагин для Visual Studio 2010).
2. В ваш проект добавьте ссылку с помощью пункта меню Add Library Package Reference…
3. В появившемся окне будет список пакетов NuGet, найдите там BLToolkit.
4. Нажмите кнопку Install — пакет скачается и установится, а в проект добавится ссылка на библиотеку BLToolkit нужной версии.
5. Убедитесь, что в вашем проекте Target Framework указан полный (Client Profile для компиляции не подойдет).

То же самое в виде комикса:

Описание проекта

Zyan — это инфраструктура, упрощающая разработку распределенных приложений. Используя Zyan, вы можете опубликовать любой .NET-класс для удаленного взаимодействия. Zyan гибко настраивается и предоставляет все необходимые инструменты для построения модульных распределенных приложений.

Zyan требует для работы Microsoft .NET Framework 3.5 Client Profile, либо Mono 2.8 или выше (поддерживаются платформы Linux & Mac; см. скриншот).

Особенности

• Интуитивный программный интерфейс
• Широкий выбор вариантов хостинга .NET-компонентов (локальных или удаленных)
• Два режима активации компонентов: сингльтон и режим одиночных вызовов
• Поддержка TCP, HTTP и именованных каналов (для других протоколов возможно написать собственные плагины)
• Дуплексный TCP-канал позволяет серверу взаимодействовать с клиентами, находящимся за NAT-ом или брандмауэром
• Поддержка шифрованных каналов, не требующая сертификатов и наличия служб Active Directory
• Простая в использовании расширяемая система аутентификации
  • Поддержка интегрированной аутентификации Windows (единый вход в систему)
  • Поддержка базовой аутентификации на серверах SAM (удобно при отсутствии служб Active Directory)
• Расширяемое управление сессиями
  • Быстрый и легкий однопроцессный менеджер сессий (сессии хранятся в памяти сервера)
  • Масштабируемый менеджер сессии на базе SQL-сервера (сессии хранятся в СУБД)
  • Переменные сессий поддерживаются обоими вариантами менеджера сессий
• Распределенные события обрабатываются так же просто, как button_Click в Windows.Forms-приложениях
• Поддержка связывания распределенных EBC-компонентов (Event Based Components)

Простейший пример распределенного приложения

Публикация компонента:

// Создаем сервер ZyanDemo и привязываем его к TCP-порту 8080
var host = new ZyanComponentHost("ZyanDemo", 8080);
 
// Регистрируем тип и интерфейс компонента
host.RegisterComponent();

Вот и все, что нужно, чтобы компонент HelloWorldService стал доступным для удаленного взаимодействия.

Классу HelloWorldService не требуется наследование от MarshalByRefObject. Кроме того, не требуется разметка класса атрибутами ServiceContract и OperationContract. Любой .NET-класс может быть опубликован для удаленного взаимодействия. Единственное требование к нему — наличие интерфейса, через который будут осуществляться вызовы методов.

Получение доступа к службе с удаленного компьютера:

// Соединяемся с сервером
var connection = new ZyanConnection("tcp://localhost:8080/ZyanDemo");
 
// Создаем прокси-объект для HelloWorldService
var proxy = connection.CreateProxy();
 
// Вызываем метод (точно так же, как метод локального объекта)
proxy.SayHello("HelloWorld");

Дальнейшие подробности см. в разделе Документация.

Создаем проект и подключаемся к серверу

После установки ODAC первым делом, конечно, нужно настроить файл TNSNAMES.ORA. Проще всего взять пустую болванку, которая после установки будет лежать в папке %ORACLE_HOME%/Network/Admin/Sample/tnsnames.ora, подправить и переместить на одну папку вверх (в Network/Admin). Выглядеть этот файл будет примерно так:

SANDBOX=
  (DESCRIPTION=
    (ADDRESS=
      (PROTOCOL=TCP)
      (HOST=192.168.xxx.xxx)
      (PORT=1521)
    )
    (CONNECT_DATA=
      (SID=xxxx)
    )
  )

Дальше запускаем Visual Studio 2010 и создаем проект Windows Forms-приложения:

В окне Server Explorer создаем новое соединение, указывая в качестве Data Source Name имя соединения из файла TNSNAMES.ORA.

Здесь все как обычно, можно создавать/изменять таблицы, вьюшки, последовательности и прочие объекты БД. Я подключался к старой схеме, поэтому у меня уже были созданы таблицы AGENTS и USERS. Переименовывать их я не стал, чтобы продемонстрировать работу Entity Framework с классами, имена которых не совпадают с именами физических таблиц (классы будут называться Agent и User соответственно).

Импортируем и настраиваем схему

Добавляем модель Entity Data Model, генерируем классы из схемы БД (выбираем нужные таблицы, указываем пространство имен для модели и все прочее):

Переименовываем классы модели, которые нас не устраивают: AGENTS -> Agent, USERS -> User. Колонки тоже переименовываются: AGENT_ID -> AgentID, и так далее.

Выполняем LINQ-запросы

Схема готова. Чтобы выполнить запрос к ней, нарисуем простое окошко:

Вот запрос, который будет выполняться:

using (var ctx = new Entities())
{
  var query =
    from u in ctx.Users
    where u.Name.StartsWith("ya")
    select u;
 
  foreach (var u in query)
  {
    var msg = string.Format("{0} → {1}", u.Name, u.Agent.Name);
 
    TextBox.AppendText(msg);
    TextBox.AppendText(Environment.NewLine);
  }
}

Вот так будет выглядеть результат:

static void Main(string[] args)
{
    // Запускаем сервер
    var config = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
    RemotingConfiguration.Configure(config, false);
 
    // Работаем, пока не нажмут Enter
    Console.WriteLine("Server started. Press ENTER to quit.");
    Console.ReadLine();
}

Запустил, минимизировал такое окошко и крутится там себе сервер на фоне. Частенько бывает, что таких серверов запущено несколько (штуки три-четыре), и они постоянно торчат на панели задач. Изредка развернешь, чтобы прочитать, что там на консоли напечатано, а большую часть времени они только зря место занимают. Мне, честно говоря, это никогда особо не мешало. Пару недель назад один мой товарищ в разговоре заметил, что такие программки хорошо бы куда-нибудь прятать, оставляя одну иконку в системном трее. И с тех пор меня эти кнопки на панели задач стали раздражать.

Это такой мыслевирус, как кернинг: если человек не знает, что это такое, он живет себе спокойно. А если ему рассказать, да еще и показать на примере, чем плохой кернинг отличается от хорошего, — покой навеки утрачен. Теперь плохой кернинг постоянно будет ему бросаться в глаза на вывесках, объявлениях и рекламе в метро.

Короче говоря, пришлось-таки сделать небольшую библиотечку для сворачивания консоли в трей-иконку. Проблем тут, собственно, немного, но они есть (поэтому наивный вариант решения задачи — добавить компонент NotifyIcon с обработчиком DoubleClick, по которому что-нибудь там делать — не работает):

• В .NET Framework нету легального способа получить в свое распоряжение окно консоли
• В консольных приложениях нет конвейера сообщений

То есть, грубо говоря, добавить NotifyIcon можно (и в системном трее она будет нормально показываться), но обработчик события Click или DoubleClick вызываться не будет. Поскольку конвейера нет, событие просто некому переправить на обработку. А если и получится вызвать такой обработчик, непонятно, что в этом обработчике делать с консолью.

Чтобы справиться с этими проблемами, нужно 1) запустить свой конвейер сообщений в отдельном потоке и 2) заполучить хэндл окна консоли и прятать/показывать его средствами WinAPI. Выглядит так, как будто весь компонент будет состоять из сплошных вызовов p/invoke, то есть решение не будет блистать изяществом.

Однако выяснилось, что на деле не все так страшно. Оказывается, конвейеру WinForms — Application.Run(…) — вовсе не требуется главная форма. Он вполне сносно будет работать, если вместо этой формы ему подсунуть компонент NotifyIcon. То есть, первая часть задачи на самом деле сводится к запуску отдельного потока, в котором будет создаваться NotifyIcon и запускаться конвейер. И никакого p/invoke, что весьма приятно.

Хендл окна консоли, как выяснилось, иногда можно получить вот так: Process.GetCurrentProcess().MainWindowHandle. Здесь, разумеется, все портит слово «иногда»: на моем ноутбуке этот способ работает (Win7 x64), а на рабочем компьютере (WinXP x32) — нет. Вместо хендла возвращается IntPtr.Zero (MSDN говорит, что так задумано).

Так что для второй части задачи — прятать/показывать окно консоли — p/invoke все же нужен. Во-первых, нужен хендл консольного окна, во-вторых — метод ShowWindow(), который прячет или показывает окно по его хендлу. Весь WinAPI-мусор выносится в отдельный файл строчек примерно на 50 — ничего страшного. Жаль, правда, что портабельным этот вариант не будет, ну да хрен с ним, я и не претендовал на универсальность.

А дальше можно сделать приемлемую обертку, на иконку прицепить контекстное меню и заполнять его каким-нибудь fluent-интерфейсом:

using (var tools = new ConsoleTools())
{
    // настраиваем иконку в системном трее
    tools.SetNotifyIcon(SystemIcons.Shield)
        .SetTooltip(Console.Title + ": double click to toggle visibility")
 
        // добавляем обработчики событий (конвейер их обработает)
        .OnClick((s, e) => Console.WriteLine("NotifyIcon clicked!"))
        .OnDoubleClick((s, e) => tools.ConsoleVisible = !tools.ConsoleVisible)
 
        // добавляем пункты контекстного меню
        .AddMenuItem("About", SystemIcons.Question, ShowAboutBox)
        .AddMenuSeparator()
        .AddMenuItem("Hide console", (s, e) => tools.ConsoleVisible = false)
        .AddMenuItem("Show console", (s, e) => tools.ConsoleVisible = true)
        .AddMenuSeparator()
 
        // метод CloseConsole() работает как нажатие кнопки [x] на окне консоли
        .AddMenuItem("Close console",
            SystemIcons.Error, (s, e) => tools.CloseConsole());
 
    // А тут все как обычно, к примеру, RemotingConfiguration.Configure(...)
    Console.WriteLine("Press Enter to exit...");
    Console.ReadLine();
}

Остается только причесать немножко библиотеку и запустить ее куда-нибудь на CodePlex.

Консольную и GUI-версии программы вместе с исходниками можно взять на сайте проекта. Среди прочего в исходниках лежит и концептуальная версия (минимальный скелет программы без каких-либо наворотов), по которой можно разобраться, как все это работает. Концептуальная версия описана в нескольких прошлых постах: часть 1, часть 2, часть 3.

Системные требования:

• .NET Framework версии 2.0 или выше (используется DeflateStream)
• Windows XP или выше (используются системные процедуры для загрузки ресурсов)

Новые возможности версии 0.02 alpha:

• Исполняемый файл генерируется с помощью Reflection.Emit
• Ресурсы иконок и VersionInfo копируются из исходного файла
• В Windows-версии можно добавлять в список дополнительные сборки для упаковки в тот же исполняемый файл
• Добавлена защита от дизассемблирования Red Gate .NET Reflector-ом
• Ну и, разумеется, добавлены новые исправлены старые ошибки.

Справа — скриншот Рефлектора, который пытается декомпилировать упакованный файл. Попытка декомпилировать в C# (и любой другой высокоуровневый язык) приводит к ошибке. Дизассемблирование в IL, разумеется, работает, как и ILDasm (любую программу, которая загружается и запускается под .NET Framework, можно дизассемблировать в IL-код).

P.S. Стоит иметь в виду, что это по-прежнему альфа-версия. Любое использование исключительно на свой страх и риск. Замечания об ошибках и неполадках приветствуются.

Сегодня я очередной раз написал такой класс-хранилище, и получилось вполне симпатично. Пользоваться им нужно вот так:

using (TempFileManager temp = new TempFileManager())
{
  using (FileStream fs = File.Create(temp["my-temp-file.txt"]))
  {
    // файл my-temp-file.txt создался во временной папке
    // и будет удален вместе с ней
  }
}

Класс TempFileManager создает временную папку со случайным именем в подпапке системного временного каталога (обычно этот путь хранится в переменной окружения %TEMP% или %TMP% и расположен где-нибудь в C:\WINDOWS\Temp).

TempFileManager реализует интерфейс IDisposable, и в методе Dispose удаляет временные файлы и папку, в которой они хранятся. Временные файлы, кстати, вовсе необязательно должны быть в этой папке: можно добавить в список файлы с указанием полного пути, и они тоже будут чиститься в конце работы.

Файл регистрируется как временный, когда его имя передается в индексатор класса TempFileManager (индексатор — это свойство this[string fileName], возвращает он тоже строку). Индексатор TempFileManager всегда возвращает полный путь к переданному файлу: если имя файла указано без пути, файл считается помещенным во временную папку, иначе остается как есть. Например:

using (TempFileManager t = new TempFileManager())
{
  string s = t[@"1.txt"];    // s = @"c:\Windows\Temp\...\1.txt"
  s = t[@"c:\autoexec.bat"]; // s = @"c:\autoexec.bat";
}

Исходный текст можно взять на странице проекта Exepack.NET или здесь: TempFileManager.cs

А самый неподходящий вариант — модульная программа, построенная на плагинах. Что если плагин должен иметь возможность добавлять команды в главное меню или кнопки на панель инструментов? Давать плагину доступ к меню небезопасно, поэтому обычно поступают наоборот: программа спрашивает у плагина, какие команды он поддерживает и сама добавляет их в свое меню. Для этого плагин должен поддерживать метод типа GetPluginCommands(), возвращающий коллекцию доступных команд.

В результате в плагине приходится писать здоровенный такой метод, который формирует некую древовидную структуру команд. При добавлении в плагин новых функций нужно каждый раз лезть в этот метод и что-то туда дописывать. В .NET есть гораздо более изящный вариант решения подобной задачи — с помощью атрибутов.

Посмотрите на картинку: панель инструментов и меню описываются атрибутами ToolButton и MenuItem. Чтобы добавить новую команду-кнопку на панель инструментов, я пишу метод-обработчик, реализующий эту команду, и помечаю его атрибутом [ToolButton("Название команды")]. Добавление команд в главное меню сделано почти так же, только атрибут MenuItem позволяет указывать полный путь для добавляемой команды. Например, пункт File -> Exit описывается атрибутом [MenuItem("File", "Exit")]. Уровень вложенности может быть любой. При старте программа строит список помеченных атрибутами методов и добавляет пункты в меню и кнопки на панель инструментов.

Чем такой подход хорош? Во-первых, при добавлении новых функций не нужно лезть в дизайнер, чтобы что-нибудь там найти. Во-вторых, команды можно вытаскивать из любого класса (из самой программы или из плагинов) совершенно одинаковым способом. Плагину не нужен будет монструозный метод GetPluginCommands(), не несущий никакой полезной нагрузки.

Мне очень нравится такое описание интерфейсов, по-моему, оно удобно даже в маленьких проектах вроде Exepack.NET. Я далеко не всегда пишу в VisualStudio, и дизайнер форм иногда запустить просто негде, так что этот способ меня здорово выручает.

Итак, упаковщик работает по такой схеме:

1. Загружает главную исполняемую сборку (*.exe)
2. Составляет список используемых библиотек классов (*.dll)
3. Упаковывает все сборки, сохраняет во временные файлы
4. Готовит исходник для загрузчика (loader.cs)
5. Компилирует загрузчик, добавляя временные файлы как ресурсы
6. Удаляет временные файлы

Список библиотек для упаковки, конечно, можно было бы задавать явно (например, в командной строке) . Но согласитесь, гораздо приятнее, если упаковщик сам его составит, тем более, что это сделать совсем несложно. Стандартный класс-обертка Assembly, который позволяет более-менее успешно манипулировать .NET-сборками, дает возможность получить список модулей, на которые ссылается загруженная сборка: Assembly.GetReferencedAssemblies().

Повторяя этот процесс рекурсивно, мы получим полный список библиотек, которые используются нашим пакуемым приложением. Правда, в этом списке будут присутствовать всякие системные сборки типа mscorlib.dll и System.dll. При упаковке их, конечно, нужно будет пропускать.

Упаковки данных делается тем же самым классом DeflateStream, что и распаковка в загрузчике. При упаковке файлов я меняю их расширение на .deflated, в ресурсах файлы так и будут называться (было MyLib.dll, стало MyLib.deflated). Тут есть еще одна небольшая хитрость. Сборка-библиотека может быть спрятана где-нибудь далеко, например, в глобальном кэше сборок (GAC). Чтобы не искать ее самостоятельно, можно загрузить сборку стандартным механизмом загрузки — с помощью Assembly.LoadFrom(string name), — а затем посмотреть на свойство Assembly.Location. Получается весьма компактный метод:

static string CompressFile(string asmName)
{
  // load assembly
  Assembly asm = Assembly.LoadFrom(asmName);
  string compressedName = Path.ChangeExtension(asm.Location, "deflated");
 
  using (FileStream inFile = File.OpenRead(asm.Location))
  using (FileStream outFile = File.Create(compressedName))
  using (DeflateStream ds = new DeflateStream(outFile, CompressionMode.Compress))
  {
    new BinaryWriter(ds).Write(new BinaryReader(inFile).ReadBytes((int)inFile.Length));
  }
 
  return compressedName;
}

При загрузке каждой сборки надо еще проверить: вдруг она уже была загружена (например, по ссылке из другой сборки). Здесь я опустил такую проверку, но в исходных текстах Exepack.NET она, конечно, есть.

Дальше у нас по плану — исходник загрузчика. Можно его держать в отдельном файле loader.cs на диске, но я считаю, что это неудобно. Вдруг потеряется. Гораздо лучше, если он будет храниться в ресурсах самого упаковщика. Непосредственно перед компиляцией его нужно извлечь и сохранить на диск, чтобы компилятор C# смог до него добраться. Попутно нужно в нем исправить кое-какие мелочи (в частности, прописать имя ресурса, из которого будут загружены упакованные данные):

static string GetLoaderSource(string exeResourceName)
{
  using (Stream stream =
    Assembly.GetExecutingAssembly().GetManifestResourceStream("loader.cs"))
  {
    string loader = Encoding.UTF8.GetString(
      new BinaryReader(stream).ReadBytes((int)stream.Length));
    loader = loader.Replace("app.deflated", exeResourceName);
    return loader;
  }
}

Осталось рассказать о том, как запустить C#, чтобы скомпилировать загрузчик с упакованными ресурсами. Я не советую париться по поводу путей установки .NET Framework и собирания директив компиляции в RSP-файл: есть куда более легкий путь. Можно воспользоваться CodeDom-провайдером для C# (это такая подсистема .NET Framework, которая отвечает за генерацию кода — например, в дизайнере форм). Провайдер CodeDom самостоятельно определит, где находится компилятор C# (csc.exe), подготовит ключи компиляции, запустит и сохранит готовый EXE-файл. Очень удобно:

static string CreateExecutable(List files,
  string iconName, bool isConsole)
{
  // prepare loader source code
  string exeName = Path.GetFileName(files[0]);
  string loader = GetLoaderSource(exeName);
 
  // prepare compiler parameters
  CompilerParameters cp = new CompilerParameters();
  cp.GenerateExecutable = true;
  cp.OutputAssembly = Path.ChangeExtension(exeName, "packed.exe");
  cp.IncludeDebugInformation = false;
  cp.GenerateInMemory = false;
  cp.ReferencedAssemblies.Add("System.dll");
  cp.CompilerOptions = "/o /filealign:512";
  cp.CompilerOptions += isConsole ? " /target:exe" : " /target:winexe";
  cp.CompilerOptions += iconName != null ? " /win32icon:\"" + iconName + "\"" : "";
 
  // add compressed resources
  foreach (string fileName in files)
  {
    if (fileName == exeName)
      continue;
 
    cp.EmbeddedResources.Add(fileName);
  }
 
  // compile and check for errors
  CompilerResults cr = new CSharpCodeProvider().CompileAssemblyFromSource(cp, loader);
  if (cr.Errors.Count > 0)
  {
    // Display compilation errors.
    Console.WriteLine("Errors building loader into {0}", cr.PathToAssembly);
    foreach (CompilerError ce in cr.Errors)
    {
      Console.WriteLine("  {0}", ce.ToString());
      Console.WriteLine();
    }
  }
 
  // return new executable name
  return cp.OutputAssembly;
}

К сожалению, класс CompilerParameters поддерживает не все возможности компилятора C#. Поэтому кое-что приходится задавать ключами CompilerOptions. Это плохо, потому что не переносимо (то есть, не будет работать с другими компиляторами C# — Mono, Portable.NET и т. д.) Лично я с этим пока смирился: если придется портировать упаковщик для Linux — вероятно, это будет наименьшей проблемой из всех, что у меня появятся.

Ну вот, собственно, и все. Оказалось неожиданно просто. Весь процесс от задумки до работающей программы занял три часа (или чуть больше), зато написание статей растянулось на несколько дней. Кстати, на скриншоте в самом начале статьи показан файл ILMerge.exe после упаковки (было 828, стало 373 килобайта).

Я создал проект Exepack.NET на сайте CodePlex. Исходники для упаковщика из этой статьи — это релиз версии 0.00 alpha. Проект выпущен под лицензией MIT (в двух словах: используйте как угодно, в коммерческих или некоммерческих целях, только оставьте упоминание оригинального авторства). Если захотите принять участие в дальнейшей разработке проекта — присоединяйтесь!

Попробуем усложнить задачу. Возьмем какое-нибудь реальное .NET-приложение, которое состоит из нескольких сборок. Как правило, это один EXE-файл и несколько дополнительных DLL-библиотек.

Модули (файлы *.netmodule) я рассматривать не буду, никогда не видел, чтобы ими кто-то пользовался. Я могу ошибаться, но по-моему, в Visual Studio нет для них полноценной поддержки: проекты компилируются в монолитные сборки, а не в набор модулей. Теоретически, конечно, это может быть реализовано по-разному на разных платформах, но я пока не ставил себе цели написать полностью переносимый EXE-упаковщик.

Чтобы не искать готовое приложение, я за минуту написал небольшую программку из двух файлов: app.cs и applib.cs. На картинке показано, как такая программа выглядит в дизассемблере ILDASM (красным выделена ссылка на сборку-библиотеку).

Теперь я модифицирую загрузчик так, чтобы он мог распаковать и запустить программу вместе с библиотекой. Файлы app.exe и applib.dll я присоединяю к ресурсам моего загрузчика, чтобы получить один EXE-файл. Загрузчик работает по старой схеме: вытаскивает ресурс с именем app.exe и выполняет метод Main() с помощью методов отражения. Но теперь при загрузке происходит еще кое-что интересное.

Файл app.exe невозможно загрузить отдельно от applib.dll. Поэтому среда исполнения .NET перед загрузкой сборки app.exe начинает усиленно искать applib.dll везде, где только можно: сначала в текущем каталоге, потом в GAC. Поскольку файла нигде нет (он ведь теперь упакован), среда генерирует исключение: файл не найден.

А раз есть исключение, мы можем написать для него свой обработчик. Обработчик (у меня он называется ExtractAssembly) подключается одной строчкой:

AppDomain.CurrentDomain.AssemblyResolve += ExtractAssembly;

Обработчик работает по той же схеме, что и загрузчик: он вытаскивает из ресурсов файл applib.dll и подсовывает его исполняющей среде .NET вместо файла на диске. Вот как это делается:

static Assembly ExtractAssembly(object sender,
  ResolveEventArgs args)
{
    return GetResourceAssembly(new AssemblyName(
      args.Name.ToLowerInvariant()).Name + ".dll");
}
 
static Assembly GetResourceAssembly(string name)
{
    using (Stream stream = Assembly.GetExecutingAssembly().
      GetManifestResourceStream(name))
    {
        Assembly asm = Assembly.Load(
          new BinaryReader(stream).ReadBytes((int)stream.Length));
        return asm;
    }
}

Тут есть один маленький нюанс. Обработчику передается не имя файла, а имя сборки, в данном случае — «applib». Вообще говоря, тут нужно сохранить табличку соответствия имен сборок именам их файлов, но пока я ограничился самым простым вариантом: к имени сборки я добавляю расширение «.dll».

Собственно, это уже практический нормальный загрузчик, которым уже можно пользоваться. Осталось только добавить к нему распаковку ресурсов перед загрузкой (это делается одной строкой кода, с помощью DeflateStream) и еще пару мелочей:

// csc loader.cs /res:app.deflated /res:applib.deflated
// Written by Y [10-01-09]
 
using System;
using System.IO;
using System.IO.Compression;
using System.Reflection;
 
class Loader
{
  [STAThread]
  static void Main(string[] args)
  {
    AppDomain.CurrentDomain.AssemblyResolve += ExtractAssembly;
 
    Assembly asm = GetResourceAssembly("app.exe");
 
    if (asm.EntryPoint.GetParameters().Length == 0)
      asm.EntryPoint.Invoke(null, new object[0]);
    else
      asm.EntryPoint.Invoke(null, new object[] { args });
  }
 
  static Assembly ExtractAssembly(object sender,
    ResolveEventArgs args)
  {
    return GetResourceAssembly(
      new AssemblyName(args.Name.ToLowerInvariant()).Name + ".dll");
  }
 
  static Assembly GetResourceAssembly(string name)
  {
    using (Stream stream = Assembly.GetExecutingAssembly().
      GetManifestResourceStream(name))
    using (DeflateStream ds =
      new DeflateStream(stream, CompressionMode.Decompress))
    {
      // (int)ds.Length не поддерживается,
      // пока сделаем ограничение на 4 мегабайта
      Assembly asm = Assembly.Load(
        new BinaryReader(ds).ReadBytes(4000000));
      return asm;
    }
  }
}

Теперь, когда загрузчик готов, остается сделать не так уж много. Нужно написать программу, которая упаковывает сборки и компонует их вместе с загрузчиком в монолитные EXE-файлы. Пускай это остается на следующий раз.

Как недавно мне удалось выяснить, написать такой упаковщик для .NET-программ можно за три часа. Наверное, можно и быстрее, но у меня получилось за три с копейками. Это такая приятная особенность .NET: почти все уже сделано до нас.

А сделано до нас вот что:

• управляемый загрузчик Assembly.Load() или Assembly.LoadFrom()
• загрузчик ресурсов Assembly.GetManifestResourceStream()
• класс DeflateStream для упаковки и распаковки данных.

В простейшем случае .NET-программа — это один EXE-файл, который ссылается на системные сборки типа mscorlib, System.dll и так далее. Когда я обработаю этот файл упаковщиком, у меня должен получиться другой EXE-файл, который делает то же самое, но места занимает меньше. Естественно, это будет тоже .NET-программа, так называемый загрузчик.

Для начала я прикинул, как будет выглядеть этот самый загрузчик. Он будет загружать откуда-нибудь исходную сборку и запускать ее в своей же виртуальной машине CLR, в дефолтовом домене приложений. Сказано — сделано:

using System;
using System.Reflection;
 
class Loader
{
  static void Main(string[] args)
  {
    Assembly asm = Assembly.LoadFrom("app.exe");
 
    if (asm.EntryPoint.GetParameters().Length == 0)
      asm.EntryPoint.Invoke(null, new object[0]);
    else
      asm.EntryPoint.Invoke(null, new object[] { args });
  }
}

В данном случае сборка грузится из файла app.exe. Единственная тонкость, на которую тут надо обратить внимание: метод Main может быть с параметрами, а может — без. Поэтому перед запуском приходится проверять, с каким вариантом мы имеем дело. Более того, этот метод может быть void, а может возвращать значение типа int, это тоже надо бы учитывать (у меня тут, как видите, не учитывается).

Идем дальше. Загружать сборку из файла, понятно, некрасиво. У нас в результате должен быть один-единственный EXE-шник, в котором упаковано все. Поэтому сборку нужно грузить из наших же ресурсов. Когда я буду компилировать новую версию загрузчика, я попрошу компилятор C# присобачить файлик app.exe к моей программе в качестве ресурса. Есть такой удобный ключик у консольного компилятора — /res:app.exe. Ресурс в результате так и будет называться — app.exe.

Осталось разобраться, как загрузить сборку из ресурса. Выясняется, что это тоже довольно просто: вытаскиваем нужный Stream из ресурса с именем hello.exe, считываем в буфер (массив byte[]) и загружаем из него сборку с помощью Assembly.Load():

// csc loader2.cs /res:app.exe
 
using System;
using System.IO;
using System.Reflection;
 
class Loader
{
  static void Main(string[] args)
  {
    using (Stream stream = Assembly.GetExecutingAssembly().
      GetManifestResourceStream("app.exe"))
    {
      Assembly asm = Assembly.Load(
        new BinaryReader(stream).ReadBytes((int)stream.Length));
 
      if (asm.EntryPoint.GetParameters().Length == 0)
        asm.EntryPoint.Invoke(null, new object[0]);
      else
        asm.EntryPoint.Invoke(null, new object[] { args });
    }
  }
}

Проверяем — работает! Как нетрудно догадаться, если перед компиляцией загрузчика файл app.exe упаковать, а после загрузки, соответственно, распаковать — это и будет практически готовым упаковщиком.

В реальной жизни .NET-программы редко представляют собой единственный EXE-файл. Обычно это целая пачка сборок — файлов EXE и DLL. Что делать с такими программами, я расскажу в следующий раз.