Runtime: Перенос Workflow Foundation в .NET Core

Копия: @terrajobst , @joshfree , @weshaggard

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

Я понимаю @jakesays .

Дело в том, что определения рабочего процесса WF могут быть сделаны в классах C# вместо XAML (на данный момент), и многие люди даже не используют его представление XAML. Позже, когда System.Xaml будет открыт, мы также сможем интегрировать визуальный конструктор и определения XAML. Кроме того, мы работаем над механизмом рабочего процесса, который строго следует использованию/реализации WF, но вместо использования XAML в качестве базового хранилища для определений рабочих процессов мы используем его на основе Json для хранилища, что открывает множество возможностей для новых разработчиков рабочих процессов в любой среде. платформы (не только VS или размещенный компонент конструктора для WPF/WForms) и имеют несколько преимуществ, таких как более быстрое чтение/запись, простота схемы, более быстрая загрузка/компиляция и операции во время выполнения. Его можно даже использовать для поддержки клиентских рабочих процессов, например, для управления потоками пользовательского интерфейса приложений в приложениях Windows Phone/Store из-за его облегченной среды выполнения.

Я действительно думаю, что WF - ДЕЙСТВИТЕЛЬНО мощный компонент на платформе .Net, но для современных технологий XAML по-прежнему является его "ограничителем", но, если для стратегического решения MS мы можем оставить его как есть и перенести на CoreCLR.

Спасибо

@zhenlan может рассказать о текущих взглядах на WF

@galvesribeiro многие люди могут не использовать xaml, но многие это делают, и он действительно считается основной частью WF. Мы широко используем xaml, поэтому я считаю, что WF без поддержки xaml вряд ли стоит использовать.

Я бы предпочел, чтобы мы продолжали лоббировать Microsoft, чтобы открыть System.Xaml.

И использование JSON в качестве замены просто не привлекательно.

@galvesribeiro @jakesays Нам очень нравится узнавать, насколько клиенты WF заинтересованы в наличии версии WF для .NET Core, поэтому приятно слышать отзывы от сообщества. Если будет достаточный спрос, нам будет полезно двигаться вперед.

Мы находимся на ранней стадии оценки осуществимости, зависимостей, приоритетов функций и т. д. Поэтому нам будет очень полезно узнать, какие сценарии вы имеете в виду, почему WF на .NET Core (по сравнению с WF на полной .NET) будет полезный для вас и какие функции WF вы хотели бы увидеть в первую очередь.

@galvesribeiro В вашем сценарии с созданием рабочих процессов в коде и сохранением этих определений в формате JSON, что вы (планируете?) использовать для выражений? Используете ли вы выражения VB, выражения C# или у вас есть собственные действия с выражениями, основанные на CodeActivity, для работы с выражениями?

Спасибо за отзыв.

@jakeговорит , что я могу использовать XAML. Меня волнует только производительность...

@zhenlan У нас есть электронный платежный коммутатор, который обрабатывает миллиарды транзакций по кредитным / дебетовым картам в день для некоторых банков в Бразилии и некоторых других за рубежом. Мы были полностью локальными, и мы обновляем технологию, чтобы она стала полностью облачной и предлагалась как услуга в Azure. Мы получили соглашение Enterprise, чтобы изучить все, что нам нужно, от Azure здесь в качестве многопользовательской платформы обработки платежей для наших клиентов.

Мы изучаем использование NanoServer для и CoreCLR, чтобы уменьшить занимаемую площадь, поверхность атаки и затраты на обслуживание для запуска наших сервисов, и мы заметили, что coreCLR еще не перенесла (по крайней мере) System.Activities. Другими словами, нет Workflow Foundation.

Наш основной механизм обработки — это бизнес-движок, построенный на основе WF, и он содержит более 40 настраиваемых действий, ориентированных на наш бизнес. Этот движок обрабатывает в режиме реального времени процесс/правила транзакции, чтобы получить одобрение транзакции. Нам нужно масштабировать его по требованию, а сделать это с текущей реализацией WF в облаке, скажем так, невозможно.

Перенос его на .net core вместо того, чтобы оставить его на .net full (профиль сервера), откроет возможности для запуска клиентских рабочих процессов, чего нам очень не хватает в нашем бизнесе. Эти клиентские рабочие процессы могут заставить людей разрабатывать декларативную клиент-бизнес-логику таким образом, чтобы небольшие устройства, такие как смартфоны, носимые устройства, IoT и наши платежные терминалы, могли принимать некоторые решения без написания реального повторяющегося кода.

Поскольку мы не обнаружили никаких усилий по WF для .net Core, и даже он не менялся годами и все еще зависел от XAML, мы решили запустить свой собственный Workflow Engine, который ведет себя точно так же, как WF. Та же модель действий, тот же стиль кода и т. д., но они намного легче и основаны на Json в качестве хранилища их определений. Это позволяет устройствам с небольшой вычислительной мощностью обрабатывать рабочие процессы без накладных расходов на работу с XAML/XML, поэтому большая часть нашего кода, созданного для WF, работает без многих изменений в определениях Json вместо рабочих процессов на основе XAML. Кроме того, отказ от XAML откроет возможность для новых дизайнеров рабочих процессов... Не зацикливаться на Visual Studio и приложениях WPF для повторного размещения конструктора VS.

Я пытаюсь предложить один из этих вариантов:

1. Перенесите WF (с XAML) как есть на ядро ​​.Net. Этот вариант займет намного больше времени, так как сегодня WF зависит от профиля сервера .Net, что заставит нас потратить много времени на его развязку, чтобы заставить его работать с ядром .Net.
2. Порт WF переписывает его на ядро ​​.Net. Таким образом, мы можем получить основные концепции и сосредоточиться на разработке более легкого движка, который может работать на серверах, клиентах, IoT или на чем угодно, сохраняя принципы проектирования и функции, которые в настоящее время реализованы в WF. Таким образом, мы делаем процесс перехода от XAML к (например) определениям рабочего процесса на основе Json с минимальными усилиями и без трения. Все текущие действия должны быть перенесены на новую модель.

Я не прошу вас создать команду или заниматься новым продуктом. Сообщество может сделать это так же, как они делают для ASP.Net и Entity Framework. Сделать его внешним и вспомогательным каркасом, не заложенным в ядро.

Спасибо

@jimcarley Выражения будут скомпилированы так же, как сегодня в XAML. В одном из наших рабочих процессов у нас есть это (это также может быть VBValue, только что полученный образец):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

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

Если вы посмотрите на Azure Resource Manager (ARM), они уже сделали это! У них развертывание ресурсов выполнено в виде шаблона Json, который имеет зависимости и поток, а переменные можно вызывать как выражения. Взгляните на это:

"переменные": {
"location": "[resourceGroup().location]",
"usernameAndPassword": "[concat('параметры('имя пользователя'), ':', параметры('пароль'))]",
"authorizationHeader": "[concat('Basic', base64(переменные('usernameAndPassword')))]"
}

Хорошо, они используют функции JavaScript, но принцип тот же. У них есть переменная $schema поверх шаблона, которая определяет структуру документа, этапы процесса развертывания, которые мы можем сделать как действия. Дизайн очень похож на WF, но этот DSL фокусируется на развертывании группы ресурсов. Мы можем сделать его более общим и использовать действия так же, как в текущей реализации WF.

Если вы, ребята, решите, что стоит попробовать, мы можем начать рисовать документацию по другому вопросу, который будет определять архитектуру «нового WF». Если это звучит так безумно и не входит в ваши планы, дайте мне знать, мы все равно разработаем его с нашей стороны для поддержки ядра .net, а позже выпустим его как nuget для людей. Я просто пытаюсь обновить эту замечательную структуру с учетом текущих (будущих) технологий. Это действительно бизнес-потребность для нас. Мы во многом зависим от WF, но если он не станет быстрее и не будет поддерживаться в coreCLR, нам нужно будет начать подготовку этой новой среды, чтобы, когда NanoServer+coreCLR станут RTM, мы могли перейти на нее.

Пожалуйста, дайте мне знать, если у вас есть какие-либо вопросы.

Спасибо

PS: я каждый день на гиттер-каналах, если вам нужно поболтать.

@galvesribeiro Итак, вы используете TextExpressionCompiler для компиляции выражений после создания объекта Activity из определения рабочего процесса, хранящегося в JSON. Правильно?

@jimcarley , у нас еще не работает компилятор выражений. Мы по-прежнему разрабатываем его, используя те же принципы, что и TextExpressionCompiler, но да, это похоже на ту же концепцию. Текущие реализации, похоже, пока привязаны к System.XAML. Поскольку он не открыт, я не могу подтвердить, будет ли он работать так же (внутренне), как TextExpressionCompiler, но да, после загрузки действия мы должны оценить/скомпилировать выражения (если они еще не находятся в кеше) и выставить объект Expression на нем для оценки потребителями деятельности (при необходимости).

В прошлом году я немного поработал над выражениями, чтобы включить поддержку выражений C# в конструкторах WF, размещенных на собственном хостинге. Он был основан на битах nrefactory и roslyn. Могу раскопать, если кому интересно.

@galvesribeiro, подумав больше о вашем подходе json, в конце концов, я думаю, это действительно не имеет значения для новой разработки. Если MS не откроет поддержку xaml, это может сработать.

@zhenlan Я согласен с @galvesribeiro в том, что мы не обязательно ищем MS для формирования команды для портирования WF. Это определенно то, что сообщество могло бы сделать под руководством вашей команды и т. д.

@jakesays Я согласен с вами, что хранилище на самом деле не имеет значения, если мы снова создаем WF для coreclr.

Дело в том, зачем продолжать использовать XML вместо Json, поскольку у нас есть много тестов в Интернете, сравнивающих производительность (де) сериализации обоих, и json намного быстрее и потребляет меньше ресурсов, чем это? (например, сравнение Json.Net от Newtonsoft с обычный XML-сериализатор) Если WF будет работать на небольшом клиентском устройстве (любой IoT), каждый байт памяти имеет значение.

Кроме того, с json намного проще сразу получить новых веб-дизайнеров WF. Компиляцию и выполнение выражения реализовать несложно. Это примерно анализатор строки для построения объекта выражения. Трудная часть (имхо) состоит в том, чтобы получить intellisense в VS для типов, используемых при разработке WF, но я почти уверен, что Roselyn и языковые службы могут помочь нам с этим, и VS имеет для этого инфраструктуру.

@galvesribeiro , вы упомянули, что уже создали свой собственный механизм рабочего процесса с определением и сериализацией рабочего процесса на основе JSON. Если бы WF был портирован на Core, стали бы вы им пользоваться?

@dmetzgar мы начали разрабатывать и тестировать его как доказательство того, что мы можем добиться лучшего результата в более чистом WF, почти не зависящем от фреймворка, что хорошо, когда он работает на coreclr. У нас это не готово.

Я хотел бы не создавать свой собственный движок и продолжать использовать WF, даже если он основан на XAML, но перенесен на coreclr, и если он следует той же концепции версий coreclr EntityFramework и ASP.Net, например (не зависит от серверные библиотеки и работает везде).

Дело в том, что если он по-прежнему будет зависеть от XAML и профиля сервера, он будет работать медленно (требуя слишком много ресурсов), ограниченным выбором дизайнера и т. д.

Мое предложение состоит в том, чтобы перенести его на coreclr с помощью Json и удалить множество зависимостей, которые у него есть сегодня, чтобы пользователь мог запускать его где угодно, так же, как вы можете запускать ASP.Net vNext на устройстве IoT ARM (скоро, как поддержка ARM готово!) и не беспокойтесь о зависимостях и высоком потреблении ресурсов.

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

ИМХО, перенос его на coreclr в том виде, в каком он есть, не приносит столько преимуществ, если только кто-то не предложит супер новый легкий движок для синтаксического анализа/рендеринга XAML/XML как во время выполнения, так и во время разработки. Но если вы, ребята, решите портировать как есть, мы все равно продолжим его использовать, поскольку он заставит мои рабочие процессы XAML работать (я надеюсь) с 0-го дня, даже если я знаю, что это не принесет никакой практической пользы...

Опять же, я (вероятно, @jakesays и другие пользователи WF) могу помочь с этим портом в обоих направлениях (XAML или JSON), независимо от вашего решения. Я просто хочу убедиться, что этот порт не просто копирует, вставляет и исправляет, чтобы заставить его работать, а вместо этого приносит реальную пользу людям, которые его используют, следуя той же идее coreclr, и он может работать везде без проблем.

Спасибо

@galvesribeiro Я согласен с тем, что XAML слишком тесно интегрирован в WF. Возвращаясь к оригинальной книге Дхармы о рабочем процессе, у него был образец, в котором был построен рабочий процесс из Visio. По крайней мере, с переносом на ядро ​​мы можем разделить его, чтобы среда выполнения была отделена от XAML. Это позволяет нам продолжить с портированием команды XAML на ядро ​​или без него, и мы всегда можем добавить поддержку рабочего процесса XAML позже в виде отдельного проекта GitHub или пакета NuGet. Я определенно за то, чтобы можно было определять и сохранять рабочие процессы в любом формате. Спасибо, этот отзыв полезен.

@dmetzgar У меня нет сомнений, что когда-нибудь XAML будет портирован на ядро ​​​​... Если ядро ​​​​.net будет работать на Windows Phone или любом мобильном устройстве с Windows 10, это произойдет в какое-то время, и я полностью согласен с вами, что мы можем построить новое ядро, а позже добавить постоянство как определений, так и состояния рабочего процесса.

Итак, что нам нужно сделать, чтобы начать его портировать? (мы уже подписали соглашение о содействии и имеем другие соглашения о неразглашении как компания с MS и т. д.)

Спасибо

@galvesribeiro Я ценю энтузиазм! Как бы ни было заманчиво открыть репозиторий GitHub и начать взламывать его, необходимо выполнить несколько шагов. Кроме того, не только System.Xaml нужно вырезать. Существуют и другие зависимости, глубоко укоренившиеся в WF, такие как System.Transactions и некоторые общие компоненты с WCF. Мы изучаем каждый из них.

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

@dmetzgar Рассматривали ли вы публикацию частей, исходный код которых может быть открыт прямо сейчас, на https://github.com/Microsoft/referencesource? Я думаю, что это может быть значительно проще, чем создание полноценного проекта с открытым исходным кодом, который действительно работает.

Таким образом, вы можете не торопиться с правильной версией, а другие тем временем могут создавать свои собственные частичные/пользовательские версии.

Компоненты @svick WF в полной https://github.com/Microsoft/referencesource/tree/master/System.Activities.

@zhenlan да, проблема в том, что некоторые зависимости не являются «разрешимыми» ... Я не могу понять, как правильно ведут себя некоторые классы, из-за его зависимости от System.Xaml, который не является общедоступным ...

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

@dmetzgar System.Transaction — это то, что не открыто (пока?), но я думаю, что мы можем с этим справиться (пока). Что касается WCF, дерево зависимостей показывает мне только действия и узел служб рабочих процессов. Ничто в ядре (IIRC) не зависит от WCF...

@galvesribeiro Ситуация с System.Transactions сложнее. Он разбросан по всей среде выполнения WF и сильно зависит от надежного создания экземпляров, где базовые классы служат для обеспечения устойчивости. WCF и WF были объединены в одну команду в период времени .Net 4.0, поэтому у нас есть такие вещи, как System.ServiceModel.Internals, используемые как WCF, так и WF. В .Net core портировано много важных вещей, но многого не хватает. Работа над отсутствующими частями может потребовать изменения дизайна или переписывания функций.

Ни одна из этих проблем не является непреодолимой, я просто не хочу упрощать усилия. Это касается кода и всего, что с ним связано, например, получения юридического разрешения, создания среды, тестирования инфраструктуры и т. д. Мы определенно хотим, чтобы сообщество помогло, и мы работаем над этим. Следует ли вам написать свой собственный порт или дождаться «официального», зависит от ваших временных рамок. Запуск рабочих процессов на сервере Nano — один из наших самых больших сценариев, и я хотел бы получить вашу помощь в этом.

@dmetzgar Я понял, у меня всегда была некоторая задержка, когда любой вопрос нужно было направить в отдел по связям с общественностью или в юридический отдел, когда я был на вашей стороне :)

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

Пожалуйста, дайте мне знать, если мы можем что-то сделать, или если у вас есть какие-либо новости, или свяжитесь со мной, если вам нужно какое-либо предложение относительно дизайна/порта.

Спасибо

По мере уточнения сроков я буду обновлять эту тему. Я был бы рад услышать, какие другие сценарии интересуют людей. WF на Nano сейчас является основным сценарием, но было бы неплохо узнать, что делают другие.

Привет, ребята, помимо XAML и JSON, есть КРУТОЙ способ составления действий: метапрограммирование. Взгляните на мой экспериментальный проект: Metah.W: язык метапрограммирования рабочих процессов (https://github.com/knat/Metah).

@jakesays Можете ли вы дать некоторые рекомендации о том, как включить поддержку выражений C # в WF, размещенном на собственном сервере.

Пожалуйста, сохраните Xaml. :) Сериализированные объекты JSON тоже были бы интересны. Но я бы предпочел видеть провайдеров, которые как-то настроены во фреймворке для выбора предпочтительного формата.

@dmetzgar (и другие участники MSFT) есть какие-нибудь новости по этому поводу?
Спасибо

Мы работали над этим и добились большого прогресса. В настоящее время XAML недоступен в Core, поэтому мы сосредоточимся на среде выполнения. Мы рассматриваем возможность открытия для других сериализаторов. Поэтому вместо того, чтобы выбирать между JSON или XAML, мы бы предпочли позволить вам использовать собственный сериализатор. Есть еще больше соответствия и юридических вещей, которые нужно утвердить. Поскольку не многие клиенты настаивают на этом порте, он имеет более низкий приоритет.

@dmetzgar мило! Я был бы более чем счастлив внести свой вклад в это, однако я могу, если это станет основным проектом... будь то дизайнер веб-процессов и т. д. Похоже, что xaml вряд ли нужно там для формата определения... рад слышать об этой работе!

Привет, ребята, счастливого Рождества и счастливого Нового года!

Итак, есть ли у нас какое-либо обновление по этому порту или, по крайней мере, версия текущей работы OSS, чтобы мы могли помочь с этим?

Спасибо

@galvesribeiro Я постараюсь объяснить ситуацию как можно лучше. Стремясь перенести WF на .NET Core, я не учел бизнес-сторону всего этого дела. WPF/XAML не перенесен в .NET Core, и это представляет собой значительную часть WF. Хотя XAML не является обязательным для среды выполнения, именно с его помощью большинство клиентов создают рабочие процессы. Это ограничивает аудиторию, которая сочла бы WF на Core полезной. Одно из опасений заключается в том, что мы выпускаем WF на Core, а сообщество не принимает большого участия. Это увеличивает нашу стоимость поддержки и не улучшает ситуацию для большинства клиентов WF. Хотя здорово видеть, как WF работает на машине с Linux, трудно доказать, что кто-то действительно будет его использовать.

Я знаю об OmniXAML, и нам удалось убедить автора перейти на лицензию MIT. Таким образом, с некоторыми вложениями мы потенциально могли бы заставить XAML работать. Но остается вопрос, какую пользу это принесет существующим клиентам WF. Если однажды появится такой крупный клиент, как SharePoint или Dynamics, и скажет, что они переходят на Nano, то у нас будет убедительный аргумент. Однако все это спорно, если команда .NET Framework решит создать пакет, который сможет запускать всю структуру на Nano.

Если бы было достаточно интереса сообщества и кто-то готов поддержать проект, мы могли бы попытаться сделать это таким образом. Что-то вроде Open Live Writer. Сложность заключается в том, что хотя моя команда и будет вносить в это максимально возможный вклад, такой проект не будет поддерживаться Microsoft. Я подозреваю, что большинство клиентов WF используют WF в первую очередь потому, что его поддерживает Microsoft.

Я думаю, важно подчеркнуть, что .NET Core и полная .NET Framework — это два разных продукта. .NET Framework никоим образом не умирает. Мы продолжим поддерживать его, добавлять функции и т. д. Так что нам не нужно портировать WF на .NET Core, чтобы поддерживать его в рабочем состоянии. WF на Core, по сути, будет новым продуктом. Придумать веское деловое обоснование сложно. Это может быть даже вопрос времени. По мере того, как все больше компаний внедряют серверы Nano, это может стать более веским доводом.

@dmetzgar Как насчет Portable.Xaml, может ли это быть альтернативой? https://github.com/cwensley/Portable.Xaml Он был извлечен для использования автором фантастического проекта Eto.Forms для Eto. Он лицензирован MIT и (как и библиотеки классов, из которых он получен в монопроекте).

@dmetzgar ,

Я постараюсь объяснить ситуацию как можно лучше. Стремясь перенести WF на .NET Core, я не учел бизнес-сторону всего этого дела. WPF/XAML не перенесен в .NET Core, и это представляет собой значительную часть WF. Хотя XAML не является обязательным для среды выполнения, именно с его помощью большинство клиентов создают рабочие процессы. Это ограничивает аудиторию, которая сочла бы WF на Core полезной. Одно из опасений заключается в том, что мы выпускаем WF на Core, а сообщество не принимает большого участия. Это увеличивает нашу стоимость поддержки и не улучшает ситуацию для большинства клиентов WF. Хотя здорово видеть, как WF работает на машине с Linux, трудно доказать, что кто-то действительно будет его использовать.

Я думаю, что самая большая мотивация для нынешних пользователей WF — это Nano server и Micro Services, а не Linux. Linux добавит больше пользователей, но это не настоящая мотивация.

Но остается вопрос, какую пользу это принесет существующим клиентам WF.

Мы находимся в облачных дней. Помните: «Сначала облако, сначала мобильные...» и одной из крупных технологий, которые развиваются, являются контейнеры, микросервисы и большое предложение от MS для всего, что касается Nano Server.

Если однажды появится такой крупный клиент, как SharePoint или Dynamics, и скажет, что они переходят на Nano, то у нас будет убедительный аргумент.

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

Однако все это спорно, если команда .NET Framework решит создать пакет, который сможет запускать всю структуру на Nano.

Сегодня DNX (начиная с RC1) состоит не только из coreCLR. Он также имеет полную структуру (dnx451), поэтому в настоящее время мы можем использовать WF на DNX, и это не проблема здесь. Речь идет о coreCLR (dnxcore50)

Если бы было достаточно интереса сообщества и кто-то готов поддержать проект, мы могли бы попытаться сделать это таким образом. Что-то вроде Open Live Writer.

Я бы не стал сравнивать это с тем, что было сделано на Open Live Writer... Думаю, это более-менее то, что было сделано с помощью ASP.Net, MVC, Entity Framework. Основные «продукты» из семейства .Net, которые сегодня имеют открытый исходный код.

Сложность заключается в том, что хотя моя команда и будет вносить в это максимально возможный вклад, такой проект не будет поддерживаться Microsoft. Я подозреваю, что большинство клиентов WF используют WF в первую очередь потому, что его поддерживает Microsoft.

Действительно, клиенты WF используют контракты на поддержку MS... Тем не менее, клиенты Dynamics и Sharepoint делают это, однако существует множество приложений за пределами этого мира, которым все еще требуется поддержка. Сказать, что люди используют его только из-за поддержки, а OSS не поддерживается, почти то же самое, что сказать, что CoreCLR, EF, ASP.Net не будут иметь поддержки от MS. Хотя сейчас эти проекты являются OSS, они тщательно отслеживаются и модерируются командами MS.

Например, я начинал как пользователь проекта MS Orleans. Он обеспечивает работу всех облачных сервисов Halo уже почти 7 лет. Skype, Outlook и многие другие общедоступные/облачные сервисы MS каким-то образом используют его. Несколько лет назад был OSS от MS Research, а теперь поддерживается 343 Studios, некоторыми людьми из MSR и некоторыми другими из других групп внутри MS, но в основном поддерживается сообществом. Сегодня я считаю себя активным участником этого проекта и поддерживаю новых пользователей вместе с другими пользователями MS и не MS. У нас есть даже бывшие (как я) люди, не работающие в MS, в команде GH для Орлеана. Значит ли это, что у нас нет поддержки? Что ж, я не покупал Орлеан, поэтому я по закону прошу поддержки в рамках моих контрактов с MS специально для Орлеана, однако я могу сделать это, ориентируясь на .Net framework или любой другой связанный продукт, поэтому я не совсем согласен с вашим заявлением.

Придумать веское деловое обоснование сложно.
Я согласен с вами, если вы ищете только клиентов Sharepoint и Dynamics.

Что ж, мы, как и многие другие компании по всему миру, поддерживаем крупные корпоративные соглашения (EA) с Microsoft, используя самые разнообразные продукты по этим контрактам. В нашем случае мы обрабатываем миллионы финансовых транзакций (кредитных/дебетовых карт) в день, и каждая из них представляет собой один экземпляр WF, работающий поверх Orleans и внутри Microsoft Azure. Я не знаю, что было бы для вас большим, чтобы выступать в качестве делового оправдания.

Я просто думаю, что ядро ​​(System.Activities) без XAML можно было бы портировать в coreCLR, а дизайнеры можно было бы создавать по запросу для XAML, Json, HTML, XML, чего угодно. Развязывая эту зависимость, открываются другие возможности.

Как я сказал в начале этой ветки, самая тяжелая работа, которую мы хотим сейчас, - это получить ее OSS, и кто-то (по крайней мере, на начальном этапе) из MSFT сможет просмотреть PR. Здравый смысл здесь состоит в том, чтобы переписать WF, а не просто скопировать и вставить его для coreCLR, поэтому мы ожидаем большой вклад в это.

Если этого не произойдет, я думаю, что мы можем закрыть эту проблему, и, по крайней мере, люди начнут искать другие OSS или даже платные механизмы Workflow, которые в конечном итоге получат поддержку CoreCLR. Я просто думаю, что это большая потеря, если его нет в CoreCLR...

Я могу привести очень вескую причину, по которой WF следует портировать на .Net Core.

Microsoft подталкивает разработчиков к платформе UWP. UWP станет платформой Windows будущего. Это не имеет ничего общего с воздушной волшебной идеей переноса приложений на Linux и т. Д. Существует острая необходимость в том, чтобы WF работал на компьютерах с Windows 10, а UWP — это будущее для платформы Windows 10.

Мы создаем периодически подключаемые приложения. У нас есть серверная часть .Net и интерфейс UWP. В настоящее время вся бизнес-логика используется в .Net и UWP. Но мы хотели бы программно запрограммировать бизнес-логику в WF. Это будет нормально работать в .Net, но WF в настоящее время не поддерживается UWP, поэтому WF становится бесполезным, поскольку, если пользователь не подключен к Интернету, он не может совершать вызовы, которые проверяются логикой WF.

В UPW есть XamlReader, поэтому синтаксический анализ XAML на самом деле не имеет большого значения...

@MelbourneDeveloper согласен с вами по всем причинам, однако имейте в виду, что UWP и .Net Core (по крайней мере, сейчас) не находятся под одним и тем же прозвищем, а это означает, что даже они используют одни и те же API более низкого уровня, имеют одинаковую поверхность API (и . Net Core — это OSS, а UWP — нет), они не одно и то же и несовместимы. Другими словами, вы не можете добавить сборку .Net Core к сборке UWP. Эти различия (ИМХО) со временем исчезнут, но пока они все еще существуют...

да. Понял. Это было с рабочим предположением, что эти две вещи будут объединены в будущем. Если их нет, помоги нам Бог!

Кроме того, Xaml @MelbourneDeveloper UWP — это совершенно другая, упрощенная версия Xaml .NET. UserVoice WindowsDev приправлен (то, что продолжает игнорироваться, как и все, что кажется UWP — неудивительно, почему у них вообще есть UserVoice для начала) голосов за улучшение своей системы Xaml:
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

Будем надеяться, что они поступают правильно и поддерживают порт @cwensley Mono Xaml и/или OmniXaml, как было предложено. Система Xaml UWP в ее нынешнем виде — это действительно шутка, и это одна из причин, по которой скорость ее принятия настолько ужасна.

Наряду с этим у меня есть бизнес-вариант использования MSFTies для рассмотрения: NodeJS. Чем дольше мы все вместе ломаем голову над этой проблемой, тем большую ценность получает NodeJS на рынке, поскольку он действительно кроссплатформенный и действительно вездесущий, на что технология MSFT просто не может претендовать на данный момент (или в обозримом будущем). NodeJS работает на сервере и на клиенте (ВСЕ ИХ) и позволяет повторно использовать код между ними. Одна кодовая база будет работать в нативном (через Cordova) и веб-сценарии (через стандартный браузер HTML5), что намного дешевле, чем то, что вам пришлось бы делать с решением на основе MSFT.

Скоро дойдет до того, что переделывать систему на NodeJS и вообще отказываться от MSFT станет приятнее (и, очевидно, дешевле), чем ждать, пока (как кажется) неблагополучные команды догонят экономические реалии рынка.

Я также упомянул об этом, поскольку упоминалось, что кажется, что MSFT рассчитывает на UWP для своей клиентской платформы, но он охватывает лишь часть рынка, которую занимает NodeJS. И когда я говорю дробь, это может быть преувеличением. Мы говорим о 200 миллионах (последнее известное количество установок Windows 10) против ~3 миллиардов (МИЛЛИАРДОВ) устройств, которые могут быть доступны приложениям на основе nodejs.

Не поймите меня неправильно, я люблю MSFT. Я вложил более 15 лет своей жизни в его технологии, и лично я полностью вложился сюда. Тем не менее, с этими инвестициями приходит страсть видеть, как все делают все правильно, и гордиться решениями и усилиями, предпринятыми здесь, в новую эру открытого исходного кода, кроссплатформенной удивительности. Я также хочу, чтобы все знали о надвигающейся рыночной угрозе (а также, возможно, чтобы проверить/подтвердить мои опасения).

Наконец, если все пойдет хорошо, у нас действительно будет еще одна большая проблема с нашим нынешним состоянием кросс-платформенного Xaml, поскольку Portable.Xaml отличается от OmniXaml, поэтому в какой-то момент нам, как сообществу, придется выяснить, как согласовать эти два понятия. кодовые базы... в идеале. :)

@Michael-DST согласен с вами во всем. Одной из целей, для которых мы хотим запускать WF, являются клиенты (особенно мобильные и встроенные). Мы хотим сократить клиентский код для локальных бизнес-правил, добавив в него WF. Под клиентами я не подразумеваю, строго говоря, UWP, такие как устройства Windows (телефоны, планшеты и IoT)...

Я действительно считаю, что есть основные продукты, которые полагаются на WF, такие как BizTalk и Sharepoint, но они по-прежнему могут полагаться на полную версию .Net, в то время как пользователи .Net Core (а позже и UWP) могут полагаться на совершенно новые API-интерфейсы WF/XAML. Я знаю, что это будет означать много #ifs вокруг кодовой базы, но это будет путь...

@galvesribeiro благодарит вас за проверку/поддержку. Иногда мне кажется, что я катюсь в гору, потому что никто, кажется, не признает эту очень реальную (экзистенциальную?) проблему, стоящую перед .NET. На самом деле руководство .NET помогает усугубить эту проблему , рекомендуя сочетать .NET с AngularJS для веб-приложений, фактически подталкивая организации к полному переходу на NodeJS! (полное раскрытие, я написал это. :P).

Я не решаюсь публиковать здесь так много информации о NodeJS, так как WF — это скорее серверная технология, но, как я (и другие организации начинают) это видеть, это затрагивает все сферы и угрожает .NET по всем направлениям. В настоящее время использование NodeJS в качестве стека решений просто более рентабельно (и эффективно с точки зрения охвата рынка), и мы (опять же, ненавижу повторяться, но не совсем) видим, как это отражается на организациях, которые выбирают их технологии.

Итог: я должен поместить свою тревогу _куда-то_, и эта ветка - жертва. :P #простинеизвини

Что касается #if defs... фу, я процитирую здесь манифест MvvMCross : "# для твиттера, а не для кода". :П

НАКОНЕЦ, я забыл пометить @SuperJMN , так как он тоже должен знать об этой ветке/обсуждении (как автор OmniXaml) — никакого неуважения, чувак! Примерно на следующей неделе я лично займусь проблемой OmniXaml и Portable.Xaml.

@Michael-DST, да ... На самом деле #if - это только один из способов ... Команда .Net Core использовала подход «Native Shims», где реальная (специфическая для ОС) реализация абстрагируется от тонкого нижнего слоя собственного кода. В случае WF это может быть прокладка для .Net Full и другая для .Net Core, например...

Я не фанат Node.js и JavaScript (я склонен думать, что это все же скриптовый язык, а не язык программирования, но это мое личное мнение), но я должен согласиться, что в настоящее время ничто не сравнится с ним. с точки зрения xplat. Сама Microsoft использует его для своих агентов сборки на VSTS (просто чтобы назвать 1 случай, есть и другие на MS), поскольку он работает, например, на любой платформе...

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

@galvesribeiro ... я с вами на 100%. Точно так же работает и EF Core 1.0... традиционная серверная технология, которую теперь можно использовать и на стороне клиента. Было бы очень удобно иметь WF таким же образом.

Кроме того, приятно слышать о прокладках. Много одобряю. :)

Наконец, я не хочу (сильно) срывать/захватывать поток, но чтобы быть уверенным в отношении: JavaScript: я согласен как язык сценариев. Тем не менее, это также очень гибкий «язык», который можно использовать в других формах, особенно в байт-коде. Я уверен, вы видели, что для C++ существует магия компилятора LVVM . Растущий/популярный запрос в сообществе разработчиков .NET заключается в том, чтобы сделать то же самое для .NET (официально перевести .NET в JS). Это действительно исправило бы все текущие (основные) пороки текущего климата разработчиков MSFT.

В любом случае, вернемся к вашим обычным запланированным программам. :P Спасибо за диалог и мысли!

Вы, ребята, затрагиваете некоторые вещи, которыми я занимаюсь уже 9 лет. Есть кое-что, чего не понимают многие люди, работающие с технологиями Microsoft; а именно концепция распределенных вычислений. Фундаментальное требование к нашему программному обеспечению с самого начала заключается в том, чтобы оно работало в режиме случайных подключений. Со временем Microsoft предприняла различные попытки предоставить инструменты для этого, но всеобъемлющая структура так и не была разработана. Здесь у нас есть немного инфраструктуры синхронизации, там немного базы данных LINQ, но нет всеобъемлющего набора инструментов, чтобы все работало вместе.

В течение последних 9 лет мы разрабатывали собственный периодически подключаемый фреймворк. Теперь он работает на .Net, Silverlight и UWP. Мы очень старались использовать платформы Microsoft, такие как EF и WF, но поддержка этих технологий не предлагалась на клиентских технологических платформах, таких как Silverlight. Мы буквально создали собственную ORM и платформу синхронизации для Silverlight, которая теперь совместима с UWP.

Прежде всего, когда вокруг WF было много шума, это было довольно интересно, потому что предлагало способ программно кодировать бизнес-логику без кода. Но с течением времени я все меньше и меньше склонялся к мысли, что когда-либо будет порт на клиентскую технологию, такую ​​как Silverlight. Я задавал множество вопросов по этому поводу на форумах, но ответы всегда были одинаковыми: WF — это серверная технология, зачем вам использовать ее в Silverlight?

Как сказал гальвесрибейро

«Я действительно думаю, что WF — это потрясающая технология, текущая версия которой предназначена для пользователей на стороне сервера, однако, с .Net Core, и отлично может работать и на клиентах ...»

И

«Одной из целей, на которых мы хотим запускать WF, являются клиенты (особенно мобильные и встроенные). Мы хотим сократить клиентский код для локальных бизнес-правил, добавив в него WF. Под клиентами я строго не говорю о UWP, таких как устройства Windows. (телефон, планшеты и Интернет вещей)"

Что люди должны понимать, так это то, что когда речь идет о распределенных вычислениях, нет различия между клиентскими и серверными технологиями. Подумайте о том, как работает Git. Код для Git одинаков независимо от того, смотрите ли вы на центральный репозиторий или на какой-то узел в сети. Код дублируется везде. То же самое и с нашим фреймворком. Бизнес-логика дублируется на все узлы. Это потому, что даже если пользователь не подключен к сети, он все равно должен подчиняться той же бизнес-логике. В распределенных вычислениях каждый компьютер буквально ЯВЛЯЕТСЯ сервером. Он буквально запускает тот же код, что и сервер.

Мы никогда не могли использовать WF, потому что мы не могли запускать код WF в Silverlight, а теперь мы не можем запустить его в UWP. Отрадно видеть, что EF переносится на UWP. Возможно, это начало того, как Microsoft приходит к пониманию необходимости распределенных вычислений. Но Microsoft необходимо присоединиться к распределенным вычислениям и включить WF как часть всей распределенной вычислительной среды. Может быть, тогда мы сможем удалить нашу распределенную вычислительную среду, и мне больше не придется поддерживать этот код.

Действительно отличная перспектива и мысли @MelbourneDeveloper. Спасибо, что поделились ими. Я также был большим фанатом Silverlight и с тех пор не перестаю на него смотреть (отсюда мой итоговый голос и, действительно, сайт выше). Кроме того, мне любопытно, что вы думаете о мобильных службах Azure и рассматривали ли вы возможность их использования в своей автономной истории? Я новичок в распределенных вычислениях (но вникайте в то, что вы хотите сказать), но я действительно хочу заняться этим в следующем году (я также слышу много микросервисов, которые, как я полагаю, являются последним эквивалентом этого?) .

Что люди должны понимать, так это то, что когда речь идет о распределенных вычислениях, нет различия между клиентскими и серверными технологиями.

Действительно хороший момент. На данный момент все зависит от того, где размещена технология. То есть вы действительно ограничены набором технологий, которые вы пытаетесь «распространить», я бы сказал (и снова я не эксперт в этом). Чем более вездесущ (или легко доступен) хост, тем лучше распределено/доступно приложение. Эннннд... Я думаю, вы знаете, к чему я клоню. :П

В любом случае, на самом деле кажется, что мы все пришли к соглашению по поводу _кое-чего_ в этом обсуждении, и это долгожданное изменение/достижение для меня. ;)

@галвесрибейро

имейте в виду, что UWP и .Net Core (по крайней мере, сейчас) не находятся под одним и тем же прозвищем, что означает, что даже они используют одни и те же API более низкого уровня, имеют одинаковую поверхность API (и .Net Core — это OSS, а UWP — нет) , это не одно и то же и несовместимо. Другими словами, вы не можете добавить сборку .Net Core к сборке UWP. Эти различия (ИМХО) со временем исчезнут, но пока они все еще существуют...

Взгляните на этот PR dotnet/corefx#5760, надеюсь, он прояснит некоторые вещи.

Сторона .NET UWP _is_ .NET Core. Однако .NET Core предоставляет несколько сред выполнения. UWP использует среду выполнения на основе AOT, поэтому некоторые функции, требующие JIT, не поддерживаются (например, LCG или RefEmit). Однако они используют одни и те же сборки и (в будущем) одни и те же пакеты NuGet. Мы специально разработали стек, чтобы разрешить перекрестные ссылки на сборки (и пакеты) из UWP и ASP.NET Core.

Конечно, помимо этого есть инструменты VS, называемые переносимыми библиотеками классов (PCL), которые пытаются помочь вам в создании библиотек, которые будут работать на множестве платформ. В диалоговом окне таргетинга PCL вы можете выбрать несколько вариантов, и все они приведут к тому, что ваш двоичный файл будет совместим с .NET Core. Однако, поскольку переносимость в VS определяется платформой, вы не сможете ссылаться на PCL из приложения UWP, если в этом PCL не указано, что он может ориентироваться на UWP. Такое поведение является преднамеренным, поскольку идея состоит в том, что инструменты PCL помогают вам не использовать случайно функциональные возможности, которые не поддерживаются везде, где вам нужно работать. И наоборот, вы можете ссылаться на PCL только с тех платформ, на которые он указывает.

Поскольку вы явно упоминаете прозвища, давайте поговорим и об этом на секунду. Дизайн прозвища (TFM) заключается в том, что он представляет всю площадь поверхности. В нашем инструменте есть два моникера:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Думайте о TFM как об идентификации всей управляемой внутренней поверхности, в то время как TPM представляет базовую ОС, т. е. набор API, предоставленный ОС.

Поскольку мы разработали .NET Core с возможностью переноса на несколько платформ, традиционный TFM не имеет большого смысла. Именно поэтому существует новая концепция под названием Стандартная платформа , ранее называвшаяся поколениями.

Это помогает?

Однако они используют одни и те же сборки и (в будущем) одни и те же пакеты NuGet.

Большинство сборок имеют одну и ту же библиотеку BINARY реализации как для целевого объекта NuGet netcore50 (приложение WIndows UWP Store), так и для целевого объекта NuGet dnxcore50 (ASP.NET v5 / ASP.NET Core 1.0).

Однако некоторые пакеты NuGet, такие как многие пакеты библиотеки System.Net.*, имеют разные реализации для цели «netcore50» и цели «dnxcore50». Например, библиотека System.Net.Http с 'netcore50' использует реализацию WinRT Windows.Web.Http внизу. Реализация dnxcore50 использует что-то другое (собственный WinHTTP).

Однако некоторые пакеты NuGet, такие как многие пакеты библиотек System.Net.*, имеют разные реализации для цели «netcore50» и цели «dnxcore50».

Да, я должен был упомянуть об этом. Я вижу это так: пакет NuGet предоставляет контейнер, который позволяет производителю предоставлять разные реализации для разных сред выполнения, в то время как потребителям не нужно об этом знать. В этом смысле пакеты NuGet — это новые сборки.

Спасибо @terrajobst и @davidsh за то, что поделились этим более глубоким объяснением и справочной проблемой, но что не так с тем, что я сказал, что «на одну сборку с одной платформы не может ссылаться другая»?

Я вижу это так: пакет NuGet предоставляет контейнер, который позволяет производителю предоставлять разные реализации для разных сред выполнения, в то время как потребителям не нужно об этом знать. В этом смысле пакеты NuGet — это новые сборки.

Эта концепция на самом деле не нова... Люди уже создают один пакет Nuget, который является не чем иным, как ссылкой на кучу других пакетов - так называемых "метапакетов". Есть несколько способов заставить PCL работать на многих платформах. Наиболее известными, используемыми многими популярными библиотеками (например, Json.Net от Newtonsoft), являются Bait и Switch , где у вас есть nuget с общедоступным интерфейсом (поверхность API) и одна сборка для каждой конкретной платформы (реальная реализация поверхности API). которые могут даже иметь разные зависимости друг от друга, и во время выполнения будет выбрана правильная сборка для этой платформы. Разница теперь заключается в том, что вместо того, чтобы иметь несколько nuget «внутри» одного контейнера nuget, где все должны быть на одной платформе или 1 интерфейсной сборке, которая просто используется при разработке и которая переключается на конкретную во время выполнения, у нас есть смесь этого! 1 nuget, который является контейнером и в то же время общедоступным интерфейсом для всех связанных с ним nugets, специфичных для платформы.

Я думаю, что мы говорим об одном и том же, просто я сначала плохо выразился :smile:

Во всяком случае, вернемся к WF... Я думаю, общеизвестно, что люди хотят, чтобы его портировали на WF, а не просто «потому что круто» запускать его на Linux или на Nano Server. Люди хотят легко использовать его и на клиентах.

Опять же, я думаю, что в сообществе достаточно людей, желающих сделать этот порт...

PS: Для тех, кто интересуется распределенными вычислениями (настоящими, а не историей офлайн-клиента), пожалуйста, взгляните на наш другой проект Orleans , который на самом деле является хорошим вариантом использования WF на .Net Core и который сегодня расширяет возможности крупных сервисов Microsoft. как Skype, Halo5, и который я лично использую в качестве основной технологии моей платформы обработки финансовых транзакций, которая обрабатывает миллиарды транзакций распределенным способом...

@галвесрибейро

что не так с тем, что я сказал, что «на одну сборку с одной платформы нельзя ссылаться с другой»?

Дело не в том, что ваше утверждение неверно; просто это тоже неправильно :smile: Обычно я не из тех людей, которые любят придираться, но что меня сбило с толку, так это вот эта часть:

Другими словами, вы не можете добавить сборку .Net Core к сборке UWP.

Я хочу избежать впечатления, что UWP и .NET Core — это разные платформы .NET, такие как .NET Framework и Silverlight. Мы специально разработали .NET Core, чтобы вы могли создавать сборки, работающие на всех платформах. Например, System.Collections.Immutable и почти все Roslyn являются сборками .NET Core, они также будут нормально работать в UWP.

Итак, перефразируя: наша цель — создать платформу, на которой простые компоненты на основе MSIL могут буквально использовать один и тот же двоичный файл на всех платформах на основе .NET Core. В тех случаях, когда это невозможно, например, из-за нативных зависимостей или различных реализаций, мы делаем именно то, что Пол Беттс так красноречиво назвал PCL-приманками и переключателями : переносимая поверхность, различные реализации для каждой платформы и NuGet в качестве контейнера и селектор.

В мире .NET Core библиотеки System не являются чем-то особенным. Любой может использовать ту же технику, чтобы гарантировать, что большинству потребителей не придется засорять свою кодовую базу директивами #if .

Я думаю, что мы говорим об одном и том же, просто я сначала плохо выразился :smile:

Я думаю, что мы создали мир, в котором слишком легко запутать людей, в том числе и нас самих :smile: Вот почему я так стараюсь быть точным в том, как создавался .NET Core и какие проблемы мы пытались решить.

Да, ты прав. Впечатление — вот что важно.

Я надеюсь, что когда-нибудь мы вызовем .Net Core и на UWP, так что с этим покончено... Итак, нам по-прежнему нужен system.xaml

Несмотря на то, что это связано, я думаю, что System.Xaml — это отдельный компонент, который сам по себе добавляет ценность. Я зарегистрировал dotnet/corefx#5766, чтобы отслеживать это отдельно.

Спасибо, Майкл-DST.

Кроме того, мне любопытно, что вы думаете о мобильных службах Azure (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/). и рассматривали ли вы возможность использовать это в своей офлайн-истории?

Отличный вопрос. Это подводит нас к небольшому уроку истории об опыте нашей компании в области распределенных вычислений, также называемых периодически подключаемыми приложениями, и о том, как это связано с мобильными службами Azure и распределенными вычислениями с технологией Microsoft.

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

Около 8 лет назад мы создали приложение для оригинальной платформы Windows Phone. Старая школа с .Net Compact Framework. Люди могут насмехаться над этим, но по некоторым ключевым моментам эта платформа была более продвинутой, чем текущая платформа UWP, в отношении технологий, которые время от времени подключаются. Хотя, похоже, UWP наверстывает упущенное. Ключами к успеху иногда подключаемых приложений на этой платформе были:

1) Полная реализация базы данных SQL (SQL Server CE)
2) Реализация Sync Framework между SQL Server (серверная часть) и SQL Server CE (мобильное устройство). Это была Sync Framework версии 1.

Это приложение было успешным. Мы написали уровень данных, который располагался поверх SQL CE, и SQL Server, который был развернут на сервере и развернут на устройствах. Это почти максимизировало память, но это сработало. Полевые работники могли собирать данные в полевых условиях, и данные были синхронизированы с центральной базой данных.

Мы были в ужасе, когда вышла Windows Phone 7, потому что была критическая проблема: все базы данных на рынке были базами данных, отличными от SQL. В основном они были реализованы с помощью LINQ. Это было несовместимо с нашим уровнем данных, а EF не существовало для Windows Phone 7. Таким образом, мы не смогли создать время от времени автономную среду для Windows Phone 7, хотя мы смогли создать полное решение для исходного Платформа Windows Phone.

Silverlight изменил правила игры. Опять же, мы наткнулись на полную базу данных SQL. Но Microsoft не внедрила структуру синхронизации для Silverlight или рассматриваемой встроенной базы данных. Итак, мы приступили к написанию собственной структуры синхронизации, созданной по образцу структуры синхронизации Microsoft. Платформа синхронизации Microsoft основана на метках времени. Это то, что мы реализовали в нашей структуре синхронизации. И снова мы добились полного успеха с Silverlight. Выездные работники могли брать с собой планшеты Windows в поле, собирать данные, а затем синхронизировать их с центральной базой данных. Проблема заключалась в том, что это никогда не было доступно для телефонов. Платформы базы данных для Windows Phone 7 не существовало.

Как я уже упоминал ранее, мы хотели реализовать бизнес-логику с помощью WF, но от Silverlight отказались, и никто даже не говорил о возможности переноса WF на Silverlight.

Наконец, мы приходим в UWP. Оболочка для SQLite была написана для UWP, и с помощью нескольких взломов оболочки я смог расширить интерфейс с помощью SQLite, чтобы мы могли снова работать с полной базой данных SQL. Это означает, что наш уровень данных совместим с ним. Наш уровень данных и уровни синхронизации теперь работают с .Net, Silverlight и UWP, с SQL Server, SQLite и другой безымянной платформой баз данных.

Сегодня я впервые увидел синхронизацию с чистой технологией Microsoft благодаря Michael-DST. По сути, я могу сказать, что синхронизация Azure Mobile Services — это просто ребрендинг Microsoft Sync Framework. У него немного другой интерфейс API, но основы такие же, как и у оригинальной платформы синхронизации Windows Phone, которую мы использовали для работы синхронизации около 8 лет назад. Я вижу, что он даже использует те же два поля временных меток для отслеживания изменений данных. Они были введены в SQL Server в качестве основной функции SQL Server 2008. Наша структура синхронизации работает более или менее так же, как среда синхронизации Microsoft.

Итак, чтобы ответить на вопрос Майкла, я буду исследовать эту технологию. Я посмотрю, сможет ли он заменить нашу структуру синхронизации. Я бы с удовольствием выкинул его, и пусть кто-то другой обслуживает его. Увидев, что они упомянули, что он будет поддерживать SQLite, это звучит многообещающе, потому что похоже, что мы сможем взломать оболочку SQLite, чтобы продолжить использовать полную базу данных SQL и, следовательно, сможем продолжать использовать наш уровень данных. Если это так, это будет означать, что 5+ лет кода фреймворка синхронизации отправятся прямо в мусорное ведро.

В любом случае, дело в том, что Microsoft выглядит так, как будто они еще раз признают важность распределенных вычислений. Если это важно, нужно портировать WF на UWP. UWP — это будущее, а значит, это и будущее распределенных вычислений с технологией Microsoft. Будущее распределенных технологий нуждается в WF.

Несмотря на связанность, я думаю, что System.Xaml — это отдельный компонент, который сам по себе добавляет ценность. Я зарегистрировал dotnet/corefx#5766, чтобы отслеживать это отдельно.

Большое спасибо @terrajobst! Я не согласен со всем, что вы публикуете в Интернете/твиттере, но я большой поклонник того, как вы способствуете диалогу и общению между разработчиками/сообществом, и я всегда с этим согласен. :) Это действительно много значит для меня лично, так как кажется, что больше года катания в гору, чтобы получить что-то от MSFT (и да, я понимаю, что это не обязательство, но на данный момент все имеет смысл).

Итак, чтобы ответить на вопрос Майкла, я буду исследовать эту технологию.

Отлично @MelbourneDeveloper , рад помочь! Я чувствую, что Azure действительно хорошо справляется с их группой. Наряду с VSO/VSTS они действительно прислушиваются к своим разработчикам и получают *_lot *_done. На самом деле, похоже, это относится ко всем группам в MSFT, за исключением группы UWP, которая на самом деле, кажется, мало что делает и даже не понимает свою собственную технологию (и давайте даже не будем вдаваться в их определение "Ксамл").

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

Как сказал @MelbourneDeveloper

В любом случае, дело в том, что Microsoft выглядит так, как будто они еще раз признают важность распределенных вычислений. Если это важно, нужно портировать WF на UWP. UWP — это будущее, а значит, это и будущее распределенных вычислений с технологией Microsoft. Будущее распределенных технологий нуждается в WF.

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

Я думаю, что в этой теме мало места для разногласий.

Безусловно, можно утверждать, что декларативное визуальное программирование, такое как WF, не так эффективно, как написание кода. Я даже склонен согласиться. Но иметь WF в качестве инструмента в наборе инструментов для завершения настраиваемой платформы, безусловно, было бы хорошо. Клиенты *_DO *_ хотят видеть визуальные рабочие процессы, и предоставление клиентам возможности изменять свои собственные рабочие процессы, безусловно, является хорошей идеей.

Время сделать это!

Я думаю, что в этой теме мало места для разногласий.

Ха-ха @MelbourneDeveloper , вы когда-нибудь встречали разработчика программного обеспечения? Или действительно, человеческий род? ;п

Я лично считаю, что визуальный дизайнер WF и существующие инструменты оказали XAML медвежью услугу, поскольку слишком многословные файлы, созданные для рабочих процессов MSBuild, действительно создали Xaml дурную славу в этом отношении. Это действительно то, что разработчики связывают с Xaml («раздутые файлы»), и это способствовало переходу к «более простым» файлам JSON и файлам сборки со сценариями. Не говоря уже о том, что весь загадочный, сложный и громоздкий процесс (я до сих пор даже не могу заставить его полностью работать в своих проектах) даже создания проекта для просмотра файла Xaml для начала.

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

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

Я большой поклонник того пути, к которому стремился WF, но его нужно немного подтянуть, а его инструменты исправить и улучшить. На самом деле, в конце концов, технология хороша настолько, насколько хороши вспомогательные инструменты — дизайнеры и все такое. Чем лучше инструменты/дизайнеры, чем доступнее/понятнее технология, тем лучше ее внедрение.

Я определенно хотел бы, чтобы WF стал больше похож на EF и был доступен в любом сценарии .NET, а инструментарий был улучшен именно для этого.

Насколько я понимаю, одним из первоначальных замыслов WF была поддержка нескольких типов файлов для рабочих процессов, а не только XAML. В целом, за исключением некоторых причуд здесь и там, у меня действительно не было проблем с XAML. Просто мне потребовалось некоторое время, чтобы окунуться в него и привыкнуть редактировать его вручную, когда это необходимо, что, я уверен, представляет собой барьер для входа для многих людей. Поэтому, хотя я считаю, что XAML необходимо поддерживать для обратной совместимости (по крайней мере, в краткосрочной перспективе), мне бы очень хотелось, чтобы другие типы файлов рабочих процессов начали развиваться (например, JSON). Я мог видеть некоторые интересные вклады сообщества на этом фронте! (Рабочие процессы написаны в пробелах ? :smile: )

@ Michael-DST Я полностью с тобой согласен. Недавно мы с моей командой анализировали, что нравится/не нравится/пожелания для Workflow, и почти все, что мы хотели улучшить, касалось дизайнера, а не самого ядра WF. Я думаю, что Microsoft проделала фантастическую работу над тем, что они создали в WF, и я думаю, что несколько улучшений и немного евангелизации мы могли бы вдохнуть в него новую жизнь. Я думаю, что это инструмент, который ДОЛЖЕН существовать, и я получил массу пользы от WF, и я хочу, чтобы он продолжался ДОЛГО-ДОЛГО.

Наше предприятие сделало значительные инвестиции в WF и теперь является ключевой технологией для нашего бизнеса. Учитывая недавнюю приверженность MIcrosoft открытому исходному коду и .NET Core, портирование WF кажется лучшим следующим шагом для этой технологии. Нам это нужно!

Рабочий процесс был инструментом со многими преимуществами для нас как разработчиков в нашей организации. Если Microsoft собирается унифицировать свои фреймворки, нам будет проще иметь WF в базовом фреймворке.

Ха-ха @MelbourneDeveloper , вы когда-нибудь встречали разработчика программного обеспечения? Или действительно, человеческий род? ;п

Ха-ха, я разработчик программного обеспечения. Человеческая раса для меня не имеет значения.

Майкл-DST

Я лично считаю, что визуальный дизайнер WF и существующие инструменты оказали XAML медвежью услугу, поскольку слишком многословные файлы, созданные для рабочих процессов MSBuild, действительно создали Xaml дурную славу в этом отношении. Это действительно то, что разработчики связывают с Xaml («раздутые файлы»), и это способствовало переходу к «более простым» файлам JSON и «скриптовым» файлам сборки.

Вы, вероятно, правы. Но я лично считаю, что здесь слишком много внимания уделяется Xaml. Когда я попробовал WF (до того, как понял, что мы не можем его использовать, потому что его нет в Silverlight), я создал приложение WPF. Это приложение подключилось к нашим службам WCF и сохранило Xaml для WF в таблице в нашей базе данных. Вот как мы достигли мягкого кодирования WF.

Но Xaml полностью управлялся с помощью инструмента конструктора WPF WF. Пользователь никогда не видел Xaml. Xaml не имел отношения к пользователю. Думайте об этом как о разметке HTML позади веб-страницы. Это может быть чрезвычайно запутанным, но пока конечному пользователю нравится веб-страница, это не имеет большого значения. Я думаю, что если вы манипулируете Xaml напрямую как текстом, вы все равно не используете WF по назначению...

Человеческая раса для меня не имеет значения.

Хороший. Б)

Но Xaml полностью управлялся с помощью инструмента конструктора WPF WF. Пользователь никогда не видел Xaml.

Правильный. Именно так работает MSBuild, и конечные пользователи ненавидят его из-за того, насколько велики создаваемые им файлы (особенно если сравнивать их с простыми файлами «скриптов», которые очень просты и линейны). Я согласен с вами, что это проблема инструментария/дизайнера, и я бы также сказал, что инструментарий/дизайнер можно значительно улучшить с помощью WF.

Дело в том, что сообщения в блогах и копирование/вставка кода (или, на самом деле, копирование/вставка _workflow_ :smile:). Несколько раз я искал в Интернете WF и наткнулся на хороший пост в блоге, в котором были показаны некоторые шаги, которые необходимо выполнить, чтобы добавить компонент рабочего процесса (скорее всего, для MSBuild). Ну, для того, чтобы сделать это, мне пришлось в основном дублировать кучу шагов. Обычно в блоге кодирования код доступен для простого копирования/вставки. С ВФ не так. Вы должны делать это шаг за шагом, пока он не будет выглядеть на вашем компьютере точно так же, как он выглядит в сообщении в блоге. Это, очевидно, очень утомительно и подвержено ошибкам (и полностью похоже на шаг назад с точки зрения C#).

Другая проблема, с которой мы столкнулись в MSBuild, — это размер файла не только в байтах, но и в самом конструкторе: было очень сложно ориентироваться в сложном рабочем процессе. Это похоже на то, что следует учитывать очень всесторонним (и интуитивным) образом.

Наконец, я хочу подвести итоги по поводу размера файла. Я не уверен, знакомы ли вы с WordML и/или MSFT Frontpage в прошлом. Но это создало бы самый раздутый HTML в мире. Хотя пользователи обычно не касаются полученной разметки, им нравится совать в нее свой нос, чтобы почувствовать, насколько она «чиста». Во-первых, они смотрят на размер на диске, во-вторых, чтобы открыть файл, чтобы увидеть, как он отформатирован и т. д.

Опять же, я согласен с тем, что то, как создаются эти файлы, является исключительно проблемой инструментария/дизайнера, но разработчикам становится любопытно, и это также следует учитывать. :)

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

Кто на самом деле имеет право принимать решение о переносе WF на .Net Core или UWP? Это просто случай, когда какой-то разработчик где-то пишет код, а затем отправляет этот патч администраторам репозитория кодовой базы .Net Core? Какая политика вокруг этого? Разве не существует основная команда разработчиков, на которую оказывает влияние Microsoft? Являются сотрудниками Microsoft? Я до сих пор не понимаю всей установки. Кого мы должны убедить?

На самом деле, @MelbourneDeveloper , просто участвуя в этой теме, вы помогаете аргументировать. В MS есть команда, которой принадлежит WF, в настоящее время моя, но мы не принимаем решения о выпуске WF на Core. Мы должны сделать бизнес-кейс. Обсуждение здесь помогает мне сделать это.

На самом деле впечатляет то, как люди начали 2016 год, поддерживая эту тему :)

Кроме того, https://github.com/dotnet/corefx/issues/5766 от @terrajobst в эти дни стал намного более загружен :)

@dmetzgar Я надеюсь, что вы получите столько отзывов, сколько сможете/нужно, из этих обсуждений, чтобы у вас было достаточно случаев для OSS.

Я почти уверен, что если открыть репозиторий dotnet/WF, если он будет добавлен в corefx, люди определенно быстро его разовьют.

На самом деле, @MelbourneDeveloper , просто участвуя в этой теме, вы помогаете аргументировать

Это заставляет меня чувствовать себя тепло и пушисто.

Просто к вашему сведению, dmetzgar - я более чем счастлив задокументировать наш опыт и выдвинуть убедительные доводы, чтобы помочь собрать доказательства для портового бизнес-кейса.

Я был по колено в технологиях Microsoft с 2000 года. Я наблюдал, как все основные технологии, относящиеся к этой теме, развиваются и исчезают. Хотя я погружен в технологии Microsoft, я по-прежнему смотрю на них с объективной точки зрения и считаю, что WF — это одна из ключевых технологий, которые могут помочь бизнесу и правительству приобрести платформы .Net Core и Windows UWP.

Ничто так не возбуждает клиента, как блок-схемы! Ничего такого!

Я также должен сказать, что технология Microsoft находится на пороге чего-то большого.

В течение стольких лет я наблюдал взлеты и падения хороших технологий. Основная причина, по которой технологии отошли на второй план, заключается в изменении ландшафта устройств. В прошлом стратегия заключалась в создании платформы для каждого семейства устройств. В этом подходе не было ничего изначально неправильного. Но это означает перенос технологий между платформами. Это обременительно, и нередко технологии отходят на второй план, потому что платформа внезапно становится неприятной (кашель — Silverlight).

Теперь Microsoft отстает от .Net Core и UWP. Хотя я считаю, что эти две платформы должны быть одной и той же, я все же очень оптимистичен в отношении того, что когда данная технология будет создана или будет поддерживаться, она будет работать на многих платформах. Xamarin еще больше усиливает мой оптимизм.

Действительно кажется, что впервые в истории мы смотрим в упор на набор технологий, которые работают с очень широким спектром процессоров и операционных сред. Если Microsoft будет сильно настаивать на этом, WF станет частью этого.

Это заставляет меня чувствовать себя тепло и пушисто.

:+1: об этом @MelbourneDeveloper и @dmetzgar. Это своего рода взаимодействие и диалог, который я лично хотел бы видеть от MSFT, а не игнорируемые просьбы и безответные призывы от его страстной базы ( это просто подло, это подло, чувак ).

Случайное отступление: с моей точки зрения, NodeJS является единственным бизнес-кейсом/угрозой, которая вам нужна, случайная статья, на которую я недавно наткнулся .

Наконец, по моему мнению, «если .NET Core достаточно хорош для EF, он должен быть достаточно хорош и для WF»... если WF перешел на .NET Core, есть ли способ интегрировать его с EF, чтобы EF как его бэкенд как-то? Это убедительный случай, если так. Если нет, то все же стоит подумать (см.: обсуждение/диалог/мозговой штурм/и т. д.). :)

Наконец, по моему мнению, «если .NET Core достаточно хорош для EF, он должен быть достаточно хорош и для WF»... если WF перешел на .NET Core, есть ли способ интегрировать его с EF, чтобы EF как его бэкенд как-то? Это убедительный случай, если так. Если нет, то все же стоит подумать (см.: обсуждение/диалог/мозговой штурм/и т. д.). :)

Это интересная мысль. Каков ваш вариант использования для интеграции EF и WF? Можете ли вы привести пример? Это для настойчивости?

Можете ли вы привести пример? Это для настойчивости?

По крайней мере, его можно было бы использовать в качестве модели поддержки, с которой работает рабочий процесс в домене приложения. В лучшем случае он может служить механизмом хранения для самого рабочего процесса (но я бы не рекомендовал этого — Xaml гораздо лучше подходит для этого).

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

Конечно, мой опыт работы с WF здесь ограничен (те, у кого большой опыт, могут присоединиться сюда). Но если это сработало для WPF, то может сработать и для WF. На самом деле, я использую ту же самую парадигму (то есть разработку на основе Xaml в стиле WPF) для консольного приложения, которое я использую для своего текущего проекта . Конечно, он не использует привязки данных, как я предлагаю (пока), но их легко создать, как показал нам OmniXaml/Perspex. :темные очки:

@ Michael-DST Я бы предпочел избегать слишком большого количества интеграций. WF должен быть отдельным пакетом NuGet. Интеграция WF и EF вместе должна быть отдельным проектом. Начните комбинировать слишком много вещей, и вы можете получить Осло .

Я согласен с @dmetzgar :+1:

EF — это поставщик хранилища/постоянства. Это должен быть пакет diff NuGet, внедренный во время выполнения. WF должен только предоставлять набор интерфейсов и все.

Мы неплохо справились с поставщиками хранилищ в Microsoft Orleans.

@dmetzgar (и @galvesribeiro) согласились. Я предлагаю не обязательную интеграцию, а возможный вариант использования / ценностное предложение. (См.: мозговой штурм. :smile:)

Каков ваш вариант использования для интеграции EF и WF? Можете ли вы привести пример? Это для настойчивости?

Я хочу поучаствовать в этом! Опять же, это относится к опыту моей компании. В конечном счете, мы хотели бы использовать EF для сохранения данных во встроенных базах данных, таких как SQLite, для периодически подключаемых приложений. В конечном счете, в UWP/.Net Core EF, SQLite, Azure Mobile Services и WF будут работать в гармонии. Я бы повторился, если бы объяснил, почему мы хотим, чтобы это произошло, но я могу объяснить, почему EF и WF будут хорошо работать вместе. Хотя мы обнаружили одно ограничение в EF, которое останавливало нас в прошлом — и это другая причина, по которой нам пришлось создать собственный ORM.

У нас есть система, в которой доступ к данным запускает такие события, как «BeforeLoad», «BeforeSave» и т. д. Мы оставляем ловушки в этих событиях, чтобы при сохранении записи определенного типа мы могли поместить туда пользовательскую бизнес-логику. В настоящее время мы сделали это, подключив пользовательские библиотеки DLL бизнес-логики. У каждого клиента есть свой набор пользовательских событий. Мы также реализовали вызовы WF. Так, например, в событии BeforeSave мы могли бы добавить некоторую проверку, выполнив вызов WF, который проверяет обязательные поля. Таким образом, логика проверки была программно закодирована для данного клиента. В конечном счете нам пришлось отказаться от WF для этой цели, потому что он никогда не был реализован в Silverlight, но было бы неплохо иметь его там в качестве опции.

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

Увы, я так и не нашел способа сделать это с EF даже на .Net. Проблема, которую я обнаружил, заключалась в том, что EF не сообщает вам, когда запись данного типа будет сохранена. Так, например, если вы создаете новый объект «Задача» и сохраняете его в базе данных с помощью EF, EF не запускает событие, которое имеет что-то вроде «RecordInserted«. Это позволило бы нам встроить крючки в доступ к данным, чтобы можно было вставить пользовательский бизнес. Итак, это одна из причин, по которой мы никогда не использовали EF. Жаль, потому что создание нашего собственного ORM заняло годы, чтобы улучшить.

Говоря о «экономическом обосновании» NodeJS: как NodeJS доминирует над .NET в 3 простых диаграммах

Терпеливо жду этого репозитория GitHub. Только что понял, что WF не был портирован на .NET Core, что в значительной степени убило его жизнеспособность для нашего продукта. Это позор, поскольку нам нравятся изменения, происходящие в ядре ASP.NET, и вся кросс-платформенная, упрощенная модульная идея .NET Core, но нам нужен WF, поскольку он является основой всего нашего продукта.

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

+1

Мы использовали динамическую генерацию (на основе импортированных внешних правил) и загрузку рабочих процессов в качестве сервисов WCF. Было бы супер, если бы мы могли использовать такую ​​модель в ядре .net!
Кстати - в чем проблема импорта сборок полного .Net? если это в основном IL-код, почему он не работает в ядре .net?

+1

@dmetzgar Невероятно интересно видеть https://github.com/dmetzgar/corewf! Из файла readme я был удивлен, увидев, что порт, сделанный командой WF, не получил большого распространения. Особенно с учетом недавнего порта Powershell с Powershell Workflow, который будет ограничен полной структурой — Linux и Mac, очевидно, не являются основной целью, но сервер Nano, как мне кажется, чрезвычайно важен для Powershell. Там также упоминается, что вы изучаете альтернативы XAML, которые включают другие реализации XAML, такие как Portable.Xaml, например, уже поддерживает профиль 259, совместимый с CoreCLR?

@watertree Portable.Xaml и другие реализации XAML с поддержкой .NET Core, которые я видел до сих пор, имеют отсутствующую функцию. Они не реализуют атрибут x:Class="". Это не нужно для WPF, но критично для WF. Рабочий процесс XAML обычно имеет

PowerShell Workflow имеет действительно хороший способ определения рабочих процессов в скрипте. Это намного чище, чем писать то же самое на XAML или C#. Однако PSWF незаметно преобразует этот сценарий в файл XAML. Чтобы PSWF мог работать с Nano, им придется заменить существующий конвейер и среду выполнения WF, чтобы они не использовали XAML. И на самом деле со стороны клиентов недостаточно давления, чтобы иметь PSWF на Nano.

Что касается альтернатив XAML, у меня много мнений по этому поводу. Моя проблема с XAML заключается в том, что он встроен в WF. Со старым WF, выпущенным в .NET 3.5, команда WF больше поощряла преобразование любого формата в рабочий процесс. Они использовали пример преобразования диаграмм Visio в рабочие процессы. Но когда появился новый WF в версии 4.0, все было сосредоточено на XAML. Вы когда-нибудь пытались написать рабочий процесс на XAML вручную? Не происходит. Затем идут символы отладки и состояние просмотра. И попробуйте сравнить одну версию XAML с другой с помощью средства сравнения.

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

Они не реализуют атрибут x:Class=""

Действительно, скомпилированный Xaml (baml?) заметно отсутствовал во всех вариантах Xaml, которые я видел. Я думал о том, чтобы погрузиться в это в свободное время, но у меня есть ощущение, что это будет доступно в какой-то мере в ближайшее время, возможно, в следующем году. Кроме того, система Xamarin Xaml поддерживает это, но она закрыта и вообще не расширяема/доступна.

Вы когда-нибудь пытались написать рабочий процесс на XAML вручную? Не происходит.

Истинный. По иронии судьбы, WF является наиболее всеобъемлющим спонсором (на сегодняшний день) любой интеграции Xaml. По вине, наверное. Жаль, что Xaml был создан, чтобы быть чрезвычайно удобным для дизайнеров, но инструментарий для WF немного не подходит для рукописных сценариев и даже для самого дизайнера. Кажется, они действительно стремились сделать его визуальным языком программирования, но без значительного объема поддержки/ресурсов ему потребовалось бы добиться успеха.

Я действительно думаю, что использование XAML для определения рабочих процессов должно быть связано с включением пакета NuGet.

Мне нравится, как ты думаешь! 👍

Кстати, если вы еще этого не сделали, перейдите к запросу/проблеме порта System.Xaml и, если можете, проголосуйте за проблему. Я, например, очень хотел бы увидеть новую кросс-платформенную систему Xaml с открытым исходным кодом, которая берет лучшее из всех известных систем и предоставляет ее как один официальный и авторитетный вариант. Разве это не было бы мило? 😛

В любом случае, сейчас до 74 голосов. Что довольно приятно, учитывая, что голосование началось до того, как стали доступны реакции GitHub:
https://github.com/dotnet/corefx/issues/5766

17 сердец тоже круто. :)

Спасибо за любую поддержку (и постоянную обратную связь)!

@dmetzgar Спасибо за ваши усилия! Просто прокомментируйте XAML - раньше я очень негативно относился к XAML, потому что большинство файлов, с которыми я имел дело, были созданы с использованием диалектов XAML, ориентированных на визуального дизайнера.

Все изменилось, когда я начал программировать с Xamarin.Forms, который имеет очень хороший декларативный C# API в дополнение к XAML. Визуального дизайнера нет (только превьювер, который появился намного позже релиза XF). Удивительно, но я предпочитаю работать с их диалектом XAML, чем с кодом C#! Они проделали большую работу, и у вас нет тонны дизайнерских метаданных, загрязняющих смысл разметки. Поддерживающие фреймворки, такие как Prism.Forms, также помогают резко склонить чашу весов в сторону XAML, поскольку это помогает очень легко писать код без кода программной части.

Так что я не думаю, что XAML сам по себе является проблемой, но диалекты, разработанные в первую очередь для поддержки дизайнеров — XF — довольно убедительное доказательство для меня.

Есть новости по этой теме?

Итак, CoreWF жив и существует по адресу https://github.com/dmetzgar/corewf .

Необходимо посмотреть, можно ли теперь портировать DynamicActivity с новыми API-интерфейсами Composition, добавленными в ядро, и стандартом .net 2.0.

Было бы здорово, если бы мы услышали от команды WF.

На эту тему было сделано много интересных и полезных комментариев. Со своей стороны, я считаю, что есть смысл переносить только среду выполнения WF и отслеживание событий (т. е. без XAML, транзакций или битов WCF) в .NET Core, и я рад, что это было (отчасти) сделано.

Я согласен, что WF.Core должен существовать официально. Если бы была возможность создать более гибкий способ определения рабочих процессов, которые работают для разработчиков, я считаю, что это был бы лучший подход. Я согласен с тем, что XAML — крепкий орешек, если MS заявляет, что они не собираются портировать System.XAML, но я действительно хочу видеть WF.Core в своих проектах .NET Core Web API.

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

Я определенно готов потратить время, чтобы помочь воплотить это в жизнь.

Таким образом, OmniXAMLv2 (он находится в ветке репозитория github), который все еще находится в разработке, должен поддерживать атрибуты x:Class (https://github.com/SuperJMN/OmniXAML/issues/12). Может быть, мы можем использовать его для (Core)WF?

@ewinnington Спасибо, что указали на это!
Это определенно большой кусок. Кроме того, в .NET Standard 2.0 есть несколько типов System.ComponentModel, используемых WF. System.Transactions уже находится в corefx. Не хватает только WCF ServiceHost.

WCF ServiceHost может подождать ИМХО. Я думаю, что модель хостинга должна быть независимой, как и все остальное в мире .Net Core/Asp.Net...

@galvesribeiro Я согласен с этим, учитывая тот факт, что существует множество других способов, которыми WF может работать в мире .NET Core, включая веб-API.

Ага. Тем не менее, я согласен с @dmetzgar в том, что сегодня есть множество клиентов, которые используют WCF, поэтому его поддержка является обязательной, но опять же, это может быть отложено...

На самом деле хостинг и «язык дизайна» должны быть абстрагированы от основной среды выполнения...

Мы используем WCF с WF, но с радостью перешли бы на что-то вроде WebAPI, если бы WF был в Core. На самом деле мы все равно перешли от WCF к альтернативе RESTful. Мы получаем ТОННУ от Workflow, и это одна из моих любимых технологий .NET!

Я также думаю, что WF на ядре не должен зависеть ни от xaml, ни от wcf, просто наличие механизма wf и объектной модели было бы очень ценным. Затем вы запустите это как промежуточное программное обеспечение на ядре asp.net, особенно с новой работой конвейера / не-http, которая подходит к kestrel.

+1 за наличие и поддержку движка WF и объектной модели в Core. Мы также можем обойти XAML и WCF.

XAML — это круто — он позволяет выполнять динамическую настройку — в одном проекте мы загружаем рабочие процессы xaml из файлов, и они представлены в виде конечных точек WCF. И эти файлы XAML автоматически генерируются из реестра доступных сервисов. Таким образом, wcf-сервисы получают конечные точки:
https://[база]/wcf/[service_id1]
https://[база]/wcf/[service_id2] ...
Было бы неплохо иметь такой функционал в ядре .Net :)
О... Я уже писал это здесь раньше... :)))

Да, поскольку я стал ближе знакомиться с землей здесь, поддержка Xaml в WF не так важна сама по себе, а скорее, это действительно портирование System.Xaml, что является важной частью. Так как это четко отражено в другой -- и я очень рад сообщить, что она довольно популярна (но пусть это не помешает вам проголосовать, @freerider7777! :smile:) -- проблема, я поддерживаю создание WF в качестве зависимости как можно более бесплатным, чтобы обеспечить его попадание в .NET Core. 👍

@Mike-EEE Я уже давно там проголосовал!! :)

Видя, что рабочие процессы можно создавать с помощью кода, будет ли использование Fluent API, аналогичного EF Core, допустимым вариантом для воплощения WF Core в жизнь? Тогда сериализация/десериализация для среды выполнения может быть построена позже и ее будет намного проще реализовать?

FluentAPI... сейчас так горячо. Или, по крайней мере, с тех пор, как они были созданы. 😄

FluentAPI, Builder Pattern, по сути, они одинаковы. Предоставление основанного на коде способа, который может быть цепочечным и простым в использовании, я считаю, что это должно быть твердым принципом.

Без дизайнера все бесполезно. Конечно, мы можем все сами закодировать — всю логику, все цепочки и так далее (с fluent или без него). Но что круто в WF — можно наглядно увидеть поток обработки. Это связующее звено между менеджерами (и другими заинтересованными сторонами) и разработчиками! Менеджеры не понимают код, но эти высокоуровневые диаграммы понятны всем. С WF вам не нужны отдельные диаграммы (Visio или другие), если они разделены - они обычно не синхронизированы с реальным кодом :)

@freerider7777 Сериализация определения WF не ограничивается xaml (см. https://github.com/dmetzgar/corewf от @dmetzgar ). Его можно было бы реализовать и для JSON.. и это открыло бы возможность интегрировать/разветвлять существующие проекты, такие как NodeRed http://nodered.org/ , который во многом напоминает функции WF Designer и UX (+ он также будет работать в веб-браузере, открывая новые варианты использования WF)

Я думаю, что лучше всего портировать WF на .NET Standard, а не только на .NET Core. Связанная ранее среда выполнения WF уже работает на .NET Standard 1.3 (мы можем пойти ниже, если отбросим действие WriteLine). С выходом стандарта 2.0 у нас будет возможность заполнить множество пробелов в функциях, таких как автоматическое кэширование метаданных, DynamicActivity и области транзакций. Мы должны разделить компоненты на разные пакеты, чтобы была модель с оплатой за игру: если вам нужна только среда выполнения, вы можете придерживаться стандарта 1.3, но если вам нужна DynamicActivity, вам понадобится стандарт 2.0, и вы ограничиваете свои платформы.

В коде среды выполнения WF определенно есть много возможностей для улучшения. Например, я бы заменил расширения действий внедрением зависимостей. Fluent API был бы интересен для написания рабочих процессов в коде (и в этом направлении посмотрите https://github.com/knat/Metah от @knat), но я согласен с @freerider7777 в том, что возможность общаться с вашим руководством и бизнес-аналитиками с помощью диаграмм созданный из того, что фактически используется в производстве, является большим плюсом. @helmsb имеет большой опыт в этом (см. http://dotnetrocks.com/?show=1236).

Новый дизайнер должен быть веб-приложением. Ориентация на WPF или UWP ограничит аудиторию. Если OmniXAML сработает, люди смогут создавать/редактировать рабочие процессы, используя те же инструменты, что и сегодня (VS или повторно размещенное решение). Проблема заключается в том, что, поскольку текущий конструктор встроен в .NET Framework, любые функции или исправления должны ждать выпуска .NET Framework. Это достаточно хорошо, чтобы начать, но не долгосрочное решение. @erikcai8 провел несколько экспериментов с веб-дизайнером, похожим на nodered. Я посмотрю, смогу ли я убедить его поделиться.

Для интерфейса конструктора рабочих процессов первая попытка доступна на github: https://github.com/gary-b/WF4JSDesigner , и вы можете использовать ее вживую http://gary-b.github.io/WF4JSDesigner/

Вот как это уже выглядит:

@ewinnington : Приятно видеть POC дизайнера веб-процессов. Я также построил еще один, как показано ниже.

ААААААААААААААААААААААААААААААААА!!! ЭТО WF POC-OFF!!! 🎉

Хе-хе. Эй, @erikcai8 , где экспорт в Xaml??? Ха-ха. Просто переворачиваю тебе горе. Сорта. 👼

Обе попытки выглядят великолепно. Приятно видеть их обоих. Сейчас это кажется очевидным, но как здорово было бы иметь визуальный веб-дизайнер в оригинальном WF? Все заблокировано и загружено, готово к работе, вы просто посещаете URL-адрес. Я думаю, что это действительно помогло бы с брендингом и внедрением. К сожалению, все, кажется, приземлились на редактор на основе TFS, который было очень сложно настроить и который привел к очень многословному Xaml. Это был плохой опыт для типичного разработчика, которому приходилось иметь дело с этим, и он дал плохую репутацию всему, что связано с опытом (WF или Xaml).

Это, OTOH, кажется отличным подходом. Да начнется ренессанс!

@Mike-EEE Мой эксперимент E2E улучшил основной механизм рабочего процесса, чтобы он загружал рабочий процесс JSON изначально, поэтому формат XAML не требуется. Однако рабочий процесс XAML можно экспортировать из Workflow Engine после загрузки рабочего процесса JSON.

В этом суть. Мы не должны привязывать среду выполнения и ее объектную модель к дизайнеру и сериализованному формату, как это было в WF 4.5...

@galvesribeiro понял. Однако в эксперименте предполагалось, что формат JSON поддерживается как еще один вариант для Workflow Core. Как обсуждалось выше, XAML еще не подходит для новейших веб-технологий.

Мы любим WF, пожалуйста, перенесите его на .NetCore.

Нам нужен веб-дизайнер рабочих процессов. Поддержка ядра .NET для запуска рабочих процессов была бы вдвойне крута. иди иди

Даниэль Герлаг работает над действительно хорошим легким движком рабочего процесса, совместимым с ядром:

https://github.com/danielgerlag/workflow-core

Даниэль прошел долгий путь за очень короткий период времени. Я настоятельно рекомендую вам посмотреть на него и принять участие в этом проекте, если вы найдете в нем достоинства.

При всем этом интересе, почему бы просто не создать с нуля движок, совместимый с Net Core?

@ccpony Потому что вы можете использовать CoreWF на ядре dot net прямо сейчас -> https://github.com/dmetzgar/corewf . Центральные компоненты портированы и работают. Несколько вещей ждут стандарта .net 2.0.

@ewinnington Спасибо за ответ, но я этого не понимаю. WF не был успешным продуктом MS, и MS ничего не делала для его улучшения в течение многих лет. Сообщество изобилует свидетельствами опробованных и неудачных реализаций. Он не получил широкого распространения на предприятии. Он громоздкий, перегруженный, сложный в освоении и (все еще) глючный. Его интерфейс широко оклеветан. Она не смогла стать удобной для конечного пользователя технологией. Его внутренности, по сути, являются черным ящиком, который не может быть легко улучшен. Это МЕДЛЕННО с чем-либо, кроме простых рабочих процессов. Это очень сложно проверить. Он основан на старых технологиях (WCF, XAML). С тех пор, как Рон Джейкобс заболел, WF чахнет, и у него нет друга в MS.

На мой взгляд, WF старался быть всем для всех, а по факту ни для кого не оказался мал. Microsoft почти отказалась от него. Зачем нам возрождать что-то подобное? Если какая-либо важная технология требует переосмысления и перезаписи, ЭТО ОНА.

Посмотрите на молодой проект Даниэля Герлага. Это ново и незрело. Но для этого нужен современный подход к рабочему процессу, который легко улучшить. Если бы все здесь перестали пытаться модернизировать сложный, устаревший и, откровенно говоря, перепроектированный проект, а вместо этого направили бы свои усилия на что-то новое и лучшее, тогда у нас был бы шанс оказаться в стоящем месте - постепенное строительство механизм рабочего процесса мирового класса вместо того, чтобы пытаться переписать бегемота с самого начала. Честно говоря, я восхищаюсь всеми здесь, кто хочет участвовать в ОЧЕНЬ стоящем усилии - - создании, НАКОНЕЦ, хорошо спроектированного, функционального, легкого, удобного для изучения, кросс-платформенного рабочего процесса (машины состояний?) инструмента. Но, к сожалению, если вы все продолжите идти по этому пути, то все ваши усилия просто сойдут на нет. МХО.

@ccpony Спасибо, что поделились своим мнением. Не могли бы вы уточнить, о каких ошибках вы говорите? Если мы можем что-то сделать, чтобы исправить проблемы в .NET Framework, я был бы рад узнать об этом.

@dmetzgar Спасибо за ответ, Дастин. В то время, когда я пытался разрабатывать WF-приложения, я сталкивался с ошибками. Не только неожиданное поведение, но и несколько раз, когда сложный WF «взрывался» и генерировал ошибки в пользовательском интерфейсе XAML, которые было трудно исправить в коде XAML. У меня никогда не было большого доверия к технологии WF. На самом деле, дошло до того, что я чувствовал, будто борюсь с 800-фунтовой гориллой — каждый шаг вперед отбрасывал меня на два шага назад.

Я знаю, что это не то, что вы ищете в своей любезной просьбе подробно рассказать об ошибках. Честно говоря, я мог бы обойти эти ошибки. Но в конце концов я отказался от WF по всем остальным причинам, о которых я упоминал в своем предыдущем посте.

Вы возглавляете эти усилия, и я приветствую вас за это. Но наверняка наступает момент, когда попытка модернизации сложной технологии становится контрпродуктивной. Следя за всей этой веткой, я просто не могу не чувствовать, что прогресс очень медленный - если вообще - - и в конечном итоге из всего этого ничего не видно. Я считаю очень маловероятным, что старые рабочие процессы будут переносимы на то, что производится здесь. Люди в этой ветке говорят о клиентском рабочем процессе (т. е. JavaScript), совместимости REST, сокращении зависимостей, кроссплатформенности и т. д. Например, XAML — такая важная часть старой технологии WF, что толку от переноса WF на ядро? XAML не будет частью этого?

Итак, Дастин, я должен спросить вас вот о чем: вот уже 18 месяцев в этом проекте, и кажется, что просто нет единого мнения о том, что достигнут реальный прогресс. Я уважаю ваши усилия и вижу, что вы отличный программист, но вот мой вопрос: не было бы НАМНОГО больше смысла собрать всю эту энергию и энтузиазм и создать что-то новое?

@ccpony В этой теме обсуждается поддержка WF .Net Standard, а не наоборот.

Просто любопытно... Вы когда-нибудь использовали или видели развертывание Sharepoint в действии? Если вы это сделаете, вы увидите, что это действительно сильно зависит от WF. Вы когда-нибудь видели развертывание BizTalk? То же.

Это основные продукты MSFT в корпоративном мире, так что да, есть пользователи, которым небезразличен WF, и он используется. Это не заброшенный/заброшенный проект, как вы сказали.

С учетом сказанного, если вы посмотрите на репозиторий @dmetzgar , вы увидите, что некоторые вещи похожи или унаследовали некоторые модели поведения от старого воплощения WF, вы также увидите, что он был переработан, чтобы сделать его более легким. Постоянство разделяется, и люди могут легко создавать новые. Дизайнер отделен, и люди уже создали несколько тестов.

Я понимаю ваше разочарование в желании чего-то нового. Поверьте, я тоже этого хочу. Но вы должны понимать @dmetzgar и его команду. Это не является приоритетом, поскольку 95% клиентов являются пользователями старого WF, который в основном работает на BizTalk и Sharepoint, как я уже упоминал. Я использовал старый WF в течение многих лет в среде с очень высоким tps (банковские и финансовые транзакции), и он очень хорошо мне служил.

Моя новая технология работает с .Net Core, и единственная причина, по которой я сейчас ее больше не использую, заключается в том, что у нас еще нет ее для .Net Core.

Что я уже предложил @dmetzgar , так это перенести репозиторий WF в .Net Foundation, определить вехи, поместить туда код и добавить задачи в качестве проблем и пометить их как up-for-grabs , чтобы сообщество начало это делать. Тем не менее, это все еще требует некоторого времени от его команды, чтобы выполнить эту работу, и у них, возможно, нет этого времени (пока).

@galvesribeiro Я понимаю твою точку зрения. Да, я написал развертывание SharePoint. И я ВИДЕЛ развертывание BizTalk в действии (*затвор*). Я понимаю взаимосвязь между SharePoint и WF. (Я не знаю, что вы имеете в виду, когда предполагаете, что BizTalk каким-то образом зависит от WF. Это не так.)

Но я должен не согласиться с вами в одном важном моменте: WF — это заброшенный/заброшенный проект. Я действительно понимаю озабоченность разработчиков SharePoint на данный момент. Нет оснований полагать, что MS расширит возможности WF в SharePoint. Я не понимаю, почему вы думаете, что усилия @dmetzgar будут как-то связаны с будущим SharePoint (или BizTalk). Не похоже, чтобы MS модернизировала SharePoint кодом @dmetzgar . Извините, но будущее SharePoint никак не связано с усилиями, предпринимаемыми здесь.

Итак, все, что действительно важно, это то, получится ли из всего этого хороший двигатель рабочего процесса. И я утверждаю, что попытки загнать такого гиганта, как WF, в будущее — не лучший способ действий. Лучше строить с нуля.

@ccpony Я хотел бы напомнить вам, что здесь есть множество людей, которые активно стремятся воплотить этот проект в жизнь, и некоторые действительно тратят время на то, чтобы это произошло. Хотя лично вы можете считать WF неудачным продуктом Microsoft, он продолжает оставаться частью .NET и используется не только нами.

Эта ветка предназначена для конструктивной критики и вклада в реализацию перехода, а не для осуждения других или самого продукта. Хотя к вашим взглядам относятся с уважением, помните, что они ваши и что другие могут иначе думать о том, насколько важен для них WF.

Мы активно приветствуем ваш вклад в способы улучшения продукта и в то, как лучше всего помочь тем, кто активно участвует в этой попытке.

Спасибо =^_^=

@ccpony

(Я не знаю, что вы имеете в виду, когда предполагаете, что BizTalk каким-то образом зависит от WF. Это не так.)

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

Нет оснований полагать, что MS расширит возможности WF в SharePoint.

Я не говорю, что это будет. Я говорю, что команда, работающая с WF Today, полностью сосредоточена на поддержке развертываний Sharepoint. Даже последняя версия Sharepoint использует ту же/текущую версию WF.

Я не понимаю, почему вы думаете, что усилия @dmetzgar будут как-то связаны с будущим SharePoint (или BizTalk).

Я не говорю, что это повлияет на будущее Sharepoint. Я говорю, что команда занята поддержкой Sharepoint, если я правильно понял. ( @dmetzgar может меня поправить, если я ошибаюсь)

Не похоже, чтобы MS модернизировала SharePoint кодом @dmetzgar . Извините, но будущее SharePoint никак не связано с усилиями, предпринимаемыми здесь.

Будет ли MS использовать WF vNext на Sharepoint vNext или нет, только они могут сказать это наверняка. Опять же, проблема в том, что команда WF не может справиться с обоими.

Итак, все, что действительно важно, это то, получится ли из всего этого хороший двигатель рабочего процесса. И я утверждаю, что попытки загнать такого гиганта, как WF, в будущее — не лучший способ действий. Лучше строить с нуля.

Никто не портирует как есть. Репозиторий @dmetzgar является доказательством того, что он перерабатывается с нуля. Опять же, проблема заключается в невыполненных работах и ​​пропускной способности, и команде приходится иметь дело с обеими вещами. Вот почему я предложил «открыть» его на основе dotnet и сделать его основным усилием сообщества под руководством и контролем команды WF, чтобы мы старались как можно меньше влиять на их графики.

Опять же, как @InariTheFox и я уже упоминали, эта ветка является продвижением для переноса, что не обязательно означает принудительное включение старой версии со всеми этими функциями в новую версию. Тем не менее, важно понимать, что люди вкладывают много усилий (и денег) в свои текущие продукты на основе WF, поэтому @dmetzgar заботится о максимальной совместимости со старыми рабочими процессами, и это действительно то, о чем нужно позаботиться.

В порядке. Я вижу здесь страсти. На самом деле, если бы была хорошая замена WF, решающая все проблемы, о которых я упоминал ранее, у нас бы не было этого разговора. Для справки: многие из нас ушли из WF и с нетерпением ждали следующего. Этого никогда не было. Насколько мне известно, НЕТ текущего, поддерживаемого, функционального решения рабочего процесса/конечного автомата на основе .Net, которое получило бы широкое признание. Пожалуйста, поймите: я настаиваю на том, что WF — мертвая технология с точки зрения Microsoft.

Но, сказав это, пожалуйста, помогите мне понять. Репозиторий @dmetzgar работает как есть? Как с ним писать рабочие процессы? Я не вижу никакого примера кода и нет никакой документации. Как мне поступить?

Я думаю, что есть много продуктов/компаний, которые сделали WF центральным элементом своей продуктовой стратегии, это не просто зависимость от Sharepoint в режиме поддержки: в моей нынешней компании мы разработали платформу автоматизации с WF в качестве центральной технологии (и я знаю еще 2 конкурента с этого рынка, которые также используют WF в своих продуктах); также я обсуждал с людьми, которые используют его в Insurtech.. так что я твердо верю, что аудитория для WF все еще существует.

При этом .net core, по-видимому, является одной из основных областей деятельности Microsoft, и в следующий период в нее будет вложено множество технических инноваций; Я думаю, что было бы большой потерей, если бы WF не был частью этого.

С моей точки зрения, правильный путь для достижения этого состоит в том, чтобы сделать ядро ​​WF независимым от xaml и упростить (де)сериализацию рабочих процессов в других форматах (например, json). Это также упростило бы реализацию таких сценариев, как дизайнеры рабочих процессов, размещенные в веб-браузерах. И с репозиторием https://github.com/dmetzgar/corewf у нас есть отправная точка.

Для тех, кто заинтересован в обзоре текущего состояния WF (которое я не считаю заброшенным MS), некоторое время назад я централизовал доступную информацию о WF в посте и презентации http://andreioros.com/blog .

Мы и наши клиенты полагаемся на WF, и нам бы очень хотелось, чтобы он работал как на клиенте, так и на сервере. WF, свободный от XAML и других зависимостей, спроектированный так, чтобы быть легким, но с выразительностью существующего WF, который также поддерживается сообществом MS, был бы действительно захватывающим и ценным продуктом.

Еще раз, пожалуйста, позвольте мне спросить: что нужно сделать с портом @dmetzgar , чтобы запустить его? Каков текущий статус?

Я не знал, что порт @dmetzgar действительно можно использовать в его нынешнем воплощении...

От @ewinnington выше:

«Потому что вы можете использовать CoreWF на ядре dot net прямо сейчас -> https://github.com/dmetzgar/corewf . Основные компоненты перенесены и работают. Несколько вещей ждут стандарта .net 2.0».

В этом случае я тоже хотел бы услышать о его использовании ...

Да, это основные функции ядра. Вы можете запускать рабочие процессы на основе кода. Отсутствующие функции из netstandard2.0 в основном связаны с поддержкой транзакций.

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

Голосуйте за переписывание WF с тестами и поддержкой современных функций Roslyn как части Core. Мне бы хотелось увидеть, как бессерверные решения и контейнеры могут повлиять на архитектуру, особенно на развертывание и масштабирование наборов правил в различных контекстах предметной области и бизнес-процессах. Лично я предпочел бы краткий DSL конструктору WYSIWYG. Мне лично нравился дизайнер, но почти все время он казался причудливым. WF сама по себе могла быть чрезвычайно солидной, но требовала глубоких знаний. На самом деле, большое развертывание WF, которое включало WF Manager и постоянные потоки в SQL Server, требовало консультаций MS и исправления ошибок. Хотя последние несколько лет я поддерживаю команды Java, мне нравится следить за .NET после чуть более 15 лет сосредоточения внимания на технологиях MS. Я читал «Генерация кода с Рослином» Ника Харрисона (у меня нет никаких связей ни с ним, ни с этой книгой) и задумался о повторном подходе к пространству Business Rule Engine еще раз, что заставило меня еще раз задуматься о судьбе WF... Честно говоря, я бы подумал, что функции Azure конкурируют как с ресурсами MS, так и с их общей корпоративной готовностью поддерживать глубокие инвестиции в WF в любом месте. Кажется очевидным, что они хотели бы, чтобы вы использовали это... так что, возможно, решение состоит в том, чтобы вместо этого сосредоточиться на версии OpenWhisk для .NET с открытым исходным кодом. Но в мире контейнеров... я могу просто использовать OpenWhisk как услугу. Так...

PS простая поддержка надежного метода импорта внешних выражений может решить 60% требований к приложениям, которые думают, что им может понадобиться WF. Это был CSharpScript? Простой способ импорта базовых конфигураций бизнес-правил с помощью простого API имел бы большое значение (различные параметры сохранения, извлечения и кэширования). Благодаря одноразовой виртуальной инфраструктуре (автоматизация через инфраструктуру, контейнер и платформу как услугу) WF vNext может сосредоточиться на развертывании изменений версии как службы, а не пытаться встроить их в приложения (т. е. лучшее решение для WF). на WCF)

Мне очень интересен этот разговор. Моя команда также столкнулась с разочарованием в XAML. Наша дилемма заключается в том, что мы создаем собственный дизайнер пользовательского интерфейса, чтобы наши клиенты могли создавать свои собственные рабочие процессы без необходимости использования Visual Studio или повторно размещенного дизайнера. Нам нужна возможность сохранять фрагменты XAML в повторно используемые биты, чтобы клиенту не всегда приходилось переписывать эти биты (думайте о них как о функциях рабочего процесса). Это требует от нас знания, как объединять фрагменты XAML, что, как мы узнали, чрезвычайно утомительно. Что мы собираемся сделать, так это создать абстракцию, в которой мы просто полагаемся на модель базы данных наших различных действий и их связей и полностью игнорируем XAML. Затем мы будем программно создавать действия и т. д. при каждом выполнении рабочего процесса. Изучая этот подход, я наткнулся на эту тему. Продолжайте в том же духе, мне очень интересно узнать мнение других.

@erikcai8 Дизайнер рабочих процессов - очень хорошая идея. Могу ли я получить исходный код вашего конструктора рабочих процессов?

Я использую WF уже более 5 лет в своих проектах автоматизации, и это было замечательно. Я надеюсь, что многие разработчики поддержат этот запрос и воплотят его в жизнь. Я всегда использовал технологию .Net с тех пор, как начал работать, и хотел бы продолжать это делать. Тем не менее, возможность поддерживать кроссплатформенность — это направление компании, поэтому я действительно с нетерпением жду полной версии WF в .Net Core.

С появлением сетевого стандарта 2.0 было бы здорово получить обновленную информацию о проблемах с corewf:

@dmetzgar
https://github.com/dmetzgar/corewf/issues/3
https://github.com/dmetzgar/corewf/issues/4

Как добавленный API разблокировал процесс переноса и чем мы можем помочь?

Я думаю, что независимо от netstandard2.0 , этот порт должен идти так, как он шел, ИМХО... С переписыванием... Делая его дружественным к внешним планировщикам задач, async/await/Task и другим современным вещам. Как бы я ни любил WF, текущая версия довольно устарела...

Я имею в виду это без какого-либо неуважения. Честно. Но я один здесь понимаю, что этот проект бесперспективен? Нам отчаянно нужен хороший механизм рабочего процесса для .Net, но это не то. Разве мы не должны изменить разговор здесь?

Я открыт для нового, лучшего механизма рабочего процесса. В итоге нам нужен один в .NET Core. Мы использовали WF в течение многих лет, и он работал очень хорошо для нас, так что это лучше, чем ничего, если это альтернатива.

@kalocamgit , источник доступен в справочном источнике. Он в двух сборках:
System.Activities.Presentation и System.Activities.Core.Presentation .

К сожалению, инструмент, который публикует исходный код, выполняет только код C#. Он не включает файлы XAML. Вы можете оставить отзыв об этом по адресу [email protected] и/или проголосовать за проблему с голосом пользователя .

Код находится в .NET Framework, поэтому вы можете использовать его в своих собственных инструментах. Вот несколько примеров: проект @orosandrei и пример проекта здесь .

Я имею в виду это без какого-либо неуважения. Честно. Но я один здесь понимаю, что этот проект бесперспективен? Нам отчаянно нужен хороший механизм рабочего процесса для .Net, но это не то. Разве мы не должны изменить разговор здесь?

Хорошо, если вы _действительно_ не имеете в виду никакого неуважения. :) Мне любопытно, что все думают о Flow ? Это то, о чем я думаю, когда думаю о «рабочем процессе» для «современного дня» ... также о том, что Azure довольно активно торгует в эти дни.

Я ОЧЕНЬ ОЧЕНЬ серьезно :)

Guess Flow — это ответ на рост Zapier? Я не вижу, как это могло бы заменить WWF в любом случае.

WF прекращен или я что-то упустил? Это было бы очень грустно!

Где я могу проголосовать за WF?

Верхний пост этого выпуска - лучшее место.

Интересно, что @rjacobs (гуру WF) думает по этому поводу.

Вы имеете в виду @ronljacobs?

@dmetzgar Наверное, да. Он настоящий герой WF.

это мой ответ
https://github.com/danielgerlag/workflow-core

Рон Джейкобс был парнем, который годами вкладывал свое сердце и душу в WF. Он заразился болезнью Деркума и покинул Microsoft в 2013 году. (здесь) Когда он ушел, это было все для WF. Еще раз и, надеюсь, в последний раз: WF МЕРТВ.

И еще раз — я бы посоветовал всем и каждому взглянуть на проект Дэна Герлага выше. Он красноречив, красиво задуман и работает на Core. Любой, кто хочет внести свой вклад в жизнеспособное решение рабочего процесса, должен его посмотреть.

Также, пожалуйста, взгляните на Durable Task Framework . Это добавляется в Функции Azure, см. Устойчивые функции .

@dmetzgar Этот фреймворк находится в подгузниках, чтобы считаться альтернативой WF. Я не думаю, что это серьезно, что Microsoft предлагает такие вещи. Не лучше ли было бы вместо того, чтобы заново изобретать велосипед, переносить WF на .NET Core и повторно использовать его как основу во всех проектах Microsoft? Извините за резкость моих слов, но я думаю, что они отражают мнение многих людей, которые очень разочарованы текущим положением WF.

@Suriman , честное слово

Я обновил файл readme в репозитории corewf , чтобы лучше описать, что связано с переносом WF на .NET Core. Не могли бы вы взглянуть?

@dmetzgar Спасибо за разъяснения и за четкое указание пути переноса WF на .NET Core. Из того, что вы говорите, я понимаю, что Microsoft не собирается выполнять всю эту миграционную работу и надеется, что это сделает сообщество, не так ли? Ответ на этот вопрос является ключевым, в зависимости от ответа компании могут выбрать альтернативный путь или выполнить работу, которую должна выполнять Microsoft.

Microsoft не будет официально портировать WF на .NET Core. Я и моя команда будем работать над этим в свободное время, но не в официальном качестве и не с какими-либо запланированными релизами. Все перечисленные проблемы решаются. Такой порт используется для некоторых проектов, которые мы делаем. Именно оттуда будет поступать большая часть нашего вклада. Я думаю, будет справедливо закрыть этот вопрос на данный момент и указать людям на репозиторий corewf , чтобы следить за последними работами.

Привет,
Переход с вехи Future на 2.1 означает, что Microsoft будет портировать WF на .NET Core?

Изменение вех для закрытых проблем просто отражает, в каком выпуске проблема была закрыта.
Эта конкретная проблема была закрыта в основном как «Не исправить» - см. объяснение выше https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275.

@karelz Как жаль. На мгновение показалось, что нас поразила лотерея.

У нас есть решение на основе WF. Мы создаем шаги действий с помощью WF, и этот рабочий процесс будет доставлен всем подписчикам, и они будут обрабатывать действия на основе WF. Мы очень любим WF. поддержка кроссплатформенности – это направление нашей компании. Мы очень заинтересованы в том, чтобы WF был на .NET CORE.

Есть CoreWF , код Workflow Foundation, частично перенесенный на ядро ​​.net. Теперь вы можете использовать кроссплатформенный Workflow Foundation. В настоящее время вы просто не можете использовать рабочие процессы на основе XAML.

У меня есть ветка, в которой я работал над добавлением поддержки Dynamic Activity поверх Net Standard 2.0 .

Процесс синтаксического анализа XAML требует, чтобы Microsoft открыла System.XAML в достаточной степени, чтобы мы могли правильно анализировать файлы.

Вы можете отслеживать ход решения этой проблемы здесь: https://github.com/dmetzgar/corewf/issues/6 и в моих различных попытках привлечь внимание к этой проблеме:
На CoreFX
Об источнике ссылки

Пакет обеспечения совместимости .Net имеет пометку «Может быть» на фронте System.XAML. Но никаких новостей о его включении не просочилось. В проблеме Ship .Net Framework Compatibility Pack в настоящее время указано «нет планов» для System.XAML.

Возможно, вы также можете использовать тему Customer Adoption Epic , чтобы рассказать свою историю о том, как добавление Workflow Foundation (и System.Xaml) позволит вашей компании выпускать продукт.

Моя компания также инвестирует в WF: у нас есть продукт для энергетических компаний, где наши клиенты создают рабочие процессы с помощью Workflow Foundation.

Спасибо за ваш ответ.
это было очень полезно, оцените это.

2 ноября 2017 г., 18:22, «Эрик Виннингтон» [email protected] написал:

Существует CoreWF https://github.com/dmetzgar/corewf , который является кодом
Workflow Foundation частично перенесен на ядро ​​.net. Вы можете использовать рабочий процесс
фундамент кроссплатформенный сейчас . Вы просто не можете использовать рабочие процессы на основе XAML
В настоящее время.

У меня есть ветка, в которой я работал над добавлением поддержки Dynamic Activity.
поверх Net Standard 2.0 https://github.com/ewinnington/corewf .

Процесс синтаксического анализа XAML требует, чтобы Microsoft открыла System.XAML.
достаточно, чтобы мы могли правильно анализировать файлы.

Вы можете отслеживать ход решения проблемы здесь: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 и в моих различных попытках
при доведении до сведения этого вопроса:
На CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
Об источнике ссылки
https://github.com/Microsoft/referencesource/issues/39

Пакет совместимости .Net
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
имеет «Может быть» на фронте System.XAML. Но никаких новостей о его
включение. Проблема Отправка пакета совместимости .Net Framework
https://github.com/dotnet/corefx/issues/24909 в настоящее время перечисляет «нет
планы» для System.XAML.

Может быть, также проблема Customer Adoption Epic
https://github.com/dotnet/corefx/issues/24751 можно использовать, чтобы сказать
ваша история о том, как добавление Workflow Foundation (и System.Xaml) позволит
вашей компании, чтобы отправить продукт.

Моя компания также инвестирует в WF: у нас есть продукт для энергетических компаний
где наши клиенты создают рабочие процессы с помощью Workflow Foundation.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Привет,
Это мир микросервисов, и все они разбиты на компоненты. Теперь, если нам нужно его организовать, нам придется полагаться на приложения логики Azure или какого-либо другого внешнего поставщика, который взимает дополнительную плату за рабочий процесс. Хотя очень мало продуктов, не связанных с .NET WF, таких как Netflix Conductor, мы бы хотели иметь версию с чистым ядром .NET. Вы можете взять подсказки от проводника Netflix по адресу https://github.com/Netflix/conductor и начать создавать его оттуда. Это будет большим подспорьем для разработчиков частных облаков, у которых нет доступа к Azure Stack и которые не могут использовать Logic Apps.

Решил написать сюда для ознакомления. Я читал следующую документацию, и это заставило меня подумать об этой теме:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Похоже, что Dynamics365 и PowerApps объединяют усилия и теперь используют Windows Workflow в некоторой степени для обработки своих рабочих процессов. Это, конечно, все только для Windows, но в новую эру кроссплатформенности и т. д... как долго это продлится?

Я не знаю, что я должен использовать. Я бы хотел, чтобы MSFT сделала это. Внесите ясность Microsoft.

@VenkateshSrini , вам также следует заглянуть в Cadence: https://github.com/uber/cadence
Модель больше похожа на SWF от Amazon, но с открытым исходным кодом. Однако пока нет клиента .NET.

Ищу. Чистая основная версия

Не произойдет.

От: [email protected]
Отправлено: среда, 26 сентября 2018 г., 00:30
Кому: dotnet/corefx [email protected]
Копия: Джеффри Майкельсон [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [dotnet/corefx] Портирование Workflow Foundation на .NET Core (#2394)

Ищу. Чистая основная версия

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 или отключите ветку https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY .

Очень плохо

Итак, что Microsoft предлагает для ifttt или рабочего процесса в экосистеме, отличной от Azure. Если они хотят включить такие вещи, как мл из Azure, почему бы не рабочие процессы

Посмотрите работы Дэна Герлага.

https://github.com/danielgerlag/workflow-core

От: [email protected]
Отправлено: среда, 26 сентября 2018 г., 8:34
Кому: dotnet/corefx [email protected]
Копия: Джеффри Майкельсон [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [dotnet/corefx] Портирование Workflow Foundation на .NET Core (#2394)

Итак, что Microsoft предлагает для ifttt или рабочего процесса в экосистеме, отличной от Azure. Если они хотят включить такие вещи, как мл из Azure, почему бы не рабочие процессы

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- .

Существует CoreWF , который является портом основы рабочего процесса для ядра .net. Этот порт развивается. Мы ищем людей, чтобы помочь.

Следующим важным этапом является компиляция загруженных рабочих процессов с помощью Roslyn, чтобы мы могли использовать код в параметрах рабочего процесса, это необходимо для рабочих процессов, определенных XAML. Если вы определяете рабочие процессы в ядре Imperative, теперь вы можете использовать CoreWF.

Спасибо за вашу работу @ewinnington и @dmetzgar ! Поддержка XAML через Portable.XAML в CoreWF является огромным преимуществом для этих усилий. @dmetzgar Планируете ли вы в ближайшее время опубликовать новую версию в NuGet?

Всем привет,

Это все производство готово. Мы предполагаем, что определение рабочего процесса будет выполняться из внешнего пользовательского интерфейса. Но движок должен иметь возможность загружать определения и работать с ними. Больше похоже на iffft

@VenkateshSrini , я не думаю, что Microsoft необходимо предоставлять кроссплатформенную структуру рабочего процесса. Во времена .NET Framework Microsoft предоставляла все, что было в ущерб всему сообществу. Я хотел бы, чтобы организации приняли больше библиотек с открытым исходным кодом .NET и сделали их «готовыми к производству».

@watertree , я жду новую версию Portable.Xaml. Для поддержки CoreWF XAML требуется критическое исправление.

Какая альтернатива длительным рабочим процессам на данный момент (с постоянством)? Только платные?

@фрирайдер7777

К вашему сведению: https://github.com/danielgerlag/workflow-core

Мы используем его в нашей компании с очень хорошими результатами.

Для тех, кто все еще следит за проектом, проект CoreWf только что продвинулся к важной вехе с интеграцией Roslyn, позволяющей выполнять динамически загружаемые рабочие процессы XAML. Если вам все еще нужен Workflow Foundation на ядре dotnet, ознакомьтесь с ним.

Привет ,
Означает ли это, что я могу взять существующий рабочий процесс XAML и использовать его как есть. Есть ли у нас ограничения

Есть ли у нас ограничения

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

Пожалуйста, создайте проблему в репозитории CoreWf и перечислите требования, которые у вас есть. Мы можем продолжить разговор там.

Текущая версия nuget для corewf устарела и не включает выполнение Xaml среды выполнения на основе Roslyn, которое только что было объединено. Мы все еще ищем отзывы, чтобы увидеть, что работает, а что нет.

Значит ли это, что этого никогда не произойдет?

Этого не произойдет. Этого никогда не должно было случиться - не в обиду тем, кто приложил все усилия. Ознакомьтесь с проектом Дэна Герлага (https://github.com/danielgerlag/workflow-core) или примите участие в поезде Azure LogicApps.

Здравствуйте, это октябрь 2020 звонит. Есть новости/обновления/релизы по Workflow Foundation на .NET Core?

или нам всем переехать к Эльзе? https://elsa-workflows.github.io/elsa-core/

@wstaelens Я думаю , что ответ MS был довольно ясен : WF не будет официально перенесен на .Net Core. Предлагаемая альтернатива — CoreWF .