Roslyn

The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs. You can build code analysis tools with the same APIs that Microsoft is using to implement Visual Studio!

Наверное уже все слышали, как и то что следующая студия будет полностью реализована на нем.

Компилятор еще в CTP, но уже сейчас аннонсированно достаточно радикальных новшеств, как например
* KRuntime, который избавляет от необходимости хранить и диплоить проекты в виде сборок, а предоставляет возможность развернуть в одном процессе портативный clr и скомпилировать проект на лету.
Как это продают со следующим ASP.NET и Visual Studio2014 внесение правок в с# код будет аналогичным написанию java script кода.
* [Перефразированно]Нейтральные типы и интерфейсы, которые не будут требовать наличия манифеста и явных зависимостей для связывания с кодом в другой сборке. Фактически это позволяет достаточно просто разрешать даже циклические зависимости и не иметь головной боли с неимоверным количеством зависимостей между сборками. Возможности Loose Coupling невиданные прежде в .net.

Кто что думает по поводу данных новшеств? Может еще что-то интересно успел отметить для себя уже.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Рослин представляет Апи, который позволяет все это выполнять естественным путем в текущей сборке, без надобности иметь доступ к файловой системе или перекомпиляции всей сборки в памяти как в случае с reflection emit.
Я правильно понимаю, вы говорите о том, чтоб взять исходный код некоторого класса, скомпилировать его, использовать его в приложении, после чего внести изменения в исходный код, и «докомпилировать», что должно обновить существующий тип в работающем приложении?
Мое понимание механизмов рантайма .NET говорит, что это невозможно.
Вместе с Roslyn выпускается новая версия рантайма, в которой поддерживаются такие патчи на живом приложении? Как это сказывается на производительности?

Не совсем так, менять сигнатуру типов в рантайме после загрузки полностью нельзя, зато можно «докомпилировать» и выполнять код над определенными типами. Поэтому и здесь есть исключения, когда надо перераспаковать всю сборку заново. Но это происходит далеко не всегда, как это было обязательным условием в предыдущих версиях .NET с «сырым» кодом.
KRuntime позволяет связывать при загрузке типы на основании их сигнатуры, а не манифеста. В этом суть assembly neutral types и в этом суть тех новых возможностей для рефакторинга, о которых я говорил, кода типы связываються из ресурсов сборки, а не на основании манифеста.
Если бы вы почитали внимательно хоть одну статью из тех, что в топике и понимали о чем речь, то вопросы бы отпали по поводу рефакторинга.

Не совсем так, менять сигнатуру типов в рантайме после загрузки полностью нельзя, зато можно «докомпилировать» и выполнять код над определенными типами.
Как это нужно понимать? Я не могу добавлять новые методы, но я могу, например, менять код уже существующих без изменения их сигнатуры?

Если внимательно прочитать, то в статье как раз говорится, что после того, как тип скомпилирован, и загружен в домен, он не может быть изменен.
Я бы хотел все-таки услышать объяснение как выполняется накат изменений «без надобности перекомпиляции всей сборки».

KRuntime позволяет связывать при загрузке типы на основании их сигнатуры, а не манифеста.
Связывание типов при загрузке на основании их сигнатуры а не манифеста — это новое название duck typing?
В этом суть assembly neutral types и в этом суть тех новых возможностей для рефакторинга, о которых я говорил, кода типы связываються из ресурсов сборки, а не на основании манифеста.
Если бы вы почитали внимательно хоть одну статью из тех, что в топике и понимали о чем речь, то вопросы бы отпали по поводу рефакторинга.
Вопросы не отпадают.
Какое отношение утиная типизация (в конкретном случае — связанная с полным дублированием кода в разных местах) имеет к рефакторингу?
Я бы хотел все-таки услышать объяснение как выполняется накат изменений «без надобности перекомпиляции всей сборки».
могу дать пример api, который известен мне и направить в каком направлении копать на github внутренности:
blogs.msdn.com/...ipting-api.aspx
Какое отношение утиная типизация (в конкретном случае — связанная с полным дублированием кода в разных местах) имеет к рефакторингу?
Это не Duck Typing. Хотя, вопрос странный по сути, потому как каждое добавление как-то фичи связанной с Duck Typing в с# позволяет рефакторить старый код.

В случае с assembly neutral типами они внедряться как embeded resource и шаряться между множеством проектов(сборок). Во время связывания играют роль общего сервис локатора.
Когда вы начинаете рефакторить код с множеством проектов, в случае подключения новой сборки вам нужно обновлять References для каждого проета, здесь, просто меняете ресурс главное что бы Namespace и тип совпадал.
Как думаете, с каким подходом вы сэкономите время на рефакторинге?

могу дать пример api, который известен мне и направить в каком направлении копать на github внутренности:
blogs.msdn.com/...ipting-api.aspx
Инфа по ссылке не имеет отношения к моему вопросу.
Беглый просмотр показывает, что ничего нового в этом плане Roslyn не предлагает, компилятор производит байтовый массив, который потом загружается в домен через Assembly.Load.
Соответственно, модифицировать уже загруженный тип будет невозможно, поскольку сам .NET runtime не представляет таких возможностей.
Это не Duck Typing. Хотя, вопрос странный по сути, потому как каждое добавление как-то фичи связанной с Duck Typing в с# позволяет рефакторить старый код.
В случае с assembly neutral типами они внедряться как embeded resource и шаряться между множеством проектов(сборок). Во время связывания играют роль общего сервис локатора.
Это просто технические детали реализации.
Когда вы начинаете рефакторить код с множеством проектов, в случае подключения новой сборки вам нужно обновлять References для каждого проета, здесь, просто меняете ресурс главное что бы Namespace и тип совпадал.
Как думаете, с каким подходом вы сэкономите время на рефакторинге?
Здравый смысл подсказывает, что, если у меня есть интерфейс, который используется в разных проектах (тот же IServiceLocator), то проще будет этот интерфейс описать в отдельной сборке и подключить ее ко всем проектам, чем описывать копию интерфейса в каждом проекте.
Если потрибуется во время рефакторинга внести изменения в интерфейс, в первом случае достаточно будет сделать это в одном месте и пересобрать решение, во втором — это нужно будет сделать в каждом месте, где тип объявлен.
Беглый просмотр показывает, что ничего нового в этом плане Roslyn не предлагает, компилятор производит байтовый массив, который потом загружается в домен через Assembly.Load.
Я бы с радостью взглянул на исходники, на основании которых был сделан этот вывод, что для вызова кода на уже созданном в рантайме обьекте используеться полная перезагрузка сборки через рефлексию, а потом связывания вызов для обьекта со старыми метаданными.

var report = new Report();

var engine = new ScriptEngine(new[] {

«System.Core», report.GetType().Assembly.Location });

var session = Session.Create(report);

engine.Execute(@"using System.Linq;", session);

engine.Execute(
@"GetValues = () => { for(int i = 1; i <= 3; i++) AddValue(i); };",
session);

engine.Execute(@"CalculateResult = () => Values.Sum();", session);

report.PrintResult();

Здравый смысл подсказывает, что, если у меня есть интерфейс, который используется в разных проектах (тот же IServiceLocator), то проще будет этот интерфейс описать в отдельной сборке и подключить ее ко всем проектам, чем описывать копию интерфейса в каждом проекте.

это шутка? проще в крупном проекте переписать все прежние места инстацирования обьектов обращениями к сервис локатору, чем связать типы во время загрузки приложения?
Это не говоря уже про возмоные последствия использования самого сервис локатора с большим количеством зависимостей в отличии от полноценной Dependency Inversion.

Я бы с радостью взглянул на исходники, на основании которых был сделан этот вывод, что для вызова кода на уже созданном в рантайме обьекте используеться полная перезагрузка сборки через рефлексию, а потом связывания вызов для обьекта со старыми метаданными.
static void Main(string[] args) { var report = new Report(); var engine = new ScriptEngine(new[] { «System.Core», report.GetType().Assembly.Location }); var session = Session.Create(report); engine.Execute(@"using System.Linq;", session); engine.Execute( @"GetValues = () => { for(int i = 1; i <= 3; i++) AddValue(i); };", session); engine.Execute(@"CalculateResult = () => Values.Sum();", session); report.PrintResult(); }
Вы второй раз ссылаетесь на ScriptingEngine, при том, что он не имеет никакого отношения к рассматриваему вопросу?
это шутка? проще в крупном проекте переписать все прежние места инстацирования обьектов обращениями к сервис локатору, чем связать типы во время загрузки приложения?
Это не говоря уже про возмоные последствия использования самого сервис локатора с большим количеством зависимостей в отличии от полноценной Dependency Inversion.
Вопрос был в том, что проще рефакторить — интерфейс, который объявлен в отдельной сборке, или интерфейс, копия которого объявлена в каждой сборке, где он испоьлзуется.
Куда вас понесло на этот раз?

В том примере, что я дал происходят не возможные для вашего понимания дотент вещи, наверное поэтому их не видно. Какое изменение интерфейса при рефакторинге, о чем речь, вы хоть знаете первичные цели рефакторинга? Это кое кого несет непонятно куда

В том примере, что я дал происходят не возможные для вашего понимания дотент вещи, наверное поэтому их не видно.
Расскажите со своей точки понимания .NET что там происходит кроме того что:

1) Описан тип в том числе с двумя полями типа Func и Action
2) ScriptEngine присваивает этим полям значения
3) Исходный метод типа обращается к этим полям

Всё верно. Расскажите как сделаете тоже самое без Рослин имея строку, и без промежуточного типа.присвоите строчные представление функции полю

Во-первых, давайте начнем с того, что ScriptEngine выпилен из текущей версии Roslyn.

Во-вторых, делается это либо через Reflection.Emit (судя по всему, так и делали, но впоследствии отказались), либо предварительно упаковать код в вид, в котором его поймет компилятор C#, откомпилироать, загрузить через Assembly.Load, создать экземпляр типа и передатьв него управление.
Первый вариант реализовать проблематично ввиду высокой сложности парсинга языка C# и отсутствия подходящих инструментов парсинга. Второй вариант абсолютно тривиален.

Возможность интерпретации C# не рассматриваю ввиду малореалистичности реализации в рамках существующего рантайма.

Если у вас есть другие идеи, как реализовать это в рамках существующего рантайма .NET, я готов их выслушать (варианты типа «не важно как, но Roslyn все это может» не принимаются)

Во-первых, давайте начнем с того, что ScriptEngine выпилен из текущей версии Roslyn.
Проверил последнюю версию исходников,
roslyn.codeplex.com/...ScriptEngine.cs
Так же нашел информацию, что фича в процессе доработки?
roslyn.codeplex.com/...=Home#Scripting,
Хотелось бы источник почитать.
Во-вторых, делается это либо через Reflection.Emit (судя по всему, так и делали, но впоследствии отказались), либо предварительно упаковать код в вид, в котором его поймет компилятор C#, откомпилироать, загрузить через Assembly.Load, создать экземпляр типа и передатьв него управление.
Первый вариант реализовать проблематично ввиду высокой сложности парсинга языка C# и отсутствия подходящих инструментов парсинга. Второй вариант абсолютно тривиален.

Оригинальный экземпляр создается явно до обращения к ScriptEnginee, без рефлексии. Следуя вашей логике на выходе будет абсолютно новый тип с модифицированным IL, а не прежний, экземпляр нового типа надо создавать заново, в примере вызовы идут к старому обьекту. что значит «передаеться управление»?
postimg.org/...mage/785g3xk77
Пока ваши обьяснения не рабочие или не полные.

Возможность интерпретации C# не рассматриваю ввиду малореалистичности реализации в рамках существующего рантайма.
Следуя таким заявлениям это надо вам лезть и что-то доказывать с примерами из исходников.
Аргументы в духе: «мое понимание платформы говорит, что это не возможно, а то что декларирует MS не правда, Roslyn — это обертка над стандартным компилятором и рефлексией.»
пока вообще не о чем.
Проверил последнюю версию исходников,
roslyn.codeplex.com/...ScriptEngine.cs
Так же нашел информацию, что фича в процессе доработки?
roslyn.codeplex.com/...=Home#Scripting,
Хотелось бы источник почитать.
Вы сами дали ссылку на источник со стороны MS, который говорит, что в данный момент фича выпилена.

В последней публично доступной версии библиотек нет ScriptEngine, ночные билды MS не выкладывает, лично я не могу пересобрать исходники на своем компьютере, возможно, не хватает каких-то инструментов.

В любом случае смысл спекулировать на тему «как оно работало раньше, но перестало раобтать» или «как оно будет работать в будущем» будет, если разработчики хотя бы выложат описание механизмов.

Оригинальный экземпляр создается явно до обращения к ScriptEnginee, без рефлексии. Следуя вашей логике на выходе будет абсолютно новый тип с модифицированным IL, а не прежний, экземпляр нового типа надо создавать заново, в примере вызовы идут к старому обьекту. что значит «передаеться управление»?
postimg.org/...mage/785g3xk77
Пока ваши обьяснения не рабочие или не полные.
Есть строка:
report.GetValues = () => { for (int i = 1; i <= 3; i++) report.AddValue(i); };

Оборачиваем ее чтоб она была корректным C# кодом

public static class CompiledScript { public static void RunScript(Program.Report report) { report.GetValues = () => { for (int i = 1; i <= 3; i++) report.AddValue(i); }; } }

Компилируем через CodeDom
Загружаем сборку
Вызываем метод RunScript, передаем в экземпляр Report

Компиляция и загрузка сборки — задача тривиальная, поэтому код не привожу.

Следуя таким заявлениям это надо вам лезть и что-то доказывать с примерами из исходников.
Аргументы в духе: «мое понимание платформы говорит, что это не возможно, а то что декларирует MS не правда, Roslyn — это обертка над стандартным компилятором и рефлексией.»
пока вообще не о чем.
Как я и предполагал, идей реализации у вас нет, есть только слепая вера в то, что делает MS, причем при отсутствии понимания что она на самом деле делает.

Перестаньте строить, из себя того кем, вы не есть. И перестаньте на личности переходить рассказывая что я и кто на основании своих безосновательных утверждений, если вы вообще пришли в этот топ не ради развести срач.
------------------
пример рабочий для корректного случая и с костылем, про который я писал в условии.
С реализацией типа контекста ScriptEngine я не знаком, но я имею большие сомнения что там используеться промежуточный тип, и раз уж вы ничего не показали из реализации Roslyn, пока ваш пример ничего не опровергает или подтверждает.
Кроме того что вы можете написать примитивный парсер строки и покрыть им рефлексию. Это ничего не будет иметь общего с тем как работает Roslyn. Почему? Roslyn обладает своим генератором IL кода, как минимум для CS. Ваше представление уже вкорне неверное о технологии и возможно платформе.

Что доказать пытаетесь? что написав парсер строки поверх рефлексии будет тоже самое, что с Roslyn?

С реализацией типа контекста ScriptEngine я не знаком, но я имею большие сомнения что там используеться промежуточный тип, и раз уж вы ничего не показали из реализации Roslyn, пока ваш пример ничего не опровергает или подтверждает.
Мой пример подтверждает, что аналогичную функциональность можно реализовать без использования Roslyn, опровергать это — ваша задача, а не моя.

Я бы мог рассказать вам, как именно работает ScriptEngine, если бы его можно было хотя бы запустить и протестировать (что я, в отличие от вас хотя бы попытался сделать).
Удовольствие ковыряться в исходных кодах, которые не компилируются из коробки, и искать пруфы там я могу предоставить вам, у меня лично очень мало свободного времени, и вы не тот оппонент, который сможет по достоинству оценить эти усилия.

И, раз мы уже дошли до стадии непрошеных советов, я в свою очередь хотел бы посоветовать вам перестать делать вклад в создание образа не совсем неадекватных майкрософтофилов.

Не стоит расстраиваться, генератор IL и анализатор кода это тоже не беда, что бы опять соскакивать с темы, хоть даже и из такой уважительной причины как отсуствие свободного времени, ведь как показывает этот топ желание развести срач все равно берет верх. Смотрите, у вас осталось множество практически реальных аргументов как и дальше уличать майкрософтофилов,ведь я так понимаю именно это было целью отметиться в топике, а не сам сабж?
можно скажем написать свой парсер атрибутов с# на Питоне, а потом просто перед загрузкой проекта, обновить эпизодически код, манифест и прогнать через компилятор в командной строке, вуаля Assembly Neutral Types и практически рантайм на питоне, как раньше дотнетчики не додумались до этого. Ведь это легче чем писать компилятор, а продать можно так же.

Если без сарказма, то вы постоянно пытаетесь опуститься до уровня il, и показать что отдельные фичи Рослин при желании можно сделать отдельно. Ок, с Рослин эти задачи решать проще имея универсальный высокоуровневый Апи, поэтому они и начали появляться именно сейчас на уровне платформы. Так же есть скоп задач, что покрывает Рослин и без него их реализация будет настолько противоестественной и кривой что их даже всерьез никто не рассматривал прежде, assembly neutral types одна из них.

это продают со следующим ASP.NET и Visual Studio2014 внесение правок в с# код будет аналогичным написанию java script кода.
Это работало со времен ASP.NET 2.0
Фактически это позволяет достаточно просто разрешать даже циклические зависимости и не иметь головной боли с неимоверным количеством зависимостей между сборками. Возможности Loose Coupling невиданные прежде в .net.
Можно напримерах без маркетинговой шелухи?
Пока что выглядит так, будто проблему создают для решения, а не наоборот.
Можно напримерах без маркетинговой шелухи?
Вот тут.
Моё понимание что фича предназначена больше для решения уже существующего головняка нежели для открытия «невиданных прежде возможностей».

Девид это позиционирует как хороший задаток для рефакторинга BCL в дальнейшем, но это фича именно K Runtime насколько я понимаю, с которой связанно много потенциально новых возможностей. Сейчас это нативный процесс, который может стартовать .net, mono или core clr native host и разворачивать в нем приложение, как будет развиваться дальше на других платформах посмотрим. Пока реализации core clr native host нету нигде кроме win.

Это работало со времен ASP.NET 2.0
Не знаю писали ли вы java script, но там процесс несколько другой чем при Edit and Continue в c#

Работало. Весь сайт загружался на веб-сервер в исходниках, разумеется, была возможность внести изменения в любой сайт. Изменения становились доступными сразу, не было небоходимости компилировать сайт ручками.

Весь сайт загружался на веб-сервер в исходниках, разумеется, была возможность внести изменения в любой сайт. Изменения становились доступными сразу, не было небоходимости компилировать сайт ручками.
Я правильно понял, что предоставляется возможность задеплоить проект без компиляции и __без прогонки тестов__?
__без прогонки тестов__
Этот код был вообще нетестируемый. так что проганять было нечего.

Теперь понял о чем вы.
Речь немного о разных, хоть в чем-то и похожих вещах. То о чем вы говорите — это фича скорее IIS и настройки recycle events(для серверных страничек *.asmx, *.aspx) и возможности тех времен, когда ASP.NET не мог жить без System.Web.
msdn.microsoft.com/...0(v=vs.80).aspx

Следующий ASP.NET вообще никак не связан с IIS. Даже Microsoft.AspNet.Hosting теперь Host agnostic — все что ему нужно это listener + owin application dictionary на вход для запроса.
Даже под IIS Asp.Net vNext будет жить поверх Helios — который полностью искореняет System.Web из IIS pipe.
Так вот в этом режиме изменение in process касаються абсолютно любого cs кода и не классических asp.net расширений.

Следующий ASP.NET вообще никак не связан с IIS. Даже Microsoft.AspNet.Hosting теперь Host agnostic — все что ему нужно это listener + owin application dictionary на вход для запроса.
Даже под IIS Asp.Net vNext будет жить поверх Helios — который полностью искореняет System.Web из IIS pipe.
Так вот в этом режиме изменение in process касаються абсолютно любого cs кода и не классических asp.net расширений.
Это все отлично, но как я писал выше, не понятно, какую проблему это решает.

Возможность деплоить веб-сайты в виде исходного кода давно была. В современных реалиях это имеет очень невысокую ценность, так как давно существуют системы автоматизированной сборки и деплоймента.

Возможность хостить ASP.NET приложение вне IIS может быть интересна, если имеется в виду возможность хостить его в апаче на линуксе

Возможность деплоить веб-сайты в виде исходного кода давно была. В современных реалиях это имеет очень невысокую ценность, так как давно существуют системы автоматизированной сборки и деплоймента.

не принимаеться, так как это фича веб-сервера для специфических случаев, а не платформы разработки независимой от Asp.net.

Возможности само собой в другом. Новые инструменты рефакторинга и дизайна приложений, отсуствие необходимости привязываться к десктопной версии фреймворка в дальнейшем, открытый компилятор, на который переходит MS, что так же говорит в пользу еще более быстрого рызвития языка в дальнейшем.

Пока что выглядит так, будто проблему создают для решения, а не наоборот.
Проблему создает кто? Разработчик Open source продукта? откровенно говоря странный тезис.
не принимаеться, так как это фича веб-сервера для специфических случаев, а не платформы разработки независимой от Asp.net.
Ну вообще-то это не фича веб-сервера, а фича самого ASP.NET
Новые инструменты рефакторинга
Какие инструменты рефакторинга станут возможными благодаря Roslyn, которые не существуют сегодня?
дизайна приложений
Каким образом опенсорцный компилятор повлияет на дизайн приложений?
отсуствие необходимости привязываться к десктопной версии фреймворка в дальнейшем
Как и сейчас, в системных требованиях приложения будет минимально необходимая версия и поддержка всех новых версий
открытый компилятор, на который переходит MS, что так же говорит в пользу еще более быстрого рызвития языка в дальнейшем?
Пошла копипаста из пресс релизов MS
Ну вообще-то это не фича веб-сервера, а фича самого ASP.NET

Очень сильное заявление, особенно учитывая что та часть ASP.NET стека, о которой вы говорите без IIS не существует.

Какие инструменты рефакторинга станут возможными благодаря Roslyn, которые не существуют сегодня?
Assembly neutral types.
Каким образом опенсорцный компилятор повлияет на дизайн приложений?
Избавит от необходимости явно помещать типы в сборки, избавить от необходимости создавать тесные связи и уменьшит количество дубликатов.
Как и сейчас, в системных требованиях приложения будет минимально необходимая версия и поддержка всех новых версий
Вы уверенные или просто что-то возразить охота? В режиме Core CLR не загружается даже десктопный mscorlib.
Еще аргументы по поводу системных требований.
Очень сильное заявление, особенно учитывая что та часть ASP.NET стека, о которой вы говорите без IIS не существует.
Возможно, но это не значит что это фича веб-сервера.
Конкретно то, о чем шла речь, скорее всего реализовано внутри ISAPI расширения ASP.NET, и называть это фичей IIS лично я не могу.
В любом случае — эта фича уже была и работала.
Assembly neutral types.
Причем это к рефакторингу?

Assembly neutral types
Избавит от необходимости явно помещать типы в сборки, избавить от необходимости создавать тесные связи и уменьшит количество дубликатов.
Это опять копипаста из пресс-релизов? Покажите на реальном примере где возникает проблема и как она может быть решена с помощью этих возможностей.

Какой isapi?) это не расширение асп нет, а древний модуль иис. Это скорее сейчас часть system Web уже, и даже если так это часть веб-фреймворка или в древние времена как вы говорите, модуля который использовал иис для взаимодействия с асп, с roslyn это часть рантайма. этот функционал работает везде и без студии или веб сервера или асп. По поводу рефакторинга, почитайте ссылку выше и davidfowl.com/...implementation там достаточно ясно объяснено с примерами по поводу типов и почему это относиться к рефакторингу с реальными примерами. По остальному это отдельная тема АОР, потом.

Какой isapi?) это не расширение асп нет, а древний модуль иис. Это скорее сейчас часть system Web уже, и даже если так это часть веб-фреймворка или в древние времена как вы говорите, модуля который использовал иис для взаимодействия с асп
en.wikipedia.org/...sapi#Extensions

В IIS 5/6 ASP.NET не был частью веб-сервера, и функциональность ASP.NET подключалась к IIS через ISAPI (если не ошибаюсь, aspnet_isapi.dll)

с roslyn это часть рантайма. этот функционал работает везде и без студии или веб сервера или асп.
Есть задача:
1) Есть каталог с исходным кодом веб-приложения (файлы с C# кодом)
2) При запуске приложения нужно скомпилировать эти файлы, загрузить скомпилированную сборку в память и направлять определенные вызовы внутрь этой сборки
3) При изменении какого-то файла нужно автоматически перекомпилировать сборку.

Какой именно из вышеперечисленых пунктов нереализуем с использованием инструментов, доступных в .NET версии 1.0?

То, что компоненты ASP.NET исторически имеют очень высокую связанность, это фейл, допущенный при дизайне ASP.NET, он решается болезненным редизайном, что начали делать в ASP.NET MVC.

По поводу рефакторинга, почитайте ссылку выше и davidfowl.com/...implementation там достаточно ясно объяснено с примерами по поводу типов и почему это относиться к рефакторингу с реальными примерами. По остальному это отдельная тема АОР, потом.
С сожалением для себя выяснил, что автор является членом команды ASP.NET.

И, собсотвенно, что там относится к рефакторингу?

Вы действительно решили затеять спор ради спора? По поводу задачки понятно, что автоматизируються процесс сборки при наличии приложения хоста, перезагрузке процесса или использовании рефлексии. Рослин представляет Апи, который позволяет все это выполнять естественным путем в текущей сборке, без надобности иметь доступ к файловой системе или перекомпиляции всей сборки в памяти как в случае с reflection emit. Складывается впечатление что вам важно не как, а что если предлагают авто вы с подозрением будете отстаивать позицию достаточности велосипеда.

Подписаться на комментарии