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.
Кто что думает по поводу данных новшеств? Может еще что-то интересно успел отметить для себя уже.
36 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівКоментар порушує правила спільноти і видалений модераторами.
Мое понимание механизмов рантайма .NET говорит, что это невозможно.
Вместе с Roslyn выпускается новая версия рантайма, в которой поддерживаются такие патчи на живом приложении? Как это сказывается на производительности?
Не совсем так, менять сигнатуру типов в рантайме после загрузки полностью нельзя, зато можно «докомпилировать» и выполнять код над определенными типами. Поэтому и здесь есть исключения, когда надо перераспаковать всю сборку заново. Но это происходит далеко не всегда, как это было обязательным условием в предыдущих версиях .NET с «сырым» кодом.
KRuntime позволяет связывать при загрузке типы на основании их сигнатуры, а не манифеста. В этом суть assembly neutral types и в этом суть тех новых возможностей для рефакторинга, о которых я говорил, кода типы связываються из ресурсов сборки, а не на основании манифеста.
Если бы вы почитали внимательно хоть одну статью из тех, что в топике и понимали о чем речь, то вопросы бы отпали по поводу рефакторинга.
Если внимательно прочитать, то в статье как раз говорится, что после того, как тип скомпилирован, и загружен в домен, он не может быть изменен.
Связывание типов при загрузке на основании их сигнатуры а не манифеста — это новое название duck typing? Вопросы не отпадают.Я бы хотел все-таки услышать объяснение как выполняется накат изменений «без надобности перекомпиляции всей сборки».
Какое отношение утиная типизация (в конкретном случае — связанная с полным дублированием кода в разных местах) имеет к рефакторингу?
blogs.msdn.com/...ipting-api.aspx Это не Duck Typing. Хотя, вопрос странный по сути, потому как каждое добавление как-то фичи связанной с Duck Typing в с# позволяет рефакторить старый код.
В случае с assembly neutral типами они внедряться как embeded resource и шаряться между множеством проектов(сборок). Во время связывания играют роль общего сервис локатора.
Когда вы начинаете рефакторить код с множеством проектов, в случае подключения новой сборки вам нужно обновлять References для каждого проета, здесь, просто меняете ресурс главное что бы Namespace и тип совпадал.
Как думаете, с каким подходом вы сэкономите время на рефакторинге?
Беглый просмотр показывает, что ничего нового в этом плане Roslyn не предлагает, компилятор производит байтовый массив, который потом загружается в домен через Assembly.Load.
Соответственно, модифицировать уже загруженный тип будет невозможно, поскольку сам .NET runtime не представляет таких возможностей. Это просто технические детали реализации. Здравый смысл подсказывает, что, если у меня есть интерфейс, который используется в разных проектах (тот же IServiceLocator), то проще будет этот интерфейс описать в отдельной сборке и подключить ее ко всем проектам, чем описывать копию интерфейса в каждом проекте.
Если потрибуется во время рефакторинга внести изменения в интерфейс, в первом случае достаточно будет сделать это в одном месте и пересобрать решение, во втором — это нужно будет сделать в каждом месте, где тип объявлен.
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();
это шутка? проще в крупном проекте переписать все прежние места инстацирования обьектов обращениями к сервис локатору, чем связать типы во время загрузки приложения?
Это не говоря уже про возмоные последствия использования самого сервис локатора с большим количеством зависимостей в отличии от полноценной Dependency Inversion.
Куда вас понесло на этот раз?
В том примере, что я дал происходят не возможные для вашего понимания дотент вещи, наверное поэтому их не видно. Какое изменение интерфейса при рефакторинге, о чем речь, вы хоть знаете первичные цели рефакторинга? Это кое кого несет непонятно куда
1) Описан тип в том числе с двумя полями типа Func и Action
2) ScriptEngine присваивает этим полям значения
3) Исходный метод типа обращается к этим полям
Всё верно. Расскажите как сделаете тоже самое без Рослин имея строку, и без промежуточного типа.присвоите строчные представление функции полю
Во-первых, давайте начнем с того, что ScriptEngine выпилен из текущей версии Roslyn.
Во-вторых, делается это либо через Reflection.Emit (судя по всему, так и делали, но впоследствии отказались), либо предварительно упаковать код в вид, в котором его поймет компилятор C#, откомпилироать, загрузить через Assembly.Load, создать экземпляр типа и передатьв него управление.
Первый вариант реализовать проблематично ввиду высокой сложности парсинга языка C# и отсутствия подходящих инструментов парсинга. Второй вариант абсолютно тривиален.
Возможность интерпретации C# не рассматриваю ввиду малореалистичности реализации в рамках существующего рантайма.
Если у вас есть другие идеи, как реализовать это в рамках существующего рантайма .NET, я готов их выслушать (варианты типа «не важно как, но Roslyn все это может» не принимаются)
roslyn.codeplex.com/...ScriptEngine.cs
Так же нашел информацию, что фича в процессе доработки?
roslyn.codeplex.com/...=Home#Scripting,
Хотелось бы источник почитать.
Оригинальный экземпляр создается явно до обращения к ScriptEnginee, без рефлексии. Следуя вашей логике на выходе будет абсолютно новый тип с модифицированным IL, а не прежний, экземпляр нового типа надо создавать заново, в примере вызовы идут к старому обьекту. что значит «передаеться управление»?
Следуя таким заявлениям это надо вам лезть и что-то доказывать с примерами из исходников.postimg.org/...mage/785g3xk77
Пока ваши обьяснения не рабочие или не полные.
Аргументы в духе: «мое понимание платформы говорит, что это не возможно, а то что декларирует MS не правда, Roslyn — это обертка над стандартным компилятором и рефлексией.»
пока вообще не о чем.
В последней публично доступной версии библиотек нет ScriptEngine, ночные билды MS не выкладывает, лично я не могу пересобрать исходники на своем компьютере, возможно, не хватает каких-то инструментов.
В любом случае смысл спекулировать на тему «как оно работало раньше, но перестало раобтать» или «как оно будет работать в будущем» будет, если разработчики хотя бы выложат описание механизмов.
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, причем при отсутствии понимания что она на самом деле делает.Перестаньте строить, из себя того кем, вы не есть. И перестаньте на личности переходить рассказывая что я и кто на основании своих безосновательных утверждений, если вы вообще пришли в этот топ не ради развести срач.
------------------
пример рабочий для корректного случая и с костылем, про который я писал в условии.
С реализацией типа контекста ScriptEngine я не знаком, но я имею большие сомнения что там используеться промежуточный тип, и раз уж вы ничего не показали из реализации Roslyn, пока ваш пример ничего не опровергает или подтверждает.
Кроме того что вы можете написать примитивный парсер строки и покрыть им рефлексию. Это ничего не будет иметь общего с тем как работает Roslyn. Почему? Roslyn обладает своим генератором IL кода, как минимум для CS. Ваше представление уже вкорне неверное о технологии и возможно платформе.
Что доказать пытаетесь? что написав парсер строки поверх рефлексии будет тоже самое, что с Roslyn?
Я бы мог рассказать вам, как именно работает ScriptEngine, если бы его можно было хотя бы запустить и протестировать (что я, в отличие от вас хотя бы попытался сделать).
Удовольствие ковыряться в исходных кодах, которые не компилируются из коробки, и искать пруфы там я могу предоставить вам, у меня лично очень мало свободного времени, и вы не тот оппонент, который сможет по достоинству оценить эти усилия.
И, раз мы уже дошли до стадии непрошеных советов, я в свою очередь хотел бы посоветовать вам перестать делать вклад в создание образа не совсем неадекватных майкрософтофилов.
Не стоит расстраиваться, генератор IL и анализатор кода это тоже не беда, что бы опять соскакивать с темы, хоть даже и из такой уважительной причины как отсуствие свободного времени, ведь как показывает этот топ желание развести срач все равно берет верх. Смотрите, у вас осталось множество практически реальных аргументов как и дальше уличать майкрософтофилов,ведь я так понимаю именно это было целью отметиться в топике, а не сам сабж?
можно скажем написать свой парсер атрибутов с# на Питоне, а потом просто перед загрузкой проекта, обновить эпизодически код, манифест и прогнать через компилятор в командной строке, вуаля Assembly Neutral Types и практически рантайм на питоне, как раньше дотнетчики не додумались до этого. Ведь это легче чем писать компилятор, а продать можно так же.
Если без сарказма, то вы постоянно пытаетесь опуститься до уровня il, и показать что отдельные фичи Рослин при желании можно сделать отдельно. Ок, с Рослин эти задачи решать проще имея универсальный высокоуровневый Апи, поэтому они и начали появляться именно сейчас на уровне платформы. Так же есть скоп задач, что покрывает Рослин и без него их реализация будет настолько противоестественной и кривой что их даже всерьез никто не рассматривал прежде, assembly neutral types одна из них.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Пока что выглядит так, будто проблему создают для решения, а не наоборот.
Моё понимание что фича предназначена больше для решения уже существующего головняка нежели для открытия «невиданных прежде возможностей».
Девид это позиционирует как хороший задаток для рефакторинга BCL в дальнейшем, но это фича именно K Runtime насколько я понимаю, с которой связанно много потенциально новых возможностей. Сейчас это нативный процесс, который может стартовать .net, mono или core clr native host и разворачивать в нем приложение, как будет развиваться дальше на других платформах посмотрим. Пока реализации core clr native host нету нигде кроме win.
Работало. Весь сайт загружался на веб-сервер в исходниках, разумеется, была возможность внести изменения в любой сайт. Изменения становились доступными сразу, не было небоходимости компилировать сайт ручками.
именно так
Теперь понял о чем вы.
Речь немного о разных, хоть в чем-то и похожих вещах. То о чем вы говорите — это фича скорее 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 может быть интересна, если имеется в виду возможность хостить его в апаче на линуксе
не принимаеться, так как это фича веб-сервера для специфических случаев, а не платформы разработки независимой от Asp.net.
Возможности само собой в другом. Новые инструменты рефакторинга и дизайна приложений, отсуствие необходимости привязываться к десктопной версии фреймворка в дальнейшем, открытый компилятор, на который переходит MS, что так же говорит в пользу еще более быстрого рызвития языка в дальнейшем.
Проблему создает кто? Разработчик Open source продукта? откровенно говоря странный тезис.Очень сильное заявление, особенно учитывая что та часть ASP.NET стека, о которой вы говорите без IIS не существует.
Assembly neutral types. Избавит от необходимости явно помещать типы в сборки, избавить от необходимости создавать тесные связи и уменьшит количество дубликатов. Вы уверенные или просто что-то возразить охота? В режиме Core CLR не загружается даже десктопный mscorlib.Еще аргументы по поводу системных требований.
Конкретно то, о чем шла речь, скорее всего реализовано внутри ISAPI расширения ASP.NET, и называть это фичей IIS лично я не могу.
В любом случае — эта фича уже была и работала. Причем это к рефакторингу? Это опять копипаста из пресс-релизов? Покажите на реальном примере где возникает проблема и как она может быть решена с помощью этих возможностей.
Какой isapi?) это не расширение асп нет, а древний модуль иис. Это скорее сейчас часть system Web уже, и даже если так это часть веб-фреймворка или в древние времена как вы говорите, модуля который использовал иис для взаимодействия с асп, с roslyn это часть рантайма. этот функционал работает везде и без студии или веб сервера или асп. По поводу рефакторинга, почитайте ссылку выше и davidfowl.com/...implementation там достаточно ясно объяснено с примерами по поводу типов и почему это относиться к рефакторингу с реальными примерами. По остальному это отдельная тема АОР, потом.
В IIS 5/6 ASP.NET не был частью веб-сервера, и функциональность ASP.NET подключалась к IIS через ISAPI (если не ошибаюсь, aspnet_isapi.dll)
1) Есть каталог с исходным кодом веб-приложения (файлы с C# кодом)
2) При запуске приложения нужно скомпилировать эти файлы, загрузить скомпилированную сборку в память и направлять определенные вызовы внутрь этой сборки
3) При изменении какого-то файла нужно автоматически перекомпилировать сборку.
Какой именно из вышеперечисленых пунктов нереализуем с использованием инструментов, доступных в .NET версии 1.0?
То, что компоненты ASP.NET исторически имеют очень высокую связанность, это фейл, допущенный при дизайне ASP.NET, он решается болезненным редизайном, что начали делать в ASP.NET MVC.
С сожалением для себя выяснил, что автор является членом команды ASP.NET.И, собсотвенно, что там относится к рефакторингу?
Вы действительно решили затеять спор ради спора? По поводу задачки понятно, что автоматизируються процесс сборки при наличии приложения хоста, перезагрузке процесса или использовании рефлексии. Рослин представляет Апи, который позволяет все это выполнять естественным путем в текущей сборке, без надобности иметь доступ к файловой системе или перекомпиляции всей сборки в памяти как в случае с reflection emit. Складывается впечатление что вам важно не как, а что если предлагают авто вы с подозрением будете отстаивать позицию достаточности велосипеда.