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