Category Archives: .NET
Не так давно мутил я на дотнете воспроизведение трекерных файлов, а именно, XM. Громоздкие либы типа BASS явно для этой задачи не подходили, широко известный в узких кругах ufmod почему-то в связке с дотнет интеропом не заработал, зато нашлась библиотечка minifmod, которая обладала всеми необходимыми качествами (интересовала возможность загрузки из файла и из памяти) и небольшими габаритами. Для того, чтобы можно было удобно указывать способ загрузки (из файла или из памяти), я дописал маленький адаптер, который обрабатывал callback’и минифмода, и засунул его в DLL. Соответственно, нативная DLL к .net-проекту была подцеплена через простейший interop.
Сегодня наконец собрался с мыслями, почистил файлы проекта, и выложил все на гуглокод, благо sourceforge и codeplex уже попробовал. Google code очень понравился своей беспроблемностью в залитии файлов и работе с SVN. Вспоминая, как я трахался с sourceforge через SFTP чтобы залить туда пару архивов, могу сказать, что здесь все очень и очень удобно.
Итак, сайт проекта находится здесь http://code.google.com/p/minifmod4net/
Код использования библиотеки прост как пять копеек, достаточно взглянуть на тестовый пример, чтобы все стало ясно. Только один момент – если вы желаете использовать ее в своей программе, то вам придется сменить режим генерации кода с AnyCPU на x86, поскольку имеется нативная DLL с 32-битным кодом, и в режиме AnyCPU на какой-нибудь 64-битной винде программа не запустится, мотивировав отказ исключением наподобие ImageBadFormatException. Если же х86 специфицировать явно, то все будет работать и на 64-битных Windows.
PS. Поздравляю всех с наступившим 2010 годом, надеюсь, он принесет всем нам немало радости и профессиональных успехов 🙂
Часто приходится писать обработчики исключений, которые делают одно и то же. Например, в следующем кусочке кода нам необходимо среагировать на исключения типа Exception1 и Exception2 записью в лог-файл :
try { // Блок, который может вызвать исключения Exception1, Exception2 // или исключение любого другого типа } catch (Exception1 exc) { logger.WarnException("An exception has been occured : {0}", exc); } catch (Exception2 exc) { logger.WarnException("An exception has been occured : {0}", exc); } |
Проблема в том, что мы не можем никак избежать дублирования кода. Единственный выход – создать отдельный метод-обработчик, в котором и инкапсулировать логику. Но – во-первых, это может оказаться неудобным, поскольку локальные переменные, которые могут понадобиться в обработчике, придется передавать при вызове функции, а во-вторых, сам по себе вызов функции – это еще несколько тактов процессора.
Хотелось бы иметь способ, который бы позволял писать, скажем, следующим образом :
try { // } catch (Exception1, Exception2 exc as Exception) { // exc имеет тип Exception } |
Недавно собрался и написал краткий ман по NBox’у на русском языке.
Что это такое и зачем нужно ?
NBox – утилита c открытым исходным кодом, предназначенная для сжатия множества дотнетовых сборок и файлов приложения в одну управляемую сборку, которая будет хранить сжатые сборки в себе и при необходимости загружать их динамически.
Для чего это может понадобиться ?
- Во-первых, для уменьшения размера дистрибутива (файлы сжимаются по алгоритму LZMA, используемому в популярном архиваторе 7-zip).
- Во-вторых, иногда для разработчика удобнее предоставлять дистрибутив одним исполняемым файлом
вместо того, чтобы делать полноценный инсталлятор или же распространять множество файлов в одном архиве (то есть этот инструмент можно использовать в качестве лайт-замены для инсталляторов). - В-третьих, загрузка приложения, в котором много зависимостей, занимает обычно больше времени, чем загрузка одного исполняемого файла с последующей подгрузкой необходимых модулей прямо в памяти (особенно это заметно на медленных сменных носителях), – и NBox можно использовать для оптимизации загрузки приложения.
Дополнительные особенности :
- Возможность включать в результирующую сборку не только managed-сборки, но и библиотеки с неуправляемым кодом. Неуправляемые библиотеки обычно используются через interop, и поэтому они должны быть извлечены перед запуском приложения. Обычно они извлекаются в ту же директорию, в которой расположен исполняемый файл, либо в системную директорию.
- Возможность включать любые файлы.
Да, вы можете засунуть любой файл и извлечь его перед запуском приложения в указанную директорию. Это может быть файл конфигурации приложения, какой-либо бинарник, звуковой файл или что-то совсем другое. - Корректная работа с WPF-приложениями.
Стандартные WPF-приложения особенным образом работает с ресурсами, поэтому обычный алгоритм для них не работает. Поэтому приходится слегка похимичить с ресурсами. Либо нужно дублировать ресурсы оригинальной сборки в сжатой, либо менять привязку к абсолютным путям на относительные в исходном коде и xaml.
0