Обратная инженерия с помощью Reflector. Часть 1
Целью данной работы было объяснить и научить вас сложным техникам обратной инженерии (в основном, с использованием Red Gate Reflector). В данной статье я шаг за шагом развею миф о невозможности дизассемблирования и взлома .NET файлов для получения конфиденциальной информации.
Автор: Ajay Yadav
- Red Gate Reflector
- .NET Framework 2.x version
- VC 2010 IDE
- ILDASM.exe (не обязательно)
Reflector относится к средствам дизассемблирования. Он разработан компанией Red Gate. Хотя раньше эта программа распространялась бесплатно, теперь разработчик коммерциализировал ее. Reflector используется для декомпиляции или дизассемблирования .NET файлов (к которым могут относиться как исполняемый файлы, так и DLL).
Функционал данной программы ограничен, и она может применяться только к файлам, созданным под CLR, она не сможет декомпилировать прочие неизвестные ей сборки. Но ограничение становится преимуществом, если мы можем легко предсказать фреймворк DLL или EXE. Если бинарный файл открыт или декомпилирован в Reflector IDE, тогда он является сборкой .NET.
Для профессионалов в сфере обратной инженерии Reflector имеет ряд преимуществ. Он предоставляет возможность по IL дизассемблированию. Открывать ILDASM.EXE отдельно нет необходимости. Он может быть интегрирован с Visual Studio 2010 или 2012 в качестве дополнения, которое может конвертировать декомпилированный код к другим языкам, поддерживаемым .NET, например VB.NET или Delphi. Мы можем запустить командную строку Visual Studio прямо из Reflector’а для тестирования или выполнения файла прямо из программы после декомпиляции сборки. И наконец, мы можем просмотреть декомпилированный код любого NET framework от версии 4.5 до 1.0.
После того, как вы скачаете и установите IDE, вы увидите нечто похожее:
Помимо описания преимуществ и возможностей, я бы хотел упомянуть об общем заблуждении, что Reflector не может редактировать исходный код или коды операций.NET. В отличие от других дизассемблеров (CFF, IDA pro или Ollydbg), он не может сохранять свой проект в качестве сборки, он может только декомпилировать. Что касается редактирования .NET-файлов, появляется необходимость в установке открытого дополнения в среду разработки Reflector’а. Можно найти много разных полезных дополнений, позволяющих, например, редактировать шестнадцатеричный код или коды операций. Изменения можно будет сохранить в отдельный файл.
В статье мы не будем полагаться на уже готовое ПО или прочие сторонние файлы для демонстрации дизассемблированного исходного кода. Вместо этого, мы разработали свое приложение.
Я назвал его «Champu» в честь домашнего питомца моего сына. Программу можно запустить, когда инициируется тест, и она будет работать в триальном режиме 15 дней. Это первая особенность, касающаяся безопасности. Второй же особенностью является то, что для доступа в приложение необходимо ввести имя пользователя, пароль и лицензионный ключ. Это позволяет защититься от пиратов. Начальное окно триальной версии выглядит следующим образом.
Пользователь может запустить ознакомительная версию, нажав кнопку «Continue». Далее вы должны будете задать имя пользователя и пароль.
Если пользователь захочет приобрести полную версию продукта, он должен перейти на сайт производителя и получить там лицензионный ключ. Этот ключ должен вводиться в следующем окне:
Вы спросите, есть ли другой способ получить полную версию, без оплаты? Да, обратная инженерия – лучший способ для взлома проприетарной программы.
Дизассемблирование.
Как можно заметить, в диалоговом окне кнопка «Continue» неактивна и показано сообщение об истечении пробного периода. У нас нет исходного кода программы, чтобы мы могли модифицировать его для получения полной версии. Остается только купить ключ…
Что ж, пришло время действовать! Все что у нас есть – это champu.exe, а большего нам и не надо. Запустим Reflector IDE и откроем в нем Champu.exe. Когда файл будет открыт, вы увидите следующий график. Мы знаем, что файл был создан с помощью .NET фреймворка, так как мы смогли его открыть.
Исполняемый файл автоматически преобразуется в соответствующие файлы исходного кода. В нем есть начальная информация о сборке, типе приложения, версии, криптографическом ключе, копирайте, GUID’е и используемом фреймворке.
Также мы можем получить дополнительную информацию о внешних ссылках .NET сборки данного файла, как и о использованных изображениях.
Достаточно просто можно получить большое количество информации о программе. Далее кликнем правой кнопкой мыши по файлу champu.exe, и среда разработки предложит вам различные инструменты для работы, как, например, анализатор, ILDASM, командная строка и запуск приложения.
Можно заметить, что champu.exe содержит пространства имен, которое в свою очередь содержит классы C_Trial, Login и Register и статические классы Program и gData. Можно предположить, что данные классы реализуют весь функционал и ответственны за логику работы программы.
Сборка может содержать множество классов, и они будут содержать два разных типа реализованной логики. Таким образом, очень сложно определить точку входа для трассировки, но нам необходимо это сделать. Нужно кликнуть правой кнопкой мыши на champu.exe, а затем перейти по ссылке «Go To Entry Point». Справа отобразится функция сборки Main(), и будет загружен класс C_Trail.
Теперь мы определили точку входа – класс C_Trail, в котором реализована логика триального срока действия. Выбираем нужный класс в левой панели при раскрытии пространства имен Champu. Он позволит нам определить логику контроля лицензии, используемую в программе. Этот класс содержит два метода: RegisteredUser() и TrailCheck().
Перейдем в тело метода TrailCheck(). Здесь находится часть, отвечающая за логику триального периода. Можно понять, что программа будет работать 15 дней с 5.10.2013. Кроме того, в исходном коде мы можем найти сообщение об истечении пробного периода пользования программой.
Вот и код этого метода. Нельзя с уверенностью сказать о срабатывании основного условия. Выберем TrailCheck() в левой панели и воспользуемся анализатором. Здесь я покажу кое-какую полезную информацию, такую как условие срабатывания (On_Load()) и зависимости.
По умолчанию Reflector показывает код программы на C#. Некоторые программисты не очень хорошо знают этот язык, специально для них существует возможность изменить язык на другой, поддерживаемый .NET, например, VB.NET.
Если вы хотите изучить инструкции кодов операций MSIL, вы можете использовать соответствующий IL код. Использовать ILDASM нет необходимости.
Reflector также предоставляет возможность экспорта/импорта исходного кода в/из XML файла.
Иногда нам необходимо видеть состояние глобального кэша сборок – хранилища всех .NET сборок. Утилита GAC в Reflector предоставляет нам такую возможность, как показано ниже.
Данная статья показывает процесс дизассемблирования кода с помощью Reflector. Как уже говорилось ранее, эта программа не является средством изменения кода, она лишь проводит декомпиляцию для последующего анализа логики работы программы. Кроме того, в данной работе рассматриваются несколько возможностей Reflector’а, например экспорт/импорт сборки, GAC, анализатор, а также конвертация кода (очень полезная в ходе дизассемблирования особенность). Также в целях поиска интересующей нас информации был проанализирован класс C_Trail. В следующей статье мы проведем анализ остальных классов для последующего взлома приложения.
Если вам нравится играть в опасную игру, присоединитесь к нам — мы научим вас правилам!
Создание Windows-приложений на основе Visual C#: Информация
Рассматривается создание Windows-приложений на основе Visual C# в среде Microsoft Visual Studio.NET. Более 100 готовых примеров, доступных для скачивания, различного уровня сложности — от блокнота и калькулятора до почтового клиента и финансовой программы позволят быстро научиться создавать собственные приложения.
Рассматриваются основы создания Windows-приложений в среде Visual Studio.NET на языке Visual C# — свойства проектов, окна Solution Explorer, Class View, Toolbox, XML — документирование кода. Проводится подробное сравнение особенностей синтаксиса делегатов и событий в Windows — формах и консольных приложениях. Изучение многочисленных элементов управления сопровождается применением их в приложениях различной сложности — блокноте, калькуляторе, программе просмотра изображений, почтовой программе Ballet, финансовой программе Education Center. Рассматриваются вопросы, связанные с реестром и файловой системой операционной системы Windows, XML — сериализацией. Описываются элементы языка SQL, модель объектов ADO.NET, практическое использование в Windows-приложениях баз данных Microsoft SQL Server и Microsoft Access. В курс входит описание применения библиотек кода — .NET и COM компонент, вызов функций WinAPI. Рассматривается работа с печатью и изображениями. Приводится применение асинхронной модели программирования в .NET Framework. Уделяется внимание вспомогательным средствам — созданию пакетов дистрибутивов, справки, переводу приложений, защите сборок. Вопросы безопасности рассматриваются в широком спектре — уровни доступа, администрирование, создание собственной технологии ролевой безопасности. Применяются дополнительные утилиты, входящие в состав Visual Studio .NET — tlbimp.exe, ildasm.exe, ilasm.exe, gacutil.exe, caspol.exe.
Специальности: Программист, Архитектор программного обеспечения
ISBN: 978-5-9556-0080-2
Оптимизация клиентских библиотек
Пакеты оптимизации клиентских библиотек, которые мы рассмотрели в предыдущей статье, удобны в качестве инструмента управления и сопровождения, т.к. они освобождают нас от рутинной работы по поддержанию элементов и в актуальном состоянии. Однако пакеты позволяют предпринять еще один трюк — с их помощью можно оптимизировать контент, отправляемый браузеру. Существуют два способа оптимизации пакетов. Первый — это локальная оптимизация, а второй — применение . Мы объясним оба способа в последующих разделах, но прежде чем делать это, мы более подробно рассмотрим стандартное поведение пакетов.
По умолчанию содержимое файлов, указанных в каждом элементе и , запрашивается индивидуально через отдельные сетевые подключения. Браузеры поддерживают фиксированное количество параллельных сетевых запросов, из-за чего часто приходится ожидать загрузки файла сценариев или таблицы стилей, прежде чем веб-сайт отобразится в браузере. Браузер делает только ограниченное число параллельных запросов к одному веб-сайту, обычно равное шести. В этом можно удостовериться, запустив приложение и активизировав инструменты браузера.
Перейдите на вкладку Network (Сеть) для отображения профилировщика сети. Профилировщик отобразит детали сетевых подключений, которые были созданы для получения файлов HTML, CSS и JavaScript, требуемых для визуализации веб-формы, как показано на рисунке ниже. (В зависимости от конфигурации и производительности вашей машины разработки могут быть получены несколько отличающиеся результаты.)
Как видно на рисунке, браузеру понадобилось выполнить 24 запроса для загрузки 728 Кб данных. Эти запросы завершились быстро, но причина в том, что браузер и приложение функционируют на одном устройстве, на котором доступен большой объем памяти и не делается какая-то другая работа. В случае подключения через Интернет накладные расходы будут более существенными.
Многие из 24 запросов относились к файлам CSS для библиотеки jQuery UI, которые были добавлены в целях демонстрации работы пакетов, и веб-форме они в действительности не нужны. Тем не менее, количество запросов по-прежнему мало по сравнению с реальными проектами, в которых веб-формы нередко содержат 100 и более файлов, особенно когда используются неупакованные решения наподобие шаблонов управления контентом.
Использование локальной оптимизации
Локальная оптимизация означает, что контент минимизируется и объединяется, чтобы требовать для своей загрузки меньшее количество запросов. Чтобы включить локальную оптимизацию, мы модифицируем файл Web.config, изменяя атрибут debug в элементе system.web/compilation на false. Это указывает, что приложение должно вести себя так, как после развертывания. (Упомянутый атрибут изменяется автоматически при развертывании приложения.) Изменение представлено в примере ниже:
debug="false" targetFramework="4.5.1" /> . Изменение атрибута debug оказывает более широкое влияние, чем просто включение оптимизаций пакетов — это также приводит к включению оптимизаций компилятора и удалению символов отладчика Visual Studio. Если нужно активизировать оптимизации пакетов, не изменяя остальное, можно установить статическое свойство BundleTable.EnableOptimizations в true. Обычно это делается в глобальном классе приложения.
Снова запустите приложение (выбрав пункт Start Without Debugging (Начать без отладки) в меню Debug среды Visual Studio) и повторите профилирование запросов, выполненных браузером. Результат от включенных оптимизаций показан на рисунке ниже:
Браузер сделал 6 запросов для загрузки 178 Kb данных, т.е. значительно уменьшился как объем передаваемых данных (за счет использования минимизированного контента), так и количество сетевых запросов (за счет объединения содержимого множества файлов).
Поддержка средством упаковки функций управления сценариями и таблицами стилей является более надежной и продуманной, чем аналогичная поддержка у средства оптимизации. Однако если взглянуть более внимательно на запросы, выполняемые браузером, можно заметить ряд проблем, которые будут описаны в последующих разделах.
Исправление проблемы дублирования файлов
Первая проблема, которую придется решить, связана с тем, что включение оптимизаций отключает средство обнаружения ссылок на файлы во множестве пакетов. Это можно заметить в профилировщике при запросе файлов JavaScript по двум URL:
/bundle/jquery?v=cRpZpqaBtXGD5K6oveCrw6zWYGnzQmjc9FSFuRkN9OM1 /bundle/jqueryui?v=tNjSByHblyunjhDAi7ICDaSfjSbXY7DWtE5tEEr_C6U1
Показанные URL ссылаются на имя пакета и содержат уникальный идентификатор версии, который позволяет контенту кешироваться браузером, не препятствуя развертыванию более новых версий пакетов. В рассматриваемом примере это означает, что минимизированное содержимое файла jQuery отправляется браузеру дважды — один раз сам по себе и еще один раз в виде объединения с минимизированным контентом файла библиотеки jQuery UI.
Поскольку ссылка на каждый пакет производится по собственному URL, контент будет загружен дважды. При включенной локальной оптимизации нам придется вручную идентифицировать дублированные ссылки и создавать пакеты так, чтобы избегать их. В этом примере проблема решается простым удалением пакета jquery из веб-формы:
Чтобы увидеть результат изменения, запустите приложение и выполните профилирование заново:
Благодаря такому изменению, браузеру нужно делать только 5 запросов для загрузки 141 Kb данных.
Кроме излишнего расхода полосы пропускания дублирование файлов JavaScript может привести к более серьезным проблемам. Порядок загрузки файлов JavaScript важен из-за того, что зависимости между библиотеками полагаются на глобально доступные переменные и функции. При наличии дублированных файлов, так что порядок следования библиотек выглядит как jQuery, jQuery UI и снова jQuery, второй файл jQuery сбросит глобальные переменные, с которыми работает библиотека jQuery UI, и это приведет к ошибке. Включая локальную оптимизацию, тщательно тестируйте приложение, а не просто полагайтесь на то, что все будет работать после развертывания.
Исправление проблемы относительного местоположения изображений
Внимательно просмотрев результаты профилирования для оптимизированных пакетов, вы заметите, что последний запрос завершился с кодом состояния 404, который свидетельствует о том, что запрошенный файл не был найден. Этот запрос касался файла изображения, которое библиотека jQuery UI использует для добавления визуального эффекта к кнопкам. Чтобы увидеть это, сравните кнопки, отображаемые браузером с включенными и отключенными оптимизациями. Когда упомянутый файл изображения не доступен, кнопки отображаются с одним сплошным цветом:
Проблема возникает из-за того, что библиотека jQuery UI пытается загрузить файл изображения относительно местоположения файла CSS, а локальная оптимизация изменила URL, применяемый для запроса контента пакетов. Вот как выглядит элемент , который использовался при запрашивании файла CSS для jQuery UI:
Контент объединенных таблиц стилей основан на имени пакета, а не на местоположении файла. В результате попытка библиотеки jQuery UI загрузить файл изображения с применением URL вроде показанного ниже ни к чему не приводит:
http://localhost:32160/bundle/images/ui-bg_glass_75_dadada_1x400.png
Простейший способ исправить это предусматривает изменение URL, который создан для пакета, позволяя jQuery UI находить свои файлы изображений, как показано в примере ниже:
using System; using System.Web.Optimization; using System.Web.UI; namespace ClientDev < public class BundleConfig < public static void RegisterBundles(BundleCollection bundles) < // . Bundle jqueryUIStyles = new StyleBundle("~/Content/themes/base/jqueryUICSS") .IncludeDirectory("~/Content/themes/base", "*.css"); // . >> >Мы изменили URL пакета для соответствия с местоположением файлов на диске. Это обеспечивает работу запросов к файлам, сделанных относительно URL пакета. В примере ниже демонстрируется применение нового URL пакета к веб-форме Default.aspx:
Вновь запустив приложение и выполнив профилирование, вы увидите, что браузер находит файл изображения и корректно отображает кнопки.
Насколько широко должна применяться локальная оптимизация?
С помощью оптимизации пакетов нам удалось снизить количество запросов до пяти, но можно было бы продолжить, поскольку два запроса относятся к контенту CSS, который может быть объединен в единственный пакет (и, следовательно, в один сетевой запрос).
В реальном проекте мы останавливаемся в этой точке и принимаем тот факт, что веб-форма требует выполнения двух запросов для таблиц стилей CSS. Причина в том, что стоит только выйти за рамки создания пакетов, представляющих четкие функциональные блоки (специальные стили CSS для веб-формы, стили CSS для jQuery UI и т.д.), как очень быстро окажется, что вы создаете и сопровождаете пакеты сценариев и стилевых таблиц для каждой веб-формы в приложении. Это дает лучшие результаты в плане оптимизации, но возвращает те же самые проблемы управления и сопровождения, о которых говорилось ранее.
Эффективное использование пакетов предполагает соблюдение баланса между простотой управления и оптимизацией. Если окажется так, что каждая веб-форма содержит один крупный пакет для сценариев и еще один для стилевых таблиц, то знайте, что вы зашли слишком далеко.
Использование сетей доставки контента CDN
Совершенно другой вид оптимизации заключается в применении сети доставки контента (Content Delivery Network — CDN), когда контент загружается из серверов, которые управляются компаниями вроде Microsoft и Google и размещаются у поставщиков услуг Интернета, находящихся поблизости к клиенту.
Сети CDN хранят только широко используемые библиотеки JavaScript, но их преимущество в том, что файлы будут загружаться без потребления вашей полосы пропускания. Поскольку многие веб-сайты пользуются тем же самым набором основных библиотек (jQuery, jQuery UI и т.д.), браузер пользователя может уже располагать кешированными версиями этих библиотек из других приложений. Даже если браузер должен загрузить файл, сервер CDN находится близко к пользователю. На запросы к сети CDN не распространяется предел параллельных запросов к серверам приложений, что может ускорить передачу данных, требуемых браузеру для отображения нужного контента.
В примере ниже показано добавление поддержки обращения к CDN за пакетом jQuery UI:
using System; using System.Web.Optimization; using System.Web.UI; namespace ClientDev < public class BundleConfig < public static void RegisterBundles(BundleCollection bundles) < Bundle jquery = new ScriptBundle("~/bundle/jquery"); jquery.CdnPath = "http://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"; jquery.Include("~/Scripts/jquery-.js"); Bundle jqueryui = new ScriptBundle("~/bundle/jqueryui"); jqueryui.CdnPath = "https://ajax.googleapis.com/ajax/libs/jqueryui/1.11.2/jquery-ui.min.js"; jqueryui.Include("~/Scripts/jquery-.js", "~/Scripts/jquery-ui-.js"); Bundle basicStyles = new StyleBundle("~/bundle/basicCSS") .Include("~/MainStyles.css", "~/ErrorStyles.css"); Bundle jqueryUIStyles = new StyleBundle("~/Content/themes/base/jqueryUICSS"); jqueryUIStyles.CdnPath = "https://ajax.googleapis.com/ajax/libs/jqueryui/1.11.2/themes/smoothness/jquery-ui.min.css"; jqueryUIStyles.IncludeDirectory("~/Content/themes/base", "*.css"); bundles.UseCdn = true; bundles.Add(jquery); bundles.Add(jqueryui); bundles.Add(basicStyles); bundles.Add(jqueryUIStyles); > > >При использовании сети CDN мы избрали другой подход, определив пакет для каждой библиотеки JavaScript, которая будет применяться. Это связано с тем, что для получения контента пакета из сети CDN должен предоставляться одиночный URL, а в сетях CDN размещаются индивидуальные файлы (по-видимому, для увеличения шансов хеширования контента).
Используемый URL для CDN указывается с помощью свойства CdnPath. Мы применили сеть Google CDN, которая проста и бесплатна. (Подробные сведения и размещаемых библиотеках и доступных версиях можно получить по адресу Google Hosted Libraries.)
Также необходимо установить свойство BundleCollection.UseCdn в true, чтобы включить средство CDN. В примере ниже оба пакета сценариев используются для получения файлов библиотек jQuery и jQuery UI:
. . Благодаря внесенным изменениям, файлы JavaScript загружаются из сервера ASP.NET, когда оптимизация пакетов отключена, и через указанные URL, когда оптимизация пакетов включена, что можно видеть в результате профилирования запроса:
Браузер по-прежнему выполняет то же количество запросов, но файлы jQuery и jQuery UI поступают из сети Microsoft CDN. Это, по крайней мере, сузит полосу пропускания, требуемую для функционирования приложения. Кроме того, есть неплохой шанс, что пользователь получит лучше реагирующий интерфейс, т.к. контент будет поступать из сервера, являющегося локальным для поставщика услуг Интернета.
Сети CDN могут быть полезны, однако они сводят на нет ряд преимуществ в плане управления, которые предлагают пакеты. Отсутствует возможность сопоставления версий библиотек JavaScript, используемых локально, и библиотек, получаемых из сети CDN. Это означает необходимость ручного обновления применяемых URL для CDN, когда обновляются пакеты NuGet, или тестирования двух версий используемых библиотек. В случае работы с сетями CDN обеспечьте серьезное тестирование и синхронизацию локальных файлов и удаленных URL.
Обеспечение доступности библиотек для элементов управления
Для работы ряда встроенных элементов управления требуется библиотека jQuery: это касается и сложных элементов управления данными, которые были описаны в разделе Основы ASP.NET. Средство упаковки ASP.NET не располагает какой-либо поддержкой для управления требованиями к библиотекам сценариев со стороны элементов управления. В такой ситуации в Microsoft полагаются на более старый подход, предусматривающий применение классов ScriptManager и ClientScriptManager для обеспечения доступности библиотеки jQuery.
Классы ScriptManager и ClientScriptManager пытаются гарантировать, что элементы управления не генерируют дублированные элементы для необходимых файлов. Они делают это за счет требования предварительной координации между элементами управления и веб-формами для определения файлов, которые будут использоваться. В итоге исчезает ряд преимуществ, связанных с применением элементов управления, и снова появляются проблемы с управлением, которые пакеты стараются предотвратить. Классы ScriptManager и ClientScriptManager не были интегрированы со средством упаковки. Другими словами, нам нужен способ установления связи между ожиданиями элементов управления данными и пакетами, которые определены в приложении.
К счастью, элементы управления данными не являются слишком жесткими при проверке доступности jQuery с применением класса ClientScriptManager. Мы можем добавить в файл App_Start\BundleConfig.cs простой оператор, который удовлетворят требованиям элементов управления:
using System; using System.Web.Optimization; using System.Web.UI; namespace ClientDev < public class BundleConfig < public static void RegisterBundles(BundleCollection bundles) < // . ScriptManager.ScriptResourceMapping.AddDefinition("jquery", new ScriptResourceDefinition < Path = "~/bundles/jquery" >); > > > Хотя класс ScriptManager не был интегрирован в средство упаковки, он модифицирован так, чтобы не добавлять элементы для файлов, которые включены в пакеты. Тем не менее, мы получали несогласованные результаты, и этот класс вообще не работает при отключенной оптимизации пакетов. Соблюдайте осторожность, чтобы не получить множество версий файла jQuery внутри HTML-разметки.
В случае специальных элементов управления мы рекомендуем пробовать включать элементы либо напрямую, либо через пакеты. Не существует хорошего способа согласования имен файлов и версий. Довольно быстро можно создать ситуацию, когда клиенту отправляются разные версии одной и той же библиотеки. Взамен мы предпочитаем проверять, загрузила ли веб-форма библиотеку, необходимую для элемента управления, и сообщать об ошибке, если это не было сделано. Такая ошибка обнаруживается во время разработки и тестирования, после чего соответствующий файл JavaScript добавляется в пакеты, используемые веб-формой.
В примере ниже представлен простой пример пользовательского элемента управления под названием SimpleUserControl.ascx, который требует для своей работы библиотеку jQuery:
if (jQuery) < $(document).ready(function () < $('#nameSpan').text("Simple User Control"); >); > else Сообщение из элемента управления Несмотря на простоту, в этом элементе управления демонстрируется, как проверить, определена ли функция по имени jQuery. Это является сигналом того, что библиотека jQuery была загружена и инициализирована. Каждая популярная библиотека JavaScript располагает похожей возможностью проверки. Ниже показан код формы для проверки работоспособности элемента управления:
Добавление поддержки версий для CDN
В завершение статьи мы покажем, как создать специальный пакет сценариев, который поддерживает конструкции для URL в CDN, а также в локальных файлах сценариев. В примере ниже приведено содержимое созданного файла класса по имени CdnScriptBundle.cs:
using System.Linq; using System.Text.RegularExpressions; using System.Web; using System.Web.Optimization; namespace ClientDev < public class CdnScriptBundle : ScriptBundle < public CdnScriptBundle(string path) : base(path) < >public Bundle CdnInclude(string filePath, string cdnPath) < Bundle result = base.Include(filePath); BundleContext ctx = new BundleContext( new HttpContextWrapper(HttpContext.Current), BundleTable.Bundles, Path); Regex regexp = new Regex(@"(\d+(?:\.\d+))", RegexOptions.IgnoreCase); string version = regexp.Match(EnumerateFiles(ctx).First().VirtualFile.Name).Value; CdnPath = cdnPath.Replace("", version); return result; > > >На момент написания этих строк исходный код сборки System.Web.Optimization еще не был опубликован Microsoft, но в Microsoft пообещали вскоре сделать это (хотя данное обещание не было исполнено в течение определенного времени). С помощью декомпилятора мы выяснили, как работает средство упаковки (нам нравится инструмент .NET Reflector от Red Gate, но доступны и другие инструменты подобного рода), и создали класс, унаследованный от ScriptBundle.
Класс ScriptBundle и класс Bundle, от которого он унаследован, написаны без расчета на расширяемость, поэтому для получения желаемого поведения нам пришлось поступить несколько нестандартно. Мы определили метод CdnInclude(), который позволяет базовому классу иметь дело с конструкцией и сопоставлять ее с физическим файлом. Это используется для извлечения номера версии и вставки его внутрь URL в сети CDN, который передается методу CdnInclude(). Применение этого нового класса пакета демонстрируется в примере ниже, в котором показано содержимое файла BundleConfig.cs:
using System; using System.Web.Optimization; using System.Web.UI; namespace ClientDev < public class BundleConfig < public static void RegisterBundles(BundleCollection bundles) < Bundle jquery = new CdnScriptBundle("~/bundle/jquery") .CdnInclude("~/Scripts/jquery-.js", "http://ajax.aspnetcdn.com/ajax/jQuery/jquery-.min.js"); // . > > > Мы определяем локальный файл как «~/Scripts/jquery-.js», что соответствует физическому файлу jquery-2.1.3.js. Номер версии этого файла затем применяется к аргументу URL, так что сети CDN будет передан запрос http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.1.3.min.js, сохраняя локальную версию и версию из CDN библиотеки jQuery в синхронизированном состоянии.
Соблюдайте осторожность при использовании этого класса в своих проектах. Он предполагает, что на сервере CDN имеется версия файла библиотеки, которая соответствует версии файла, установленной локально. После выхода новой версии обновление серверов CDN может занять несколько дней, и в течение этого времени наш специальный класс пакета будет запрашивать несуществующий URL.
Сбой работы приложения после отключения питания
Попытался открыть нужную форму через блокнот, так как именно код этой формы представляет ценность для меня, получил блокнот с кучей пробелов.
При всем этом, если зайти в bin/debug при запуске файла .exe приложение работает корректно, но доступа к форме нет и не могу ее редактировать. Другие проекты работают нормально.
Буду очень благодарен помощи, убил много времени на это приложение
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:
После отключения питания слетает ОС
Здраствуйте, у меня возникла проблема, после резкого выключения питания пк постоянно слетает ос как.
Тускнеет экран после отключения питания
Я переустановил на своём ноуте (Lenovo Idepad 110) винду, была windows 10, поставил windows 7, и.
Моргает экран после отключения питания
После отключения компьютера и отключения питания, спустя несколько минут экран монитора моргает.
BSoD-ы после аварийного отключения питания
всем привет, полетела видна на пк вин ХР по словам пользователя "нажала выключить, он долго.
Администратор
16392 / 12871 / 5072
Регистрация: 17.03.2014
Сообщений: 26,183
Записей в блоге: 1
Nixtyle, декомпилируй приложение с помощью любого декомпилятора (например, dotPeek). Далее если сохранился код в Form1.Deisgner.cs, то скопируй в Form1.cs декомпилированный код удалив из него всё что уже объявлено Form1.Deisgner.cs. Это метод InitializeComponent, объявления элементов упправления и т.п. Если код Form1.Deisgner.cs тоже потерялся, то тогда удали Form1 из проекта и добавь новую форму с этим именем заново. Затем перенеси декомпилированный код в Form1.cs и Form1.Deisgner.cs.