Использовать компилятор из кода C# достаточно просто. А вот зачем – это другой вопрос :).
Hello World
Напишем первый простой пример. Создаем консольное приложение и напишем следующий код:
using System;<br>using System.CodeDom.Compiler;<br>using System.Collections.Generic;<br>using Microsoft.CSharp;<br><br>namespace ConsoleCompiler<br>{<br> internal class Program<br> {<br> private static void Main(string[] args)<br> {<br> // Source code для компиляции<br> string source =<br> @"<br>namespace Foo<br>{<br> public class Bar<br> {<br> static void Main(string[] args)<br> {<br> Bar.SayHello();<br> }<br><br> public static void SayHello()<br> {<br> System.Console.WriteLine(""Hello World"");<br> }<br> }<br>}<br> ";<br><br> // Настройки компиляции<br> Dictionary<string, string> providerOptions = new Dictionary<string, string><br> {<br> {"CompilerVersion", "v3.5"}<br> };<br> CSharpCodeProvider provider = new CSharpCodeProvider(providerOptions);<br><br> CompilerParameters compilerParams = new CompilerParameters<br> {OutputAssembly = "D:\\Foo.EXE", GenerateExecutable = true};<br><br> // Компиляция<br> CompilerResults results = provider.CompileAssemblyFromSource(compilerParams, source);<br><br> // Выводим информацию об ошибках<br> Console.WriteLine("Number of Errors: {0}", results.Errors.Count);<br> foreach (CompilerError err in results.Errors)<br> {<br> Console.WriteLine("ERROR {0}", err.ErrorText);<br> }<br> }<br> }<br>}<br><br>* This source code was highlighted with Source Code Highlighter.
Запускаем и проверяем:
Первое, на что стоит обратить внимание – это использование двух пространств имен (namespace):
Microsoft.CSharp
System.CodeDom.Compiler
В данных классах и содержится ключ к возможности компиляции. В нашем примере мы указываем что компилировать будем под .NET Framework 3.5, а так же указываем что мы хотим получить на выходе – Foo.exe, с возможностью запуска данного приложения.
Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.
От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.
Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.
Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.
Две одинаковые машины, каждая из которых движется со скоростью 100 км/ч, сталкиваются лоб в лоб. Равносильно ли это столкновению с бетонной стеной на скорости 200 км/ч?
Абсолютно упругий велосипедист на скорости 100 км/ч сталкивается лоб в лоб с тяжелым поездом, также двигающимся со скоростью в 100 км/ч. Отскочит ли при этом велосипедист со скоростью 300 км/ч?
Если на вопросы вы ответили "нет, да", то вы правы и ничего нового я вам не расскажу. А остальных приглашаю под кат. Никакой софистики там нет.
В определенный момент мне стало некомфортно использовать стандартный контрол WebBrowser, предлагаемый Visual Studio.
Причин было несколько:
1. Использовался IE-движок, что само по себе уже сильный аргумент.
2. Кривая работа с JS.
3. Отсутствие масштабирования.
4. Если запустить на машине, где стоит IE6, то все его «достоинства» переносятся на приложение.
В итоге был начат поиск альтернативных решений.
Было рассмотрено 2 SDK. xulrunner(Mozilla) и Awesomium(Chrome)
Подключение обоих происходит примерно одинаково, но на всякий случай опишу оба.
В один момент возникла задача сделать TabControl по отрисованному дизайну, с вкладками с левой стороны. Сложность была в том, что проект был уже написан с использованием winform, и переделывать его целиком не хотелось. Попытался реализовать эту задачу средствами класического TabControl, но встретился со множеством проблем, связанных с этим.
