Консольную и 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. Стоит иметь в виду, что это по-прежнему альфа-версия. Любое использование исключительно на свой страх и риск. Замечания об ошибках и неполадках приветствуются.

На самом деле такие ошибки исправлять проще всего. Надо только не ошибиться, набирая в гугле ругательное слово 0x8ffe2740.

На скриншоте представлена моя неудачная попытка запустить службу W3SCV (это веб-сервер IIS). Не ища легких путей (бросаться сразу в гугл — сами понимаете, неспортивно), я для начала полез посмотреть подробности в EventViewer. Подробности оказались еще более загадочными: «Службе не удается создать привязку экземпляра 1. Данные содержат код ошибки». И код ошибки в шестнадцатиричном виде: 40 27 00 00. Потрясающе.

На этом месте я все-таки плюнул и полез в гугл. Ошибка, которую в данном случае не смогли предвидеть разработчики IIS — это всего-навсего занятый 80-й порт.

Для тех, кому не терпится справиться с ошибкой, сообщаю: скорее всего, у вас (как и у меня) этот порт занял Skype. Чтобы исправить ситуацию, зайдите в меню скайпа: Инструменты -> Настройки -> Дополнительно -> Соединение. Снимите флажок «Использовать порты 80 и 443 в качестве входящих альтернативных» и перезапустите скайп. После этого служба IIS стартует нормально.

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

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. Что делать с такими программами, я расскажу в следующий раз.

Крут этот мессенджер тем, что, во-первых, берет список контактов из ActiveDirectory (т. е. в контакт-листе автоматом находятся все доменные пользователи компании), а во-вторых — не требует никакой настройки на клиенте, берешь и запускаешь.  Можно даже с сетевого диска запускать, все равно пользователь автоматом авторизуется под своим доменным логином и будет иметь доступ к контакт-листу и своей личной истории сообщений.

Первый год своего существования (а появился он в конце 2003 года) назывался он Kommandozentrum, и старые пользователи до сих пор его называют коммандозером, или еще проще — дозером. Ну, типа, «Скинь мне в дозер ссылочку на тот сайт».

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

Так что, в ближайшие дни опубликую на этом блоге, что у меня получилось.

UPD. Написал два документа, но не стал публиковать в этом блоге:

• Установка сервера
• Описание файла конфигурации

• paddfoot
• Roquentin
• Денис
• de_leo

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