Comments 39
ничего себе топики на Хабре поперли…
я вот к примеру вообще о таком не знал
автору — жирный плюс и за статью и за оформление и за понятный язык
я вот к примеру вообще о таком не знал
автору — жирный плюс и за статью и за оформление и за понятный язык
+9
Карма в минус двадцать является хорошим стимулом для написания хороших статей. Главное не бояться попросить помощи в нужный момент.
Насчёт оформления, как я понимаю, Вы создатель ХабраРедактора, поэтому это большей частью Ваша заслуга, спасибо.
Насчёт оформления, как я понимаю, Вы создатель ХабраРедактора, поэтому это большей частью Ваша заслуга, спасибо.
0
Да, статьи про Руби и прочие Маки отходят на второй план, по неинтересности оных :)
+3
ну ничего себе. Интересная вещь. Только что-то навскидку не вижу практического применения
0
Ну хотя бы те же константы. С одной стороны они будут находиться в xml-файле, где их удобно редактировать и просматривать, а с другой — являются константами и их не нужно всё время получать из файла, конвертировать к int (если константа целочисленная), как это происходит в случае с web.config в Asp.net.
0
хмм не думаю, ибо ведь тогда не будет работать фича «Go to Declaration»
0
или я ошибаюсь… пошел думать и спрашивать гугл…
0
Дополнительная информация, которою нашел
1. Это не работает в проектах типа «WebApplication»
2. Да действительно это можно использовать для хранения констант:
3. Можно использовать для построения своих провайдеров данных и схем
4. Можно использовать, например, для «шлюза» между Ajax и веб-службами
Ппримеры: [№ 1] и [№ 2] и [№ 3]
Интересная штучка, будем знать, автору спасибо!
1. Это не работает в проектах типа «WebApplication»
2. Да действительно это можно использовать для хранения констант:
3. Можно использовать для построения своих провайдеров данных и схем
4. Можно использовать, например, для «шлюза» между Ajax и веб-службами
Ппримеры: [№ 1] и [№ 2] и [№ 3]
Интересная штучка, будем знать, автору спасибо!
+6
Ну не то чтобы совсем не будет, просто будет переходить не в исходный файл, а в сгенерированный.
Хотя я уверен, что эти вопросы тоже решаемы, как и подсветка ошибок и всё в таком духе. Я просто пока так глубоко в подробности не вдавался.
Хотя я уверен, что эти вопросы тоже решаемы, как и подсветка ошибок и всё в таком духе. Я просто пока так глубоко в подробности не вдавался.
0
Ого, впервые слышу про такое, очень интересно. Спасибо!
0
На самом деле Microsoft потихоньку отказывается от динамической компиляции.
Если немного пройтись по истории ASP.NET, то первая версия действительно содержала переменные нужного типа, которые изредка бились и стирались встроенным дизайнером, но компиляция выполнялась одновременно в масштабах всего проекта.
Как я полагаю, слава asp обыкновенного не давала кому то покоя. Чего не хватало в asp.net 1.0/1.1- возможности поправить код ОДНОЙ страницы без перекомпиляции, а следовательно без потери сессий и т д
«Гениальное решение» — новый вид проекта WEB Site. Справедливости скажем что в 2.0 добавилось также возможность разработки сайтов находящихся в файл систем, но скорость так называемоей динамической компиляции было достаточно низкой.
На большом проекте, более 150 форм, общее замедление составляло у нас порядка 35-40 процентов при такой форме компиляции.
Посыпались просьбы, пожелания и требования, и наконец вышла возможность делать проекты типа Web Application, которые пытались повторять старую, но так зарекомендовавшуюся возможность компилировать все полностью.
И плавно это перешло уже в релиз сервис пака.
Общая проблема Microsoft что часто пытается завлечь разработчиков понятием как было и т д
Если немного пройтись по истории ASP.NET, то первая версия действительно содержала переменные нужного типа, которые изредка бились и стирались встроенным дизайнером, но компиляция выполнялась одновременно в масштабах всего проекта.
Как я полагаю, слава asp обыкновенного не давала кому то покоя. Чего не хватало в asp.net 1.0/1.1- возможности поправить код ОДНОЙ страницы без перекомпиляции, а следовательно без потери сессий и т д
«Гениальное решение» — новый вид проекта WEB Site. Справедливости скажем что в 2.0 добавилось также возможность разработки сайтов находящихся в файл систем, но скорость так называемоей динамической компиляции было достаточно низкой.
На большом проекте, более 150 форм, общее замедление составляло у нас порядка 35-40 процентов при такой форме компиляции.
Посыпались просьбы, пожелания и требования, и наконец вышла возможность делать проекты типа Web Application, которые пытались повторять старую, но так зарекомендовавшуюся возможность компилировать все полностью.
И плавно это перешло уже в релиз сервис пака.
Общая проблема Microsoft что часто пытается завлечь разработчиков понятием как было и т д
+1
Как я понимаю, динамическая компиляция, это немного другое. Провайдеры компиляции всего лишь формируют исходный код на языке C#. Компиляция происходит уже после.
0
уверен, вы знаете, что Web Application хорош не только тем, что можно «компилировать все полностью»?
0
А сами веб сайты разве нельзя было компилировать? Если я не ошибаюсь, то из командной строки делалась прекомпиляция при помощи ASP.NET Compilation Tool. Пару раз пользовался, но мне не особо нужна была…
0
Сайт компилируется в любом случае. Разница в том, что обычный сайт компилируется по мере надобности, те заменили (или изменили) вы файл default.aspx, то перекомпилируется только то, что связано с этим файлом. Это динамическая компиляция.
Напротив в проектах Web Application сайт компилируется один раз в одну сборку и при изменении одного файла нужно перекомпилировать весь сайт.
Напротив в проектах Web Application сайт компилируется один раз в одну сборку и при изменении одного файла нужно перекомпилировать весь сайт.
0
Я это знаю. Я может не совсем правильно понял вашу проблему. У вас где тормозил Web Site при компиляции? На сервере или при разработке?
Если на сервере, то я и говорю, что можно было заранее скомпилировать его и потом уже заливать на сервер. Если при разработке, то избегать перекомпиляции всего проекта и настроить студию на перекомпиляцию только текущей странице при запуске отладки.
Вроде так.
Если на сервере, то я и говорю, что можно было заранее скомпилировать его и потом уже заливать на сервер. Если при разработке, то избегать перекомпиляции всего проекта и настроить студию на перекомпиляцию только текущей странице при запуске отладки.
Вроде так.
0
Есть немного другой механизм генерации кода по произвольному файлу в проекте — можно написать свой кодогенератор, который будет работать в Visual Studio. Отличия от описанного метода: работает только на этапе разработки, применяется для любых типов проектов (WinForms, DLL, ASP.NET), созданный файл кода лежит рядом с исходным и в проекте виден как пара по типу *.aspx + *.cs, можно положить в VSS или в SVN. Более детально можно почитать тут: rsdn.ru/article/devtools/vsnetcodegen.xml (статья старая, работу в 2008 студии не проверял).
+2
Прально.
А для тех, кто хочет исправлять исходники на этапе выкладки (через publish или tfs build) посоветую обратиться к написанию своих task-ов и внедрению их в .csproj — я, к примеру, таким образом сделал автоматическую замену connectionString-ов в web.config при выкладке на тестовые и «боевые» серваки через tfs.
А для тех, кто хочет исправлять исходники на этапе выкладки (через publish или tfs build) посоветую обратиться к написанию своих task-ов и внедрению их в .csproj — я, к примеру, таким образом сделал автоматическую замену connectionString-ов в web.config при выкладке на тестовые и «боевые» серваки через tfs.
0
Вместо конструкции if (pValue == null || pValue.Length == 0)
можно использовать if(string.IsNullOrEmpty(pValue))
можно использовать if(string.IsNullOrEmpty(pValue))
+2
новая сборка нужна из соображений секьюрити. Проще говоря система не доверяет сайту но доверяет сборке:)
+2
Спасибо, очень интересно.
А ограничение
А ограничение
PS: Я не нашёл способа не помещать провайдер в отдельную сборку, а просто добавить класс в папку App_Code. В данном случае возникает ошибка о невозможности загрузить тип.выглядит логично — на этапе работы BuildProvider'ов по самой их сути никакой код еще не может быть скомпилирован.
+1
Знали бы вы, как сложно отлаживать эти провайдеры. Я замучался с этим небольшим куском кода, а что будет с провайтером покрупнее. Дело в том, что сборку фактически использует студия, поэтому дебагом по ней не пройтись.
0
поэтому дебагом по ней не пройтись.Неужели даже System.Diagnostics.Debugger.Break() не работает?
0
Хех… Не лазил много по этому пространству имён, поэтому плохо с ним знаком.
Мне кажется всё равно это ничего не даст, но, всё же, напишите как этим пользоваться, я попробую.
Мне кажется всё равно это ничего не даст, но, всё же, напишите как этим пользоваться, я попробую.
0
Вот сейчас вставил System.Diagnostics.Debugger.Break() в класс провайдера (который в статье), просто появилось сообщение, что «Visual Studio 2008 обнаружила точку останова» и потом студию пришлось перезагрузить.
0
если бы автор раскрыл в статье практическое применение провайдеров компиляции было бы куда более полезнее. А так я лично не знал об этом, теперь узнал но, от этого не тепло не холодно…
0
Практика показала, что в некоторых случаях действительно полезная вещь. Одно замечание. xml стоило бы читать используя XmlTextReader — заметно быстрее, да и ресурсов по-меньше жрёт
0
Я знаю, что это быстрее и использует меньше ресурсов, но, как я написал в конце статьи, мне хотелось сделать код предельно простым и маленьким, так как это тут не главное.
0
Плюс-минус секунда в Compile-Time погоды не сделают.
+1
Во-первых, не всегда проект состоит из 5 файлов по паре килобайт. Во-вторых, учтите расходы памяти. В-третьих, не оправдывайтесь за других, автор уже ответил достаточно ясно
0
Sign up to leave a comment.
Использование провайдеров компиляции в Asp.net