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 应用程序上的应用程序 UI 流，例如由于其轻量级运行时。

我真的认为 WF 是 .Net 平台上一个非常强大的组件，但是对于今天的技术，XAML 仍然是它的“限制器”，但是，如果对于 MS 的战略决策，我们可以保持原样并移植到 CoreCLR。

谢谢

@zhenlan可以谈谈当前对 WF 的看法

@galvesribeiro很多人可能不使用 xaml，但很多人使用，它确实被认为是 WF 的核心部分。 我们广泛使用 xaml，所以我认为没有 xaml 支持的 WF 几乎不值得使用。

我希望我们继续游说微软打开 System.Xaml。

并且使用 JSON 作为替代品一点也不吸引人。

@galvesribeiro @jakesays我们真的很想了解 WF 客户对 WF 的 .NET Core 版本有多少兴趣，因此很高兴听到来自社区的反馈。 如果有足够的需求，将有助于我们前进。

我们正处于评估可行性、依赖关系、功能优先级等的早期阶段。因此，了解您的想法以及为什么 .NET Core 上的 WF（与完整 .NET 中的 WF）将是非常有帮助的对您有用以及您希望首先看到的 WF 功能。

@galvesribeiro在您在代码中构建工作流并将这些定义存储为 JSON 的场景中，您（计划？）使用 for 表达式？ 你是用VB表达式，C#表达式，还是有自己的基于CodeActivity的表达式Activity来处理表达式？

感谢您的输入。

@jakes说我可以使用 XAML。 我只关心性能...

@zhenlan我们有一个电子支付交换机，每天为巴西的一些银行和国外的一些银行处理数十亿笔信用卡/借记卡交易。 我们完全在本地，我们正在更新技术以完全云化，并在 Azure 上作为服务提供。 我们获得了一份企业协议，以便在这里探索我们需要的一切 Azure 作为我们客户的多租户支付处理平台。

我们正在调查 NanoServer 和 CoreCLR 的使用，以便我们可以减少运行服务的占用空间、攻击面和维护成本，我们注意到 coreCLR （至少）还没有移植 System.Activities。 换句话说，没有工作流基础。

我们的核心处理引擎是建立在顶级 WF 之上的业务引擎，它包含 40 多个专注于我们业务的自定义活动。 该引擎实时处理交易流程/规则以获得交易批准。 我们需要根据需求对其进行扩展，并使用当前在云中实施的 WF 来实现，假设是不可行的。

将其移植到 .net 核心，而不是将其保留在完整的 .net（服务器配置文件）上，将打开运行客户端工作流的可能性，这是我们在业务中真正怀念的东西。 这些客户端工作流可以让人们开发客户端-业务逻辑声明性，在某种程度上，智能手机、可穿戴设备、物联网和我们的支付终端设备等小型设备可以在不编写真正重复代码的情况下做出一些决定。

由于我们没有在 .net Core 的 WF 上做出任何努力，甚至多年来都没有改变，仍然依赖于 XAML，因此我们决定启动自己的工作流引擎，其行为方式与 WF 完全相同。 相同的活动模型，相同的代码风格等，但更轻量级并且基于 Json 作为他们的定义存储。 这允许具有较小计算能力的设备处理工作流，而无需处理 XAML/XML 的开销，因此我们为 WF 编写的大部分代码都可以在没有对 Json 定义而不是基于 XAML 的工作流进行很多更改的情况下工作。 此外，远离 XAML 将为新的工作流设计器打开可能性......不会停留在 Visual Studio 和 WPF 应用程序上以重新托管 VS 设计器。

我试图建议的是这些选项之一：

1. 将 WF（带有 XAML）端口与 .Net 核心一样。 此选项将花费更多时间，因为今天的 WF 依赖于 .Net 的服务器配置文件，这将使我们花费大量时间将其解耦以使其与 .Net 核心一起使用。
2. 端口 WF 将其重写为 .Net 核心。 通过这种方式，我们可以获得核心概念，并专注于设计一个更轻量级的引擎，该引擎可以在服务器、客户端、物联网或任何需要的东西上运行，并保持目前在 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 资源管理器 (ARM)，他们已经这样做了！ 他们将资源部署作为 Json 模板进行，该模板具有依赖关系和流程，并且可以将变量称为表达式。 看看这个：

“变量”：{
"位置": "[resourceGroup().location]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameters('password'))]",
"authorizationHeader": "[concat('Basic', base64(variables('usernameAndPassword')))]"
}

好的，他们使用的是 JavaScript 函数，但原理是一样的。 它们在模板顶部有一个 $schema 变量，用于指导文档结构、我们可以作为活动制作的部署过程的步骤。 设计与 WF 非常相似，但此 DSL 侧重于资源组部署。 我们可以使其更通用，并以与当前 WF 实现相同的方式使用活动。

如果你们认为值得一试，我们可以开始在另一个问题上绘制一些文档，这些文档将指导“新 WF”的架构。 如果这听起来很疯狂并且超出了您的计划，请告诉我，我们仍然会在最后开发它以支持 .net 核心，并稍后将其作为 nuget 发布给人们。 我只是想让这个美妙的框架与当前（即将到来的）技术保持同步。 这确实是我们的业务需求。 我们非常依赖 WF，但如果它没有得到更快的速度和 coreCLR 的支持，我们将需要开始准备这个新框架，以便当 NanoServer+coreCLR 是 RTM 时，我们可以移动它。

如果您有任何问题，请告诉我。

谢谢

PS：如果你需要聊天，我每天都在 gitter 频道上。

@galvesribeiro因此，在从存储在 JSON 中的工作流定义创建 Activity 对象后，您正在使用 TextExpressionCompiler 编译表达式。 对？

@jimcarley我们还没有表达式编译器工作。 我们仍然使用相同的 TextExpressionCompiler 原理来设计它，但是是的，它看起来非常相似。 当前的实现看起来还与 System.XAML 相关联。 由于它未打开，我无法确认是否会以与 TextExpressionCompiler 相同的方式（内部）工作，但是是的，在加载活动后，我们应该评估/编译表达式（如果尚未在缓存中）并公开一个 Expression 对象由活动的消费者评估（如果需要）。

去年，我在表达式方面做了一些工作，以在自托管 WF 设计器中启用 C# 表达式支持。 它基于 nrefactory 和 roslyn。 如果有人感兴趣，我可以挖掘它。

@galvesribeiro在对您的 json 方法进行了更多思考之后，最后我想这对于新的开发真的无关紧要。 如果 MS 不会打开 xaml 支持，那么这可能会起作用。

@zhenlan我同意@galvesribeiro的观点，因为我们不一定要寻找 MS 来组建团队来移植 WF。 这绝对是社区可以在您的团队等的指导下做的事情。

@jakesays我同意你的观点，如果我们为 coreclr 再次创建 WF，存储实际上并不重要。

关键是，为什么要继续使用 XML 而不是 Json，因为我们在网络上有很多测试比较两者的（反）序列化性能，而 json 比它快得多并且消耗的资源更少？（例如比较 Newtonsoft 的 Json.Net 和常规 XML 序列化程序）如果 WF 将在占用空间小的客户端设备（任何物联网）上运行，则每个内存字节都很重要。

此外，使用 json，立即获得新的基于 Web 的 WF 设计师要简单得多。 表达式的编译和执行并不难实现。 它大致是构建表达式对象的字符串解析器。 困难的部分（恕我直言）是在 VS 上为设计 WF 时使用的类型获得智能感知，但我很确定 Roselyn 和语言服务可以帮助我们，并且 VS 有它的基础设施。

@galvesribeiro您提到您已经使用基于 JSON 的工作流定义和序列化构建了自己的工作流引擎。 如果 WF 被移植到 Core，你真的会使用它吗？

@dmetzgar我们开始开发和测试它作为概念验证，我们可以在几乎不依赖于框架的更清洁的 WF 中获得更好的结果，这很好地让它在 coreclr 上工作。 我们没有准备好。

我希望不必构建自己的引擎并继续使用 WF，即使它基于 XAML 但移植到 coreclr 并且它遵循与 EntityFramework 和 ASP.Net 的 coreclr 版本相同的概念（例如，不要依赖服务器库并在任何地方运行）。

关键是，如果它仍然依赖于 XAML 和服务器配置文件，它将一直很慢（需要太多资源），受限于设计人员的选择等。

我的建议是使用 Json 将它移植到 coreclr，并删除它现在拥有的许多依赖项，让用户能够在他们想要的任何地方运行它，就像你可以在 IoT ARM 设备上运行 ASP.Net vNext 一样（只要 ARM 支持完成了！）并且不用担心依赖和高资源消耗。

我们今天所有的工作流都是用当前版本创建的，其中一些是用纯代码编写的，有些是用 XAML 编写的，但在这两种情况下，我们仍然有依赖关系。

恕我直言，将它原样移植到 coreclr 并不会带来太多好处，除非有人为运行时和设计时的 XAML/XML 解析/呈现提供了超级新的轻量级引擎。 但是如果你们决定按原样移植，我们将继续使用它，因为它将使我的 XAML 工作流从第 0 天开始工作（我希望），即使我知道它不会带来任何实际好处......

同样，无论你们如何决定，我（可能是@jakesays和其他 WF 用户）都可以通过两种方式（XAML 或 JSON）帮助这个端口。 我只是想确保这个端口不只是复制&粘贴&修复让它工作，相反，它为使用它的人带来了真正的好处，遵循与 coreclr 相同的想法，它可以在任何地方运行而没有痛点。

谢谢

@galvesribeiro我同意 XAML 过于紧密地集成到 WF 中。 回到Dharma 关于工作流的原始书籍，他有一个从 Visio 构建工作流的示例。 至少通过移植到核心，我们可以将其划分为运行时与 XAML 分离。 这使我们可以继续进行或不将 XAML 团队移植到核心，并且我们可以随时将 XAML 工作流支持添加为单独的 GitHub 项目/NuGet 包。 我绝对支持以任何格式定义和保留工作流。 谢谢，这个反馈很有帮助。

@dmetzgar我毫不怀疑有一天 XAML 将被移植到核心......如果 .net 核心要在 windows phone 或任何 windows 10 移动设备上运行，它会在某个时候发生，我完全同意你的看法，我们可以构建一个新的核心，并在以后添加工作流的定义和状态的持久化。

那么，我们需要做什么才能开始移植呢？ （我们已经签署了贡献者协议，并且与 MS 等有其他 NDA 作为公司）

谢谢

@galvesribeiro我感谢您的热情！ 尽管打开 GitHub 存储库并开始 hack 很诱人，但其中涉及一些步骤。 此外，不只是 System.Xaml 必须被剔除。 WF 中还有其他根深蒂固的依赖关系，例如 System.Transactions 和一些与 WCF 共享的组件。 我们正在研究每一个。

我明白。 好吧，我不想逼你们，我只是担心时间。 我们现在要做出决定，继续推进自己的建设，或者加入这里的社区并将 WF 移植到 coreCLR，这样它就可以满足我们产品的时间表。

@dmetzgar您是否考虑过将现在可以开源的部分发布到https://github.com/Microsoft/referencesource？ 我认为这可能比创建一个真正有效的成熟开源项目要简单得多。

这样，您可以花时间使用正确的版本，同时其他人可以创建自己的部分/自定义版本。

完整 .NET 中的@svick WF 组件不久前已经在 github 参考源上发布。 例如，您可以找到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 时间范围内合并到同一个团队中，因此我们拥有 WCF 和 WF 都使用的 System.ServiceModel.Internals 之类的东西。 .Net 核心移植了很多重要的东西，但是缺少很多东西。 解决缺失的部分可能需要更改设计或重写功能。

这些问题都不是不可克服的，我只是不想轻视努力。 这适用于代码及其周围的一切，例如获得法律批准、构建环境、测试基础设施等。我们绝对希望社区提供帮助，我们正在努力实现这一目标。 您是否应该编写自己的端口或等待“官方”端口取决于您的时间范围。 在 Nano 服务器上运行工作流是我们最大的场景之一，我很乐意得到您的帮助。

@dmetzgar我明白，当我站在你这边时，当任何问题必须提交给公关或法律时，总是会有一些延迟:)

好吧，如果我们至少有一个时间框架的概念，我们就可以做好准备并等待它。 我讨厌在“错误的地方”实施某些东西的想法，或者当我们已经在某个地方付出了一些努力，我们可以联合起来做得更好。

请让我知道我们是否可以做任何事情，或者如果您有任何消息，或者如果您需要有关设计/端口的任何建议，请联系我。

谢谢

随着时间框架变得更加清晰，我将在此线程上进行更新。 我很高兴听到人们对其他场景感兴趣。Nano 上的 WF 是目前的主要场景，但很高兴知道其他人在做什么。

大家好，除了 XAML 和 JSON，还有一种很酷的活动组合方式：元编程。 看看我的实验项目：Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah)。

@jakesays您能否提供一些有关如何在自托管 WF 中启用 C# 表达式支持的指导。

请保留 Xaml。 :) JSON 序列化对象也会很有趣。 但我更希望看到在框架中以某种方式配置的提供程序来选择首选格式。

@dmetzgar （和其他 MSFT 人员）有关于这个主题的任何消息吗？
谢谢

我们一直在努力，并取得了很大进展。 XAML 目前在 Core 中不可用，因此我们专注于运行时。 我们正在考虑向其他序列化程序开放。 因此，与其在 JSON 或 XAML 之间进行选择，我们更愿意允许您使用自己的序列化程序。 还有更多的合规性和法律问题需要获得批准。 由于不是很多客户都在推动这个端口，因此它的优先级较低。

@dmetzgar甜！ 我很乐意为它做出贡献，但是如果这成为一个核心项目，我可以为它做出贡献……无论是 Web 工作流设计器等。似乎 xaml 几乎不需要定义格式……很高兴听到关于这项工作！

大家好，圣诞快乐，新年快乐！

那么，我们是否有关于该端口的任何更新，或者至少是当前工作的 OSS 版本，以便我们可以提供帮助？

谢谢

@galvesribeiro我会尽力解释情况。 在我将 WF 移植到 .NET Core 的热情中，我没有考虑到整个事情的业务方面。 WPF/XAML 未移植到 .NET Core，这代表了 WF 的很大一部分。 虽然 XAML 对于运行时不是必需的，但它是大多数客户构建工作流的方式。 这限制了会发现 WF on Core 有用的受众。 担心之一是我们在 Core 上发布 WF，并且没有太多的社区参与。 这增加了我们的支持成本，并没有改善大多数 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 框架绝不会消亡。 我们将继续支持它，添加功能等。因此，我们不必将 WF 移植到 .NET Core 以使其保持活力。 WF on Core 基本上是一个新产品。 想出一个可靠的商业理由是困难的。 甚至可能是时间问题。 随着越来越多的公司采用 Nano 服务器，可能会有更强有力的案例。

@dmetzgar Portable.Xaml 怎么样，它可以替代吗？ https://github.com/cwensley/Portable.Xaml它已被提取以供 Eto 的奇妙 Eto.Forms 项目的作者使用。 它是 MIT 许可的，并且（它在 mono 项目中派生的类库也是如此）。

@dmetzgar ，

我会尽力解释情况。 在我将 WF 移植到 .NET Core 的热情中，我没有考虑到整个事情的业务方面。 WPF/XAML 未移植到 .NET Core，这代表了 WF 的很大一部分。 虽然 XAML 对于运行时不是必需的，但它是大多数客户构建工作流的方式。 这限制了会发现 WF on Core 有用的受众。 担心之一是我们在 Core 上发布 WF，并且没有太多的社区参与。 这增加了我们的支持成本，并没有改善大多数 WF 客户的情况。 虽然看到 WF 在 Linux 机器上运行很酷，但很难证明有人会真正使用它。

我认为 WF 当前用户的最大动机是 Nano 服务器和微服务，而不是 Linux。 Linux 会增加更多的用户，但这并不是真正的动机。

但是，这对现有的 WF 客户有何好处仍然存在疑问。

我们在云天。 请记住，“云优先，移动优先……”以及正在增长的大型技术之一是容器、微服务，以及 MS 提供的一个大产品是 Nano Server。

如果有一天像 SharePoint 或 Dynamics 这样的大客户出现并说他们正在迁移到 Nano，那么我们就有了一个令人信服的案例。

即使使用地球上最大的 Sharepoint 或 Dynamics 部署，我们也永远无法达到相同数量的用户，我什至会说与使用云技术产生的收入水平相同。

如果 .NET Framework 团队决定制作一个可以在 Nano 上运行完整框架的包，那么这一切都没有实际意义。

今天的 DNX（就 RC1 而言）不仅由 coreCLR 组成。 它也有完整的框架（dnx451），所以我们目前可以在 DNX 上使用 WF，这与这里的问题无关。 我们正在谈论 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 公共/云服务以某种方式使用它。 几年前，它由 MS Research 提供 OSS，现在由 343 Studios、MSR 的一些人以及 MS 内部其他团体的一些人维护，但主要由社区维护。 今天，我认为自己是该项目的积极贡献者，我支持新用户以及那里的其他 MS 和非 MS 人员。 我们甚至在奥尔良的 GH 团队中也有前员工（比如我）和非 MS 员工。 这是否意味着我们没有支持？ 好吧，我没有购买 Orleans，所以我在与 MS 的合同中专门为 Orleans 合法地寻求支持，但是，我可以通过针对 .Net 框架或任何其他相关产品来做到这一点，所以我真的不同意你的说法。

想出一个可靠的商业理由是困难的。
如果您只寻找 Sharepoint 和 Dynamics 客户，我同意您的看法。

好吧，我们和世界上许多其他公司一样，与微软保持着大型企业协议 (EA)，在这些合同中使用大多数可变产品。 在我们的案例中，我们每天处理数百万笔金融（信用卡/借记卡）交易，每笔交易代表一个在 Orleans 之上和 Microsoft Azure 内部运行的 WF 实例。 我不知道作为商业理由对你来说有什么大不了的。

我只是认为没有 XAML 的核心（System.Activities）可以移植到 coreCLR，并且可以根据需要为 XAML、Json、HTML、XML 等创建设计器。 通过解耦这种依赖关系，其他可能性就打开了。

就像我在这个帖子开头所说的那样，我们现在想要做的最繁重的工作就是将其 OSS 化，并让 MSFT 的某个人（至少最初是这样）可以审查 PR。 这里的常识是重写 WF 而不仅仅是为 coreCLR 复制和过去，所以我们期待在这方面做出巨大贡献。

如果这不会发生，我认为我们可以关闭这个问题，至少人们会开始寻找其他 OSS 甚至付费的 Workflow 引擎，最终将获得 CoreCLR 支持。 我只是觉得CoreCLR里面没有它是一个很大的损失......

我可以给出一个非常充分的理由说明为什么应该将 WF 移植到 .Net Core。

微软正在将开发人员引入 UWP 平台。 UWP 将成为未来的 Windows 平台。 这与将应用程序移植到 Linux 等的梦幻般的想法无关。在 Windows 10 机器上运行 WF 是非常必要的，而 UWP 是 Windows 10 平台的未来。

我们偶尔会构建连接的应用程序。 我们有一个 .Net 后端和一个 UWP 前端。 目前，所有业务逻辑都在 .Net 和 UWP 之间共享。 但是，我们想在 WF 中对业务逻辑进行软编码。 这在 .Net 中可以正常工作，但 UWP 目前不支持 WF，因此 WF 变得无用，因为除非用户连接到 Internet，否则他们无法进行经 WF 逻辑验证的调用。

UPW 有一个 XamlReader，所以解析 XAML 并不是什么大问题......

@MelbourneDeveloper 完全同意您的看法，但是请记住，UWP 和 .Net Core（至少现在）不在同一个名称下，这意味着即使它们共享相同的较低级别的 API，具有相同的 API 表面（和 . Net Core 是 OSS 而 UWP 不是），它们不是一回事，不兼容。 换句话说，您不能将 .Net Core 程序集添加到 UWP 程序集。 这些差异（恕我直言）最终会消除，但就目前而言，它们仍然存在......

是的。 明白了。 这是基于工作假设，这两个东西将在未来结合在一起。 如果他们不是，上帝帮助我们！

此外，@MelbourneDeveloper UWP 的 Xaml 是 .NET 的 Xaml 的完全不同的简化版本。 WindowsDev 的 UserVoice 充斥着改进其 Xaml 系统的投票（继续被忽略，就像 UWP 看起来的所有东西一样——难怪他们甚至有一个 UserVoice 开始）投票：
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。 UWP 的 Xaml 系统就目前而言确实是个笑话，这也是其采用率如此糟糕的部分原因。

除了这样的注释，我还有一个供 MSFTies 考虑的业务用例：NodeJS。 我们在这个问题上讨论的时间越长，NodeJS 在市场上的价值就越大，因为它是真正的跨平台并且真正无处不在，这是 MSFT 技术目前（或在可预见的未来）根本无法声称的。 NodeJS 在服务器和客户端（全部）上工作，并支持两者之间的代码重用。 一个代码库可以在本地（通过 Cordova）和 Web（通过标准 HTML5 浏览器）场景中工作，这比使用基于 MSFT 的解决方案要便宜得多。

很快就会发现，在 NodeJS 中重做一个系统并完全放弃 MSFT 将比等待（感觉像是）功能失调的团队赶上市场的经济现实更容易接受（而且显然更便宜）。

我还提到了这一点，因为有人提到 MSFT 似乎确实指望 UWP 为其客户端平台，但它只占据了 NodeJS 市场的一小部分。 当我说分数时，这可能是夸大了。 我们说的是 200m（Windows 10 的最新安装数量）与基于 nodejs 的应用程序可以达到的约 3B（十亿）个设备。

不要误会我的意思，我喜欢 MSFT。 我已经用它的技术投入了超过 15 年的时间，我个人完全投入到这里。 然而，随着这项投资的到来，看到每个人都做对了，并为在开源、跨平台令人敬畏的新时代做出的决定和努力感到自豪。 我还希望每个人都意识到迫在眉睫的市场威胁（也可能验证/确认我的恐惧）。

最后，如果一切顺利，我们当前的跨平台 Xaml 状态确实存在另一个大问题，因为 Portable.Xaml 与 OmniXaml 不同，所以在某些时候，我们作为一个社区将不得不弄清楚如何协调两者代码库...理想情况下。 :)

@Michael-DST 在所有方面都同意您的看法。 我们希望 WF 运行的目标之一是客户端（特别是移动和嵌入式）。 我们希望通过在其上添加 WF 来减少本地业务规则的客户端代码。 对于客户而言，我并不是严格地说 UWP，比如 Windows 设备（手机、平板电脑和物联网）......

我确实相信有像 BizTalk 和 Sharepoint 这样依赖 WF 的主要产品，但它们仍然可以依赖 .Net 完整版，而 .Net Core（以及后来的 UWP）上的人们可以依赖全新的 WF/XAML API。 我知道这将意味着代码库周围有很多#ifs，但这将是要走的路……

@galvesribeiro感谢您的验证/支持。 感觉就像我有时在滑坡一样，因为似乎没有人认识到 .NET 面临的这个非常真实的（存在的？）问题。 事实上，.NET 领导层建议将 .NET 与 AngularJS 配对用于 Web 应用程序，从而加剧了这个问题，这基本上是在鼓励组织完全改用 NodeJS！ （完全披露，我写了那个。：P）。

我不愿在这里发布关于 NodeJS 的太多内容，因为 WF 更像是一种服务器端技术，但我（和其他组织开始）看到它的方式，这会影响所有领域并全面威胁 .NET。 目前使用 NodeJS 作为解决方案堆栈更具成本效益（和市场覆盖效率），我们（再次，讨厌重复我自己 - 但不是真的）看到这反映在组织中他们选择的技术。

底线：我必须将我的焦虑放在某处，而这个线程是受害者。 :P #sorrynotsorry

关于#if defs...糟糕，我将在此处引用MvvMCross 宣言：“# 用于 twitter，而不是代码。” :P

最后，我忘了标记@SuperJMN ，因为他也应该知道这个线程/讨论（作为 OmniXaml 的作者）——没有不尊重的意思，伙计！ 我将在下周左右亲自解决 OmniXaml 与 Portable.Xaml 的问题。

@Michael-DST 是的......实际上#if 只是一种方式...... .Net Core 团队采用了“Native Shims”的方法，其中真正的（特定于操作系统的）实现被抽象在一个薄的较低层的本机代码上。 在 WF 的情况下，它可能是 .Net Full 的垫片，而另一个是 .Net Core 的垫片......

我不是 Node.js 和 JavaScript 的粉丝（我倾向于认为它仍然是一种脚本语言，而不是一种编程语言，但这是我自己的选择），但我必须同意，如今，没有什么可以与之相比就 xplat 而言。 Microsoft 本身将其用于 VSTS 上的构建代理（仅举一种情况，MS 上还有其他情况），因为它可以在任何平台上运行，例如...

我确实认为 WF 是一项了不起的技术，当前版本是服务器端的用户，但是使用 .Net Core，并且也可以完美地在客户端上......

@galvesribeiro ...我100％与您同在。 EF Core 1.0 也是如此……一种传统的服务器端技术，现在也可以在客户端使用。 以这种方式也可以使用 WF 将非常方便。

此外，很高兴听到有关垫片的信息。 很赞同。 :)

最后，我不想在这里破坏/劫持线程（太多），但可以肯定的是：JavaScript：我同意作为一种脚本语言。 但是，它也是一种非常灵活的“语言”，可以以其他形式使用，尤其是字节码（ish）。 我相信您已经看到，对于 C++， LVVM 编译器具有魔力。 .NET 开发人员社区中日益增长的/流行的要求是为 .NET 做同样的事情（以官方身份将 .NET 转换为 JS）。 这将真正纠正当前 MSFT 开发人员环境中的所有当前（主要）弊端。

无论如何，回到您的常规计划节目。 :P 感谢您的对话和想法！

你们谈到了一些我已经处理了 9 年的事情。 许多使用 Microsoft 技术的人都没有掌握一些东西。 即分布式计算的概念。 从一开始，我们软件的一个基本要求就是它可以在偶尔连接的模式下工作。 随着时间的推移，微软在为此提供工具方面采取了各种尝试，但从未开发出全面的框架。 我们这里有一些同步框架，那里有一些 LINQ 数据库，但没有综合工具集可以让所有东西协同工作。

在过去的 9 年中，我们一直在开发自己的偶尔连接的框架。 它现在可以在 .Net、Silverlight 和 UWP 上运行。 我们非常努力地利用 EF 和 WF 等 Microsoft 框架，但在 Silverlight 等客户端技术平台上没有为这些技术提供支持。 我们已经为 Silverlight 构建了自己的 ORM 和同步框架，现在与 UWP 兼容。

一开始，当 WF 引起很多热议时，这非常令人兴奋，因为它提供了一种无需代码即可对业务逻辑进行软编码的方法。 但是，随着时间的推移，我越来越不愿意认为会有像 Silverlight 这样的客户端技术的端口。 我在论坛上发布了很多关于此的问题，但答案总是一样：WF 是一种服务器端技术，为什么要在 Silverlight 中使用它？

正如 galvesribeiro 所说

“我确实认为 WF 是一项了不起的技术，当前版本旨在成为服务器端的用户，但是使用 .Net Core，并且也可以完美地用于客户端......”

和

“我们希望 WF 运行的目标之一是客户端（特别是移动和嵌入式）。我们希望通过在其上添加 WF 来减少本地业务规则的客户端代码。对于客户端，我并不是严格地说 UWP 像 Windows 设备（手机、平板电脑和物联网）"

人们要明白的是，说到分布式计算，客户端和服务器技术是没有区别的。 想想 Git 的工作方式。 无论您是查看中央存储库还是网络上某处的节点，Git 的代码都是相同的。 代码到处都是重复的。 我们的框架也是如此。 业务逻辑复制到所有节点。 那是因为即使用户没有连接到网络，他们仍然需要服从相同的业务逻辑。 在分布式计算中，每台计算机实际上就是一台服务器。 它实际上运行与服务器相同的代码。

我们永远无法利用 WF，因为我们无法在 Silverlight 中运行 WF 代码，现在我们也无法在 UWP 中运行它。 看到 EF 被移植到 UWP 令人鼓舞。 也许这是微软开始理解分布式计算是必要的。 但是，微软需要加入分布式计算，并将 WF 作为整个分布式计算框架的一部分。 也许到那时，我们将能够删除我们的分布式计算框架，而我将不再需要维护该代码。

真的很棒的观点和想法@MelbourneDeveloper。 感谢您分享他们。 我也是 Silverlight 的超级粉丝，并且从那以后一直在努力（因此我的投票结果和 - 真的 - 上面的网站）。 另外，我很好奇你对Azure 移动服务的看法，你是否考虑过在你的离线故事中使用它？ 我是一个带分布式计算的新手（但要挖掘你要说的），但我真的很想在明年进入它（我也听到了很多微服务，我相信这是最新的等价物？） .

人们要明白的是，说到分布式计算，客户端和服务器技术是没有区别的。

真的好点。 在这一点上，一切都与技术的托管位置有关。 也就是说，我会说，你真的受到你试图“分发”的技术主机的限制（同样我不是这方面的专家）。 主机越普遍（或容易获得），应用程序的分布式/可访问性就越好。 Annnnnd....我想你知道我要去哪里。 :P

在任何情况下，实际上感觉就像我们都在通过这次讨论就_something_ 达成一致意见，这对我来说是一个值得欢迎的改变/成就。 ;)

@galvesribeiro

请记住，UWP 和 .Net Core（至少现在）不在同一个名称下，这意味着即使它们共享相同的较低级别的 API，具有相同的 API 表面（并且 .Net Core 是 OSS，而 UWP 不是） ，它们不是一回事，也不兼容。 换句话说，您不能将 .Net Core 程序集添加到 UWP 程序集。 这些差异（恕我直言）最终会消除，但就目前而言，它们仍然存在......

看看这个 PR dotnet/corefx#5760，我希望这能澄清一些事情。

UWP 的 .NET 端 _is_ .NET Core。 但是，.NET Core 提供了多个运行时。 UWP 使用基于 AOT 的运行时，因此不支持某些需要 JIT 的功能（例如 LCG 或 RefEmit）。 但是，它们共享相同的程序集和（向前）相同的 NuGet 包。 我们专门设计了堆栈以允许从 UWP 和 ASP.NET Core 交叉引用程序集（和包）。

当然，在此之上还有一个称为可移植类库 (PCL) 的 VS 工具，它试图帮助您构建可在一组平台上工作的库。 您可以在 PCL 目标对话框中做出一些重要的选择，所有这些选择都会导致您的二进制文件与 .NET Core 兼容。 但是，由于 VS 中的可移植性是通过查看平台来确定的，因此您将无法从 UWP 应用程序引用 PCL，除非该 PCL 表示它可以针对 UWP。 此行为是设计使然，因为其想法是 PCL 工具可帮助您避免意外使用在您需要运行的任何地方都不支持的功能。 相反，您只能从它所说的目标平台引用 PCL。

既然你明确提到了绰号，我们也来谈谈这个。 绰号 (TFM) 的设计是它代表整个表面积。 在我们的工具中有两个绰号：

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

将 TFM 视为识别托管的、内置的、表面区域的总体，而 TPM 代表底层操作系统，即操作系统提供的 API 集。

由于我们将 .NET Core 设计为可移植到多个平台，因此传统的 TFM 并没有多大意义。 这就是为什么有一个新概念，称为标准平台，以前称为世代。

这有帮助吗？

但是，它们共享相同的程序集和（向前）相同的 NuGet 包。

大多数程序集对于“netcore50”NuGet 目标（Windows UWP Store App）和“dnxcore50”NuGet 目标（ASP.NET v5 / ASP.NET Core 1.0）应用程序具有相同的 BINARY 实现 DLL。

但是，一些 NuGet 包（如许多 System.Net.* 库包）对“netcore50”目标与“dnxcore50”目标有不同的实现。 例如，带有“netcore50”的 System.Net.Http 库在下面使用 WinRT Windows.Web.Http 实现。 'dnxcore50' 实现使用其他东西（本机 WinHTTP）。

但是，像许多 System.Net.* 库包这样的一些 NuGet 包对“netcore50”目标与“dnxcore50”目标有不同的实现

是的，我应该提到这一点。 我看到的方式是，NuGet 包提供了一个容器，允许生产者为不同的执行环境提供不同的实现，而消费者不需要知道这一点。 从这个意义上说，NuGet 包是新的程序集。

感谢@terrajobst和@davidsh分享这个更深入的解释和参考问题，但是，我所说的“来自一个平台的1 个程序集不能被其他平台引用”有什么问题？

我看到的方式是，NuGet 包提供了一个容器，允许生产者为不同的执行环境提供不同的实现，而消费者不需要知道这一点。 从这个意义上说，NuGet 包是新的程序集。

这个概念实际上并不新鲜......人们已经创建了一个 Nuget 包，它只不过是对一堆其他包的引用——所谓的“元包”。 有几种方法可以使 PCL 在许多平台上工作。 许多流行库（如 Newtonsoft 的 Json.Net）使用的最著名的是Bait 和 Switch ，其中您有一个具有公共接口（API 表面）和每个特定平台的程序集（API 表面的实际实现）的 nuget它们甚至可以相互之间存在差异，并且在运行时，将选择该平台的正确程序集。 现在的不同之处在于，不是在单个容器 nuget 中“内部”有多个 nuget，所有这些 nuget 都应该位于同一平台或 1 个仅由开发使用并且将在运行时切换到特定的接口程序集，我们有一个混合的！ 1 个 nuget，它是一个容器，同时是链接到它的所有平台特定 nuget 的公共接口。

我认为我们说的是同一件事，我只是在第一名时表达得很糟糕：smile：

无论如何，回到 WF... 我认为人们希望将其移植到 WF 而不仅仅是“让它很酷”以在 linux 或 Nano Server 上运行它是臭名昭著的。 人们也希望在客户端上以轻量级的方式使用它。

同样，我认为社区中有足够多的人来实现这个端口......

PS：对于那些对分布式计算感兴趣的人（真正的不是离线客户故事），请查看我们的另一个项目Orleans ，这实际上是 .Net Core 上 WF 的一个很好的用例，它为当今的大型 Microsoft 服务提供了支持像 Skype、Halo5，我个人将其用作我的金融交易处理平台的核心技术，该平台以分布式方式处理数十亿笔交易......

@galvesribeiro

我所说的“来自一个平台的 1 个程序集不能被其他程序引用”有什么问题？

不是你的说法错了； 只是这也不对 :smile: 通常情况下，我不是那种喜欢吹毛求疵的人，但让我失望的是这部分：

换句话说，您不能将 .Net Core 程序集添加到 UWP 程序集。

我想避免给人的印象是 UWP 和 .NET Core 是不同的 .NET 平台，例如 .NET Framework 和 Silverlight。 我们专门设计了 .NET Core，您可以编写适用于所有平台的程序集。 例如， System.Collections.Immutable和几乎所有的 Roslyn 都是 .NET Core 程序集，它们也可以在 UWP 中正常工作。

换句话说：我们的目标是构建一个平台，使简单的基于 MSIL 的组件可以在所有基于 .NET Core 的平台上使用相同的二进制文件。 在不可能的情况下，例如，由于本机依赖关系或不同的实现，我们正在做 Paul Betts 雄辩地描述为Bait 和 Switch PCL的事情：可移植的表面积、每个平台的不同实现以及 NuGet 作为容器和选择器。

在 .NET Core 世界中， System库并不特别。 任何人都可以使用相同的技术来确保大多数消费者不必在他们的代码库中乱扔#if指令。

我认为我们说的是同一件事，我只是在第一名时表达得很糟糕：smile：

我认为我们创造了一个太容易让人感到困惑的世界——这显然包括我们 :smile: 这就是为什么我如此努力地准确了解 .NET Core 的构建方式以及我们试图解决的问题。

是的，你是对的。 印象最重要。

我希望有一天我们也可以在 UWP 上调用 .Net Core，这样就结束了……所以，我们仍然需要 system.xaml

虽然相关，但我认为System.Xaml是一个单独的组件，它本身就可以增加价值。 我已经提交了 dotnet/corefx#5766 来单独跟踪它。

谢谢迈克尔-夏令时

另外，我很好奇您对 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）SQL Server（后端）和SQL Server CE（移动设备）之间的同步框架实现。 这是 Sync Framework 版本 1。

这个应用程序是成功的。 我们编写了一个位于 SQL CE 之上的数据层，以及部署到服务器并部署到设备的 SQL Server。 它几乎耗尽了内存，但它起作用了。 现场工作人员能够在现场进行数据采集，并将数据同步回中央数据库。

当 Windows Phone 7 发布时，我们感到震惊，因为有一个关键问题：市场上所有的数据库都是非 SQL 数据库。 它们主要是用 LINQ 实现的。 这与我们的数据层不兼容，并且 Windows Phone 7 不存在 EF。因此，我们无法为 Windows Phone 7 构建一个偶尔离线的框架，即使我们已经能够为原始框架构建完整的解决方案视窗电话平台。

Silverlight 改变了游戏规则。 同样，我们遇到了一个完整的 SQL 数据库。 但是，微软没有为 Silverlight 或有问题的内联数据库实现同步框架。 因此，我们着手编写以微软同步框架为蓝本的自己的同步框架。 Microsoft 同步框架基于时间戳。 这就是我们在同步框架中实现的。 再一次，我们在 Silverlight 上取得了圆满成功。 现场工作人员能够将 Windows 平板电脑带到现场，捕获数据，然后将其同步回中央数据库。 问题是这永远无法用于手机。 Windows Phone 7 的数据库平台不存在。

正如我之前提到的，我们想用 WF 实现业务逻辑，但是 Silverlight 被放弃了，甚至没有人谈论将 WF 移植到 Silverlight 的可能性。

最后，我们到达了 UWP。 已经为 UWP 编写了 SQLite 的包装器，并且对包装器进行了一些修改，我已经能够使用 SQLite 扩展接口以允许我们再次使用完整的 SQL 数据库。 这意味着我们的数据层与它兼容。 我们的数据层和同步层现在可以在 .Net、Silverlight 和 UWP 上使用 SQL Server、SQLite 和另一个未命名的数据库平台。

今天是我第一次看到使用纯 Microsoft 技术发生的任何同步，这要归功于 Michael-DST。 基本上，我可以说 Azure 移动服务同步只是 Microsoft Sync Framework 的更名。 它有一些不同的 API 接口，但其基本原理与我们在大约 8 年前用于同步工作的原始 Windows Phone 同步框架相同。 我可以看到它甚至使用相同的两个时间戳字段来跟踪数据更改。 这些是作为 SQL Server 2008 中的核心功能引入 SQL Server 的。我们的同步框架的工作方式与 Microsoft 同步框架或多或少相同。

所以，为了回答迈克尔的问题，我将研究这项技术。 我会看看它是否可以取代我们的同步框架。 我很想把它扔掉，让别人来维护它。 看到他们提到它将支持 SQLite，这听起来很有希望，因为听起来我们将能够破解 SQLite 包装器以继续使用完整的 SQL 数据库，因此能够继续使用我们的数据层。 如果是这种情况，则意味着 5 年以上的同步框架代码将直接进入垃圾箱。

不管怎样，关键是，微软似乎再次承认分布式计算的重要性。 如果它很重要，应该将 WF 移植到 UWP。 UWP 是未来，因此它也是使用微软技术的分布式计算的未来。 分布式技术的未来需要WF。

虽然相关，但我认为 System.Xaml 是一个单独的组件，它本身就增加了价值。 我已经提交了 dotnet/corefx#5766 来单独跟踪它。

非常感谢@terrajobst！ 我不同意您在网上/推特上发布的所有内容，但我非常喜欢您如何促进开发人员/社区之间的对话和沟通，我将始终同意这一点。 :) 这对我个人来说真的很重要，因为从 MSFT 那里得到任何东西似乎都花了一年多的时间（是的，我意识到这不是承诺，但在这一点上任何事情都是有意义的）。

所以，为了回答迈克尔的问题，我将研究这项技术。

真棒@MelbourneDeveloper ，乐于助人！ 我觉得 Azure 对他们的团队确实有很好的把握。 与 VSO/VSTS 一起，他们真正听取了他们的开发人员的意见并获得了 *_lot *_done。 实际上，MSFT 中的每个组似乎都是这种情况_除了 UWP 组，这似乎并没有做太多事情，甚至似乎也不了解自己的技术（我们甚至不进入他们的定义“Xaml”）。

目前，我们将 WF 用于我们的几个核心服务，甚至现在我们正在进一步扩大我们的使用范围，因为我们在 Workflow 方面拥有丰富的经验，并且我们的业务逻辑具有如此直观、易于理解的格式。

就像@MelbourneDeveloper说的

不管怎样，关键是，微软似乎再次承认分布式计算的重要性。 如果它很重要，应该将 WF 移植到 UWP。 UWP 是未来，因此它也是使用微软技术的分布式计算的未来。 分布式技术的未来需要WF。

WF 一直是许多 .NET 开发人员低估的技术，因为他们当时可能没有看到它的价值（我过去没有，但现在我是 WF 的忠实粉丝，因为我知道它有多么强大是！）但在分布式计算时代，现在 WF 比以往任何时候都更加闪耀，我希望它最终能被移植。

我认为在这个话题上几乎没有分歧的余地。

当然有人认为，像 WF 这样的声明式可视化编程不如编写代码高效。 我什至倾向于同意。 但是，将 WF 作为工具包中的工具来完善可配置平台肯定是一件好事。 客户 *_DO *_ 希望看到可视化的工作流程，并且授权客户修改自己的工作流程当然是一件好事。

是时候完成这件事了！

我认为在这个话题上几乎没有分歧的余地。

哈哈@MelbourneDeveloper你见过软件开发人员吗？ 还是真的，人类？ ;p

我个人认为 WF 可视化设计器和现有工具对 XAML 造成了损害，因为为 MSBuild 工作流生成的过于冗长的文件在这方面确实给 Xaml 带来了坏名声。 这确实是开发人员与 Xaml（“臃肿文件”）相关联的原因，并帮助催生了“更简单”的 JSON 文件和“脚本化”构建文件。 更不用说，甚至创建一个项目来查看 Xaml 文件的整个神秘、困难和繁琐的过程（我什至无法在我的项目中完全工作）。

事实上，WF 的工作方式一直都是“正确的方式”。 它真正的毛病在于它的工具。

因此，如果设计器工具更友好一点（并且在以更有条理/分类的方式序列化文件方面做得更好），这将不是问题（或不是问题）。

我是 WF 所追求的道路的忠实拥护者，但它需要加强一点，并且它的工具得到解决和改进。 真的，归根结底，技术的好坏取决于它的支持工具——设计师等等。 工具/设计师越好，越容易获得/理解，技术越好，采用就越好。

我绝对希望看到 WF 变得更像 EF 并且可以在任何 .NET 场景中访问，并且改进了工具以实现这一点。

我的理解是，WF 的最初愿景之一是支持工作流的多种文件类型，而不仅仅是 XAML。 总的来说，除了这里和那里的一些怪癖之外，我还没有真正遇到过 XAML 的问题。 只是花了一段时间才把我的头缠住，并在必要时手动编辑它变得很舒服，我相信这对许多人来说是一个进入障碍。 因此，虽然我认为需要维护 XAML 以实现向后兼容性（至少在短期内），但我真的很想看到其他工作流文件类型开始开发（如 JSON）。 我可以在这方面看到一些很酷的社区贡献！ （有人用Whitespace编写的工作流程吗？：微笑：）

@Michael-DST 我完全同意你的看法。 最近，我和我的团队正在审查对 Workflow 的喜欢/不喜欢/希望，几乎我们希望看到的所有改进都围绕着设计师，而不一定是核心 WF 本身。 我认为微软在他们在 WF 中构建的内容方面做得非常出色，我认为一些改进和一些宣传我们可以看到它注入了新的活力。 我认为这是一个需要存在的工具，我从 WF 中获得了很多价值，我希望看到它持续很长时间。

我们的企业在 WF 上进行了大量投资，现在是我们业务的关键技术。 鉴于微软最近对开源和 .NET Core 的承诺，移植 WF 似乎是这项技术的最佳下一步。 我们需要这个！

工作流一直是一种工具，对我们作为组织内的开发人员有很多好处。 如果微软要统一其框架，那么在核心框架中加入 WF 将使我们的生活更轻松。

哈哈@MelbourneDeveloper你见过软件开发人员吗？ 还是真的，人类？ ;p

哈哈，我是软件开发人员。 人类对我来说无关紧要。

迈克尔-夏令时

我个人认为 WF 可视化设计器和现有工具对 XAML 造成了损害，因为为 MSBuild 工作流生成的过于冗长的文件在这方面确实给 Xaml 带来了坏名声。 这确实是开发人员与 Xaml（“臃肿的文件”）相关联的原因，并帮助催生了“更简单”的 JSON 文件和“脚本化”构建文件

你可能是对的。 但是，我个人认为这里过于强调 Xaml。 当我试用 WF 时（在意识到我们无法使用它之前，因为它在 Silverlight 上不存在），我构建了一个 WPF 应用程序。 该应用程序连接到我们的 WCF 服务，并将 WF 的 Xaml 存储在我们数据库的表中。 这就是我们如何实现WF的软编码。

但是，Xaml 完全使用 WPF WF 设计器工具进行操作。 用户从未见过 Xaml。 xaml 与用户无关。 可以把它想象成网页背后的 HTML 标记。 它可能非常复杂，但只要最终用户喜欢这个网页，这并不重要。 我认为，如果您将 Xaml 直接作为文本进行操作，那么您实际上并没有按照预期的方式使用 WF...

人类对我来说无关紧要。

好的。 二）

但是，Xaml 完全使用 WPF WF 设计器工具进行操作。 用户从未见过 Xaml。

正确的。 这正是 MSBuild 的工作方式，最终用户讨厌它，因为它生成的文件有多大（尤其是当您将它们与非常基本和线性的简单“脚本”文件进行比较时）。 我同意你的观点，这是一个工具/设计器问题，我还要说工具/设计器可以通过 WF 得到极大改进。

恰当的例子：博客文章和复制/粘贴代码（或者实际上，复制/粘贴_workflow_:smile:)。 有好几次我在网上搜索了 WF，并偶然发现了一篇不错的博客文章，其中显示了要执行的一些步骤以放入工作流组件（最有可能用于 MSBuild）。 好吧，为了做到这一点，我基本上必须复制一堆步骤。 通常在编码博客文章中，代码可用于简单的复制/粘贴。 WF不是这样。 你必须一步一步地做，直到它在你的机器上看起来和博客文章上的完全一样。 这显然非常乏味且容易出错（从 C# 的角度来看，这完全感觉像是退后一步）。

我们在使用 MSBuild 时遇到的另一个问题是文件的大小，不仅以字节为单位，而且在设计器本身中也存在：导航复杂的工作流真的很困难。 这似乎应该以非常全面（和直观）的方式来解释。

最后，我想总结一下文件大小的事情。 我不确定您是否知道从前的 WordML 和/或 MSFT Frontpage。 但它会创建世界上最臃肿的 HTML。 尽管用户通常不会将手放在生成的标记中，但他们确实喜欢将鼻子伸进去以感受它的“干净”程度。 他们首先看的是磁盘上的大小，然后是打开文件以查看其格式等。

同样，我同意这些文件的构建方式严格来说是工具/设计器的问题，但是开发人员确实会感到好奇，这也应该被考虑在内。 :)

是的。 所有的好点。 我认为需要对设计器进行清理，以免创建如此冗长的 Xaml。

谁真正有权决定是否将 WF 移植到 .Net Core 或 UWP？ 是否只是某个开发人员在某处编写代码，然后将该补丁提交给 .Net Core 代码库 repo 的管理员的情况？ 围绕这个的政治是什么？ 难道没有受微软影响的核心开发团队吗？ 是微软员工吗？ 我仍然没有真正了解整个设置。 我们需要说服谁？

实际上@MelbourneDeveloper只是通过参与这个线程，你正在帮助提出论点。 MS 有一个团队拥有 WF，目前是我的，但我们没有决定在 Core 上发布 WF。 我们必须提出商业案例。 这里的讨论可以帮助我做到这一点。

令人印象深刻的是人们如何在 2016 年开始支持这个线程 :)

此外，来自@terrajobst的 https://github.com/dotnet/corefx/issues/5766 这些天变得更加忙碌了 :)

@dmetzgar我希望你从这些讨论中获得尽可能多的反馈，这样你就有足够的案例来支持它。

我很确定如果 dotnet/WF 存储库被打开，如果它被添加到 corefx，人们肯定会非常快速地成长它。

实际上@MelbourneDeveloper只是通过参与这个线程，你正在帮助提出论点

这让我感到温暖和模糊。

仅供参考，dmetzgar - 我非常乐意记录我们的经验并提出一个有说服力的案例，以帮助建立港口商业案例的证据。

自 2000 年以来，我一直在深入研究 Microsoft 技术。我见证了与此线程相关的所有主要技术的发展和淡出。 虽然我沉浸在 Microsoft 技术中，但我仍然从客观的角度看待它，并认为 WF 是有助于开发商业/政府购买 .Net Core 和 Windows UWP 平台的关键技术之一。

没有什么比流程图更能让客户兴奋了！ 没有什么！

我还应该说，微软技术正处于大事的风口浪尖。

这么多年来，我见证了优秀技术的兴衰。 技术被淘汰的主要原因是设备格局的变化。 过去，策略是为每个设备系列构建一个平台。 这种方法本质上没有任何问题。 但是，这意味着在平台之间移植技术。 这很繁重，而且技术因平台突然变得难吃而被搁置的情况并不少见（咳嗽 - Silverlight）。

微软现在落后于 .Net Core 和 UWP。 虽然我认为这两个平台应该是同一个平台，但我仍然非常乐观地认为，当一个给定的技术被创建或维护时，它将在许多平台上工作。 Xamarin 进一步增强了我的乐观情绪。

确实，历史上第一次，我们可能会直截了当地盯着一系列可在非常广泛的 CPU 和操作环境中工作的技术。 如果微软努力推动这一点，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。 事实上，我在当前项目中使用的控制台应用程序中使用了相同的范例（即 WPF 式的基于 Xaml 的开发）。 诚然，它没有像我建议的那样使用数据绑定（还），但是这些很容易产生，正如 OmniXaml/Perspex 向我们展示的那样。 ：太阳镜：

@Michael-DST 我宁愿避免太多的集成。 WF 应该是一个独立的 NuGet 包。 将 WF 和 EF 集成在一起应该是一个单独的项目。 开始组合太多的东西，你最终可能会选择Oslo 。

我同意@dmetzgar :+1:

EF 是存储/持久性提供程序。 它应该是一个差异 NuGet 包并在运行时注入。 WF 必须只提供一组接口，仅此而已。

我们在 Microsoft Orleans 上使用 Storage Providers 做得很好。

@dmetzgar （和@galvesribeiro）同意了。 我并不是在建议一个必要的集成，而是一个可能的用例/价值主张。 （见：头脑风暴。：微笑：）

您集成 EF 和 WF 的用例是什么？ 你能给我举个例子吗？ 这是为了坚持吗？

我想插话这个！ 同样，这与我公司的经验有关。 最终，我们希望将 EF 用于内联数据库中的数据持久性，例如用于偶尔连接的应用程序的 SQLite。 最终，UWP/.Net Core 将使 EF、SQLite、Azure 移动服务和 WF 协调工作。 如果我解释了为什么我们希望发生这种情况，我会重复自己，但我可以解释为什么 EF 和 WF 可以很好地协同工作。 虽然，我们在 EF 中发现了一个限制，它在过去阻止了我们的发展——这也是我们必须创建自己的 ORM 的另一个原因。

我们有一个系统，其中数据访问会触发“BeforeLoad”、“BeforeSave”等事件。我们在这些事件中留下挂钩，以便在保存给定的记录类型时，我们可以将自定义业务逻辑放入其中。 目前，我们通过链接到自定义业务逻辑 DLL 来实现这一点。 每个客户都有自己的一组自定义事件。 我们还实现了对 WF 的调用。 因此，例如在 BeforeSave 事件中，我们可以通过调用 WF 来验证必填字段来进行一些验证。 通过这种方式，验证逻辑是针对给定客户进行软编码的。 从长远来看，我们不得不为此放弃 WF，因为它从未在 Silverlight 上实现过，但如果有它作为一个选项，那就太好了。

无论如何，我觉得这对于任何应用程序来说都是一个相当普遍的要求。 一般来说，您总是希望在数据层之上有一个层，用于验证进入数据库的数据或执行一般业务逻辑。 例如，我们有一些客户的业务逻辑，当特定类型的记录添加到数据库时发送电子邮件。 这可以在 WF 中完成。 在 EF 和 WF 协调工作的情况下实施这样的事情会很棒。

唉，即使在 .Net 上，我也从来没有找到用 EF 做到这一点的方法。 我发现的问题是 EF 不会告诉您何时将保存给定类型的记录。 因此，例如，如果您创建一个新的“任务”对象并使用 EF 将其持久保存到数据库中，则 EF 不会触发类似“RecordInserted”的事件“。这将允许我们在数据访问中构建挂钩，以便可以插入自定义业务。因此，这是我们从未使用 EF 的原因之一。很遗憾，因为构建我们自己的 ORM 需要数年时间来完善。

谈论 NodeJS 的“商业案例”：NodeJS如何在 3 个简单图表中主导 .NET

耐心等待那个 GitHub repo。 只是刚刚意识到 WF 没有被移植到 .NET Core，这几乎扼杀了它对我们产品的生存能力。 遗憾的是，我们喜欢 ASP.NET Core 和整个跨平台、精简、模块化的 .NET Core 理念的变化，但我们需要 WF，因为它是我们整个产品的基础。

我想我真的不关心这是 WWF 还是其他一些支持良好的工作流引擎，但我确实认为出于可扩展性的目的，某种工作流可能是绝对巨大的。

+1

我们使用动态生成（基于导入的外部规则）并将工作流加载为 WCF 服务。 如果我们可以在 .net core 中使用这样的模型，那就太棒了！
顺便说一句-导入完整的.Net程序集有什么问题？ 如果它主要是 IL 代码，为什么它不在 .net 核心中运行？

+1

@dmetzgar看到https://github.com/dmetzgar/corewf 真是令人兴奋！ 从自述文件中，我惊讶地发现 WF 团队的一个移植并没有获得太大的吸引力。 尤其是考虑到最近的 Powershell 端口具有将仅限于完整框架的 Powershell 工作流——Linux 和 Mac 显然不是主要目标，但我认为 Nano 服务器对 Powershell 非常重要。 那里还提到您正在探索 XAML 的替代方案，其中包括其他 Xaml 实现，例如 Portable.Xaml 已经支持与 CoreCLR 兼容的 Profile 259？

@watertree Portable.Xaml 和到目前为止我看到的其他支持 .NET Core 的 XAML 实现都缺少一个功能。 他们没有实现 x:Class="" 属性。 这对 WPF 来说是不必要的，但对 WF 来说至关重要。 XAML 工作流通常具有

PowerShell Workflow 有一种在脚本中定义工作流的非常好的方法。 它比用 XAML 或 C# 编写相同的东西要干净得多。 但是，PSWF 在后台将该脚本转换为 XAML 文件。 为了让 PSWF 在 Nano 上工作，他们必须替换现有的管道和 WF 运行时，以便它不使用 XAML。 客户真的没有足够的压力在 Nano 上安装 PSWF。

关于 XAML 的替代方案，我对此有很多意见。 我对 XAML 的问题是它嵌入在 WF 中。 随着 .NET 3.5 中发布的旧 WF，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 进行编程时，这一切都发生了变化，它除了 XAML 之外还有一个非常好的声明性 C# API。 没有视觉设计器（只有一个比 XF 版本晚得多的预览器）。 令人惊讶的是，我更喜欢使用他们的 XAML 方言而不是 C# 代码！ 他们在这方面做得非常好，而且你没有大量的设计师元数据污染了标记的含义。 像 Prism.Forms 这样的支持框架也有助于将天平向 XAML 倾斜，因为它有助于编写没有代码隐藏的代码非常容易。

所以我不认为 XAML 本身是问题，而是设计为首先支持设计人员的方言——XF 对我来说是非常有说服力的证明。

关于该主题的任何更新？

那么 CoreWF 还活着并且存在于https://github.com/dmetzgar/corewf

需要观察 DynamicActivity 现在是否可以与添加到核心和 .net 标准 2.0 的新组合 API 一起移植。

如果我们收到 WF 团队的消息，那就太好了。

关于这个话题有很多有趣和有用的评论。 就我而言，我相信将 WF 运行时和事件跟踪（即没有 XAML、事务或 WCF 位）移植到 .NET Core 是有价值的，我很高兴这（某种程度上）完成了。

我同意 WF.Core 需要正式存在。 如果有能力创建一种更灵活的方式来定义适用于开发人员的工作流程，我相信这将是最好的方法。 我同意如果 MS 说他们不打算移植 System.XAML，XAML 是一个难以破解的问题，但我真的希望在我的 .NET Core Web API 项目中看到 WF.Core。

我认为这里房间里的巨大大象是没有足够的牵引力让这个项目起步，因为 MS 和其他人一直对有关 WF 的任何信息守口如瓶。 当然，MSDN 上有一些示例，但是以书籍或其他可靠（经过审查的）材料的形式提供的信息非常少。

我绝对愿意花时间帮助实现这一目标。

因此，仍在开发中的 OmniXAMLv2（它位于 github 存储库的一个分支上）应该支持 x:Class 属性（https://github.com/SuperJMN/OmniXAML/issues/12）。 也许我们可以将它用于（核心）WF？

@ewinnington感谢您指出这一点！
这绝对是其中很大一部分。 此外，.NET Standard 2.0 有一组 WF 使用的 System.ComponentModel 类型。 System.Transactions 已经在 corefx 中。 唯一缺少的是 WCF ServiceHost。

WCF ServiceHost 可以等待恕我直言。 托管模型应该是不可知的，就像我认为的 .Net Core/Asp.Net 世界中的其他任何东西一样......

@galvesribeiro我同意这一点，因为 WF 可以通过许多其他方式在 .NET Core 世界中工作，包括 Web API。

对。 但是，我同意@dmetzgar的观点，即今天有很多客户使用 WCF，因此支持它是必须的，但同样，它可能会延迟......

事实上托管和“设计语言”应该从核心运行时中抽象出来......

我们将 WCF 与 WF 一起使用，但如果 WF 在 Core 中，我们会很乐意切换到 WebAPI 之类的东西。 事实上，无论如何，我们一直在推进并从 WCF 转向 RESTful 替代方案。 我们从 Workflow 中获得了大量价值，它是我最喜欢的 .NET 技术之一！

我还认为核心上的 WF 不必依赖于 xaml 或 wcf，只要拥有 wf 引擎和对象模型就会非常有价值。 然后，您将在 asp.net 核心上将其作为中间件运行，尤其是使用即将用于 kestrel 的新管道/非 http 工作。

+1 用于在 Core 中拥有和支持 WF 引擎和对象模型。 我们也可以解决 XAML 和 WCF。

XAML 很酷 - 它允许您进行动态配置 - 在一个项目中，我们从文件加载 xaml 工作流，它们表示为 WCF 端点。 这些 XAML 文件是从可用服务的注册表中自动生成的。 所以 wcf-services 得到了端点：
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
在.Net核心中有这样的功能会很好:)
哦...我以前在这里写过... :)))

是的，因为我已经对这片土地更加熟悉了，WF 中的 Xaml 支持本身并不那么重要，而是真正让 System.Xaml 移植过来才是重要的部分。 因为这在另一个问题中很明显——我很高兴地说它很受欢迎（但不要让这阻止你投票，@freerider7777！:smile:)——问题，我支持将 WF 作为依赖项尽可能免费以确保它进入 .NET Core。 👍

@Mike-EEE 我很久以前就在那里投票了！！ :)

看到可以通过代码创建工作流，使用类似于 EF Core 的 Fluent API 是否是实现 WF Core 的有效选择？ 那么运行时的序列化/反序列化可以在之后构建并且更容易实现吗？

FluentAPIs...现在很热。 或者至少，自从他们被接受以来。 😄

FluentAPIs，Builder Pattern，它们本质上是一样的。 提供一种可链接且易于使用的基于代码的方式，我相信这应该是这背后的坚实原则。

没有设计师，这一切都是无用的。 当然，我们可以自己编写所有东西——所有的逻辑、所有的链等等（不管有没有 fluent）。 但是 WF 中最酷的是 - 您可以直观地看到处理流程。 它是经理（和其他“利益相关者”）和开发人员之间的纽带！ 管理人员不会理解代码，但是这些高级图表是所有人都可以理解的。 使用 WF，如果它们是分开的，则不需要单独的图表（visio 或其他） - 它们通常与实际代码不同步:)

@freerider7777 WF 定义序列化不限于 xaml（参见@dmetzgar的 https://github.com/dmetzgar/corewf）。 它也可以为 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 对于在代码中编写工作流会很有趣（沿着这些思路查看 @knat 的 https://github.com/knat/Metah），但我同意@ freerider7777 的观点，即使用图表与您的管理层和 BA 进行沟通的能力从生产中实际使用的内容生成是一个很大的优势。 @helmsb在这方面有很多经验（查看 http://dotnetrocks.com/?show=1236）。

新设计师必须是 Web 应用程序。 以 WPF 或 UWP 为目标会限制受众。 如果 OmniXAML 成功，人们可以使用他们现在使用的相同工具（VS 或重新托管的解决方案）创建/编辑工作流。 问题在于，由于当前设计器内置于 .NET Framework 中，因此任何功能或修复都必须等待 .NET Framework 发布。 它足以开始，但不是一个长期的解决方案。 @erikcai8与网页设计师进行了一些实验，类似于 nodered。 我看看能不能说服他分享。

对于工作流设计器前端，可以在 github 上进行第一次尝试： https ://github.com/gary-b/WF4JSDesigner，您可以实时使用它http://gary-b.github.io/WF4JSDesigner/

这就是它的样子：

@ewinnington ：很高兴看到 Web 工作流设计器 POC。 我还构建了另一个，如下图所示。

啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊！ 这是 WF POC-OFF ！！！ 🎉

嘿嘿。 嘿@erikcai8导出到 Xaml 在哪里？？？ 哈哈。 只是翻转你的悲伤。 排序。 👼

这两项努力看起来都很棒。 很高兴看到他们俩。 现在这似乎很明显，但是在原始 WF 中拥有一个基于 Web 的视觉设计师该有多棒？ 一切都已锁定并加载，准备就绪，您只需访问一个 URL。 我认为这对品牌推广和采用确实有帮助。 不幸的是，似乎每个人都使用了基于 TFS 的编辑器，该编辑器非常难以设置并导致 Xaml 非常冗长。 对于必须处理它的典型开发人员来说，这是一个糟糕的体验，并且给与体验有关的任何事情（WF 或 Xaml）一个坏名声。

OTOH，这似乎是一个很好的方法。 让复兴开始吧！

@Mike-EEE 我的 E2E 实验增强了工作流核心引擎以本地加载 JSON 工作流，因此不需要 XAML 格式。 XAML 工作流一旦加载了 JSON 工作流，就可以从 Workflow Engine 中导出。

这就是重点。 我们不应该像在 WF 4.5 中那样将运行时及其对象模型与设计器和序列化格式联系起来……

@galvesribeiro 明白了这一点。 该实验假设 JSON 格式作为 Workflow Core 的另一个选项被支持。 如上所述，XAML 对最新的 Web 技术还不友好。

我们喜欢 WF，请将其移植到 .NetCore。

我们需要一个基于 Web 的工作流设计器。 对 .NET 核心的支持，用于运行工作流将是双倍的棒。 走走

Daniel Gerlag 正在开发一个非常好的轻量级核心兼容工作流引擎：

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

丹尼尔在很短的时间内取得了长足的进步。 如果您发现它的优点，我强烈建议您查看并参与该项目。

有了这些兴趣，为什么不从头开始构建一个与 Net Core 兼容的引擎呢？

@ccpony因为您现在可以在 dot net core 上使用 CoreWF -> https://github.com/dmetzgar/corewf 。 中心组件被移植并工作。 有些事情正在等待 .net 标准 2.0。

@ewinnington感谢您的回复，但我没有得到这个。 WF 并不是一款成功的 MS 产品，而且多年来 MS 也没有做任何改进。 社区充满了尝试和失败的实现的见证。 尚未在企业中广泛采用。 它笨重，功能过多，难以学习并且（仍然）有问题。 它的界面广受诟病。 它未能成为最终用户友好的技术。 它的内部本质上是一个不能轻易增强的黑匣子。 除了简单的工作流程之外，它很慢。 测试非常困难。 它基于旧技术（WCF、XAML）。 自从 Ron Jacobs 生病后，WF 一直萎靡不振，在 MS 也没有朋友。

在我的估计中，WF 试图成为所有人的一切，而事实上，对任何人来说，WF 都变得微不足道。 微软几乎放弃了它。 为什么我们希望复活这样的东西？ 如果有任何重要的技术需要重新思考和重写，这就是它。

看看 Daniel Gerlag 刚刚起步的项目。 它是新的和不成熟的。 但它采用了一种易于增强的现代工作流程方法。 如果这里的每个人都不再试图改造一个复杂的、过时的、坦率地说是过度设计的项目，而是把他们的努力投入到新的、更好的东西上，那么我们就有机会在一个有价值的地方结束——逐步建设世界级的工作流引擎，而不是试图从一开始就重写一个庞然大物。 老实说，我很佩服这里所有想要从事非常有价值的工作的人——最终，创建一个设计精良、功能强大、轻量级、东方学习、跨平台工作流（状态机？）工具。 但是，我很遗憾地说，如果你们都继续走这条路，那么你们所有的努力都将化为乌有。 MHO。

@ccpony感谢您分享您的意见。 您介意详细说明您所指的错误吗？ 如果我们可以做些什么来解决 .NET Framework 中的问题，我很乐意知道。

@dmetzgar感谢您的回复，达斯汀。 在尝试开发WF应用程序期间，我确实遇到了错误。 不仅是意外行为，而且有好几次复杂的 WF 会“崩溃”并在 XAML UI 中生成难以在 XAML 代码中修复的错误。 我从来没有真正对WF技术产生过很大的信心。 真的，我感觉自己就像在和一只 800 磅的大猩猩搏斗——每向前迈出一步，我最终就会被后退两步。

我知道这不是您在请求我详细说明错误时所要寻找的。 坦率地说，我可以解决这些错误。 但由于我在上一篇文章中提到的所有其他原因，我最终放弃了 WF。

你是这项工作的带头人，我为此向你致敬。 但是，当试图改造一项复杂的技术会适得其反时，肯定会有一点。 跟随这整个线程，我不禁觉得进展非常缓慢——如果有的话——最终这一切都不会显示任何东西。 我发现旧的工作流程不太可能移植到这里产生的任何东西。 这个帖子里的人都在谈论基于客户端的工作流（即 JavaScript）、REST 兼容性、减少依赖关系、跨平台等。例如，XAML 是旧 WF 技术的重要组成部分，将 WF 移植到核心有什么用XAML 不会是它的一部分吗？

所以达斯汀，我需要问你这个问题：这个项目已经进行了 18 个月，但似乎并没有就正在取得真正的进展达成共识。 我尊重你的努力，我可以看到你是一个伟大的程序员 - 但这是我的问题：获得所有这些能量和热情并创造新的东西不是更有意义吗？

@ccpony本主题中的讨论是支持 WF .Net 标准，而不是相反。

只是好奇...您是否曾经使用或看到过 Sharepoint 部署的实际应用？ 如果你这样做了，你会发现它非常依赖于 WF。 您是否见过 BizTalk 部署？ 相同。

这些是企业世界中主要的 MSFT 产品，所以是的，有些用户关心 WF 并且有使用它。 这不是你说的被遗弃/放弃的项目。

话虽如此，如果您查看@dmetzgar 存储库，您会发现有些东西是相似的或继承了旧版 WF 的某些行为，您还会看到它被重新设计为轻量级。 持久化是解耦的，人们可以轻松地创建新的。 设计师是解耦的，人们已经创建了多个测试。

我理解你对想要新事物的沮丧。 相信我，我也希望这种情况发生。 但是你必须了解@dmetzgar和他的团队。 这不是优先事项，因为 95% 的客户是旧 WF 的用户，正如我提到的，它基本上在 BizTalk 和 Sharepoint 上运行。 我在非常高的 tps 环境（银行和金融交易）中使用了旧的 WF 多年，它对我很有帮助。

我的新技术正在使用 .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）的未来有任何关系。 微软不会用@dmetzgar的代码改造 SharePoint。 抱歉，SharePoint 的未来与这里所做的努力无关。

因此，真正重要的是是否会出现一个好的工作流引擎。 我的观点是，试图将 WF 这样的庞然大物推向未来并不是最好的做法。 最好从头开始构建。

@ccpony我想提醒你，这里有很多人都在积极寻求看到这个项目的实现，有些人实际上正在投入时间来实现它。 虽然您个人可能将 WF 视为 Microsoft 的失败产品，但它仍然是 .NET 的一部分，并且在这里不仅被我们使用。

这个帖子应该是建设性的批评和投入，以使过渡成为现实，而不是对他人或产品本身的抨击。 尽管您的观点受到尊重，但请注意，它们是您的观点，其他人可能对 WF 对他们的重要性有不同的看法。

我们积极欢迎您就改进产品的方法以及如何最好地帮助那些积极参与尝试的人提供意见。

谢谢=^_^=

@ccpony

（当您建议 BizTalk 以某种方式依赖 WF 时，我不知道您的意思。事实并非如此。）

对不起，我表达得很糟糕（我在手机上）。 我有两个一起使用的应用程序，我知道很多其他的也可以。

没有理由相信 MS 会增强 WF 在 SharePoint 中的功能。

我不是说它会。 我是说与 WF Today 合作的团队完全专注于支持 Sharepoint 部署。 即使是最新版本的 Sharepoint 也使用相同/当前版本的 WF。

我不明白您为什么认为@dmetzgar的努力与 SharePoint（或 BizTalk）的未来有任何关系。

我并不是说它会影响 Sharepoint 的未来。 如果我理解正确的话，我是说团队正忙于支持 Sharepoint。 （如果我错了， @dmetzgar可以纠正我）

微软不会用@dmetzgar的代码改造 SharePoint。 抱歉，SharePoint 的未来与这里所做的努力无关

MS是否会在Sharepoint vNext上使用WF vNext，只有他们才能确定。 同样，问题是WF团队无法同时处理这两个问题。

因此，真正重要的是是否会出现一个好的工作流引擎。 我的观点是，试图将 WF 这样的庞然大物推向未来并不是最好的做法。 最好从头开始构建。

没有人按原样移植它。 @dmetzgar的 repo 证明它正在从头开始重新设计。 同样，问题是团队必须处理这两件事的积压和带宽。 这就是为什么我建议在 dotnet 基础上“打开”它，并在 WF 团队的指导和策划下使其成为一项主要的社区驱动工作，因此我们试图尽可能少地影响他们的日程安排。

同样，就像@InariTheFox和我自己提到的那样，这个线程是对端口的推动，这不一定意味着将具有所有这些功能的旧版本强制推送到新版本。 但是，重要的是要了解人们在当前基于 WF 的产品上投入了大量精力（和金钱），因此@dmetzgar担心尽可能多地与旧工作流程兼容，这确实值得关注。

行。 我看到了这里的激情。 实际上，如果 WF 有一个很好的替代品来解决我之前提到的所有问题，我们就不会进行这种对话了。 郑重声明，我们中的很多人已经离开了 WF，并一直在等待下一件事情的发生。 它从来没有。 据我所知，目前没有被广泛认可的、受支持的、功能性的、基于 .Net 的工作流/状态机解决方案。 请理解：我坚持我的观点，即从微软的角度来看，WF 是一种死技术。

但是，话虽如此，请帮助我理解。 @dmetzgar的回购是否按原样工作？ 如何用它编写工作流程？ 我没有看到任何示例代码，也没有任何文档。 我将如何进行？

我认为有许多产品/公司将 WF 作为其产品战略的核心，这不仅仅是支持模式中的 Sharepoint 依赖：在我目前的公司，我们开发了一个以 WF 为核心技术的自动化平台（我知道该市场的其他 2 个竞争对手也在其产品中使用 WF）； 我也和在保险科技中使用它的人讨论过。所以我坚信 WF 的观众仍然在那里。

话虽如此，.net 核心似乎是微软的重点领域之一，许多技术创新将在下一个时期投入其中； 我认为没有WF作为其中的一部分将是一个巨大的损失。

从我的角度来看，实现它的正确途径是使 WF 核心独立于 xaml，并使其更容易（反）序列化其他格式的工作流（例如：json）。 这也将简化在 Web 浏览器中托管的工作流设计器等场景的实施。 通过https://github.com/dmetzgar/corewf存储库，我们有了一个起点。

对于那些对 WF 当前状态的概述感兴趣的人（我认为 MS 没有放弃它），不久前我将有关 WF 的可用信息集中在一个帖子和一个演示文稿中http://andreioros.com/blog /windows-workflow-foundation-rehosted-designer/ ; 我仍然保持最新状态

我们和我们的客户都依赖 WF，我们非常希望看到它在客户端和服务器上运行。 一个没有 XAML 和其他依赖项的 WF，设计为轻量级，但具有现有 WF 的表现力，同时也受到社区的 MS 支持，这确实是一个令人兴奋和有价值的产品。

再一次，请允许我问：如何使用@dmetzgar的端口来运行它？ 目前的状态是什么？

我不知道@dmetzgar的端口实际上可以在其当前版本中使用...

来自@ewinnington ，上面：

“因为您现在可以在 dot net core 上使用 CoreWF -> https://github.com/dmetzgar/corewf 。中心组件已移植并可以工作。一些事情正在等待 .net 标准 2.0。”

在这种情况下，我也想听听它的用途......

是的，它是核心功能的准系统。 您可以运行基于代码的工作流。 netstandard2.0中缺少的功能主要与事务支持有关。

这也是我仍然建议将其开放并让人们为中心位置做出贡献的原因之一。 让它传播将使未来某一天在最终产品中更难实现。

通过测试和对现代 Roslyn 功能的支持作为核心的一部分，投票支持 WF 重写。 我很想看看无服务器和容器如何影响架构，尤其是在不同的域上下文和业务流程中规则集的部署和扩展。 与所见即所得的设计师相比，我个人更喜欢简洁的 DSL。 我个人确实很喜欢这位设计师，但几乎一直觉得它很古怪。 WF 本身具有非常扎实的潜力，但需要深厚的专业知识。 事实上，包括 WF 管理器和 SQL Server 中的持久流在内的大规模 WF 部署需要 MS 咨询和错误修复。 尽管过去几年我现在支持 Java 团队，但在专注于 MS 技术超过 15 年之后，我喜欢关注 .NET。 我正在阅读 Nick Harrison 的“与 Roslyn 一起代码生成”（我与他或这本书没有任何关系），并且想知道再次接触业务规则引擎空间，这让我再次想知道 WF 的命运......老实说，我认为 Azure Functions 与 MS 资源竞争，以及他们在任何地方支持对 WF 进行深度投资的一般企业意愿。 很明显，他们希望您使用它……所以，也许解决方案是转而专注于 OpenWhisk 的开源 .NET 版本。 但是，在容器化的世界中，......我可以将 OpenWhisk 用作服务。 所以...

PS 简单地支持导入外部化表达式的稳健方法可能会解决 60% 的认为他们可能需要 WF 的应用程序需求。 是 CSharpScript 吗？ 使用直接 API 导入基本业务规则配置的简单方法将大有帮助（各种持久性、检索和缓存选项）。 借助一次性虚拟基础架构（基础架构、容器和平台即服务的自动化），WF vNext 可以专注于将版本更改部署为服务，而不是尝试将它们内联到应用程序中（即，WF vNext 的更好解决方案在 WCF 上）

我对这次谈话非常感兴趣。 我的团队也一直在处理 XAML 的挫败感。 我们的困境是我们正在创建自己的 UI 设计器，以允许我们的客户创建自己的工作流，而无需 Visual Studio 或重新托管的设计器。 我们需要将 XAML 块保存到可重用位中的能力，这样客户就不必总是重写这些位（将它们视为工作流函数）。 这要求我们知道如何将 XAML 块合并在一起，我们了解到这非常令人沮丧。 我们正在考虑创建一个抽象，在该抽象中我们仅依赖于各种活动及其链接的数据库模型，而完全忽略 XAML。 然后，我们将在每次执行工作流时以编程方式创建活动等。 在研究这种方法时，我偶然发现了这个线程。 保持对话，我很想听听其他人的意见。

@erikcai8工作流设计师是一个非常好的主意。 我可以得到你的工作流程设计器的来源吗？

我已经在我的自动化项目中使用 WF 超过 5 年了，这太棒了。 我希望很多开发人员会支持这个请求并实现它。 自从我开始工作以来，我一直使用 .Net 技术，并且希望继续这样做。 但是，能够支持跨平台是公司的方向，因此我非常期待在.Net Core中看到完整的WF。

随着网络标准 2.0 的到来，如果能对 corewf 的问题进行更新，那就太好了：

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

添加的 API 如何解除对移植过程的阻碍，我们可以做些什么来提供帮助？

我认为不管netstandard2.0是什么，这个端口应该照原样运行，恕我直言......通过重写......使其对外部任务调度程序、异步/等待/任务和其他现代东西友好。 尽管我很喜欢 WF，但当前版本已经过时了……

我的意思是没有任何不尊重。 诚实地。 但我是这里唯一一个明白这个项目没有希望的人吗？ 我们迫切需要一个好的 .Net 工作流引擎，但事实并非如此。 我们不应该在这里改变谈话吗？

我对一个新的、更好的工作流引擎持开放态度。 最重要的是，我们需要 .NET Core 中的一个。 我们已经使用 WF 多年了，它对我们来说效果非常好，所以如果是替代方案，总比没有好。

@kalokamgit ，源代码可在参考源中找到。 它在两个程序集中：
System.Activities.Presentation和System.Activities.Core.Presentation 。

不幸的是，发布参考源的工具只做 C# 代码。 它不包括任何 XAML 文件。 您可以向[email protected]提供有关此问题的反馈和/或对用户语音问题进行投票。

该代码位于 .NET Framework 中，因此您可以在自己的工具中自由使用它。 一些示例是@orosandrei的项目和此处的示例项目。

我的意思是没有任何不尊重。 诚实地。 但我是这里唯一一个明白这个项目没有希望的人吗？ 我们迫切需要一个好的 .Net 工作流引擎，但事实并非如此。 我们不应该在这里改变谈话吗？

好吧，如果你_真的_没有不尊重的意思。 :) 我很好奇大家对Flow的想法是什么？ 当我想到“现代”的“工作流程”时，这就是我的想法……也是 Azure 近来大力兜售的东西。

我真的是认真的:)

Guess Flow 是 Zapier 增长的答案吗？ 我看不出它将如何以任何方式取代世界自然基金会。

WF 是停产了还是我在这里遗漏了什么？ 那将是非常可悲的！

我在哪里可以为 WF 投票？

这个问题的顶帖是最好的地方。

我想知道@rjacobs （WF 大师）对此事有何看法。

你是说@ronljacobs 吗？

@dmetzgar可能是的。 他是真正的WF英雄

这是我的答案
https://github.com/danielgerlag/workflow-core

罗恩·雅各布斯（Ron Jacobs）是多年来全心全意投入 WF 的人。 他感染了 Dercum 病并于 2013 年离开了微软。 （这里）当他离开时，WF 就是这样。 再一次，希望是最后一次：WF 已死。

再一次——我会鼓励每个人和任何人看看上面的 Dan Gerlag 的项目。 它雄辩，构思精美，并在 Core 上运行。 任何希望为可行的工作流程解决方案做出贡献的人都需要查看它。

另请查看Durable Task Framework 。 这将添加到 Azure Functions，请参阅Durable Functions 。

@dmetzgar这个框架在尿布中被认为是 WF 的替代品。 我认为微软提出这种事情并不严重。 与其重新发明轮子，将 WF 迁移到 .NET Core 并在所有 Microsoft 项目中重用它作为基础，这不是更好吗？ 很抱歉我的措辞严厉，但我认为它们代表了许多对WF目前的情况感到非常失望的人的情绪。

@Suriman ，公平点

我更新了corewf repo上的自述文件，以便更好地描述将 WF 移植到 .NET Core 所涉及的内容。 你介意看看吗？

@dmetzgar感谢您的澄清并清楚地展示了将 WF 移植到 .NET Core 的方式。 我从你所说的了解到，微软不会做所有这些迁移工作，它希望社区做，是吗？ 这个问题的答案是关键，根据回应，企业可以选择替代路线，或者做微软应该做的工作。

Microsoft 不会将 WF 正式移植到 .NET Core。 我和我的团队将在业余时间开展这项工作，但不是以官方身份或任何预定发布。 列出的所有问题都可以解决。 对于我们所做的一些项目，这种端口是有用途的。 这将是我们大部分贡献的来源。 我认为现在关闭这个问题并将人们指向corewf 存储库以关注最新工作是公平的。

你好，
从 Future 里程碑到 2.1 的变化，是否意味着微软会将 WF 移植到 .NET Core？

已关闭问题的里程碑更改仅反映问题已关闭的版本。
这个特定问题基本上以“无法修复”的形式关闭 - 请参阅上面的解释https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz真可惜。 有那么一瞬间，我们好像中了彩票。

我们有一个基于 WF 的解决方案。 我们正在使用 WF 创建活动步骤，此工作流将交付给所有订阅者，他们将根据 WF 处理操作。 我们非常喜欢WF。 支持跨平台是我们公司的方向。 我们对 .NET CORE 上的 WF 非常感兴趣。

CoreWF是部分移植到 .net 核心的 Workflow Foundation 的代码。 您现在可以跨平台使用 Workflow 基础。 此时您不能使用基于 XAML 的工作流。

我有一个分支，我致力于在Net Standard 2.0 之上添加对 Dynamic Activity 的支持。

XAML 解析过程要求 Microsoft 充分打开 System.XAML，以便我们能够正确解析文件。

您可以在此处跟踪该问题的进展： https ://github.com/dmetzgar/corewf/issues/6 并在我多次尝试通知此问题时：
在 CoreFX 上
在参考源上

.Net 兼容包在 System.XAML 前面有一个“可能”。 但没有消息过滤它的包含。 问题Ship .Net Framework Compatibility Pack当前列出了 System.XAML 的“无计划”。

也许客户采用史诗的问题也可以用来讲述添加 Workflow Foundation（和 System.Xaml）如何让您的公司发布产品的故事。

我的公司也投资于 WF：我们为能源公司提供产品，我们的客户使用 Workflow Foundation 创建工作流。

感谢你的回复。
非常有用，非常感谢。

2017 年 11 月 2 日 18:22，“Eric Winnington” [email protected]写道：

有 CoreWF https://github.com/dmetzgar/corewf这是代码
Workflow Foundation 部分移植到 .net 核心。 您可以使用工作流
现在的基础跨平台。 您不能使用基于 XAML 的工作流
此时。

我有一个分支，我一直致力于添加对动态活动的支持
在 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 前面有一个“可能”。 但没有消息过滤关于它的
包容。 问题 Ship .Net Framework Compatibility Pack
https://github.com/dotnet/corefx/issues/24909目前列出“没有
计划”用于 System.XAML。

也许也是客户采用史诗的问题
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 逻辑应用程序或其他为工作流收取溢价的外部供应商。 尽管像 Netflix Conductor 这样的非 .NET WF 产品很少，但我们希望拥有一款纯 .NET 核心版本。 您可以在https://github.com/Netflix/conductor从 Netflix 指挥那里获取线索，然后从那里开始构建。 这对于无法访问无法使用逻辑应用程序的 Azure Stack 的私有云开发人员来说将是一个巨大的福音。

为了提高认识，我想我会在这里发帖。 我正在阅读以下文档，它让我想到了这个线程：
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

看起来 Dynamics365 和 PowerApps 正在融合思维，现在正在以某种方式使用 Windows Workflow 来处理其工作流。 这当然是全 Windows 的，但在跨平台等的新时代……这会持续多久？

我不知道我应该使用什么。 我希望 MSFT 能做到这一点。 带来清晰的微软。

@VenkateshSrini ，您还应该查看 Cadence： https ://github.com/uber/cadence
该模型更像亚马逊的 SWF，但它是开源的。 虽然还没有 .NET 客户端。

寻找一个。 网核版

不会发生。

来自：VenkateshSrini [email protected]
发送：2018 年 9 月 26 日星期三 12:30 AM
致：dotnet/corefx [email protected]
抄送：Jeffrey Michelson [email protected] ； 提及提及@noreply.github.com
主题：回复：[dotnet/corefx] 将工作流基础移植到 .NET Core (#2394)

寻找一个。 网核版

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 ，或将帖子静音https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY 。

太糟糕了

那么微软为非 Azure 生态系统中的 ifttt 或工作流提供了什么。当他们想要启用 Azure 之外的 ml 等功能时，为什么不启用工作流

查看 Dan Gerlag 的作品。

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

来自：VenkateshSrini [email protected]
发送：2018 年 9 月 26 日星期三上午 8:34
致：dotnet/corefx [email protected]
抄送：Jeffrey Michelson [email protected] ； 提及提及@noreply.github.com
主题：回复：[dotnet/corefx] 将工作流基础移植到 .NET Core (#2394)

那么微软为非 Azure 生态系统中的 ifttt 或工作流提供了什么。 当他们想要启用 Azure 之外的 ml 等功能时，为什么不启用工作流

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 ，或将帖子静音https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY 。

CoreWF是工作流基础到 .net 核心的一个端口。 这个港口正在进步。 我们正在寻找可以提供帮助的人。

下一个主要的垫脚石是使用 Roslyn 编译加载的工作流，以便我们可以在工作流参数中使用代码，这是 XAML 定义的工作流所必需的。 如果您在 Imperative 核心中定义工作流，您现在可以使用 CoreWF。

感谢@ewinnington和@dmetzgar的工作！ CoreWF 中通过 Portable.XAML 提供的 XAML 支持对于这项工作来说意义重大。 @dmetzgar您是否计划尽快向 NuGet 发布新版本？

大家好，

这一切都准备好了吗？ 我们正在等待要从外部 Ui 完成的工作流定义。 但是引擎应该能够加载定义并从它们开始工作。 更多的一种

@VenkateshSrini ，我认为微软没有必要提供跨平台的工作流框架。 在 .NET Framework 时代，Microsoft 提供了一切，这损害了整个社区。 我希望看到更多的 .NET 开源库被组织采用并“为生产做好准备”。

@watertree ，我正在等待 Portable.Xaml 的新版本。 CoreWF XAML 支持需要一个关键的修复程序。

现在（具有持久性）长期运行的工作流的替代方案是什么？ 只有付费的吗？

@freerider7777

仅供参考： https ://github.com/danielgerlag/workflow-core

我们在公司使用它，效果非常好。

对于那些仍在追随的人， CoreWf项目刚刚通过集成 Roslyn 推进了一个重要的里程碑，以允许执行动态加载的 XAML 工作流。 如果您仍然需要 dotnet core 上的 Workflow Foundation，请查看。

你好 ，
这是否意味着我可以采用现有的 XAML 工作流程并按原样使用它。 我们有什么限制吗

我们有什么限制吗

实例存储尚未移植，设计器不在核心上，并且由于 WCF 服务器尚未在核心上，WCF 服务不可用。

请在CoreWf 存储库上提出问题并列出您的要求。 我们可以在那里继续对话。

corewf 的当前 nuget 已过时，不包括刚刚合并的基于 Roslyn 的运行时 Xaml 执行。 我们仍在寻找反馈，看看哪些有效，哪些无效。

这是否意味着它永远不会发生？

这不会发生。 这永远不会发生 - 对那些尽最大努力的人没有任何冒犯。 查看 Dan Gerlag 的项目 (https://github.com/danielgerlag/workflow-core) 或一口咬定，加入 Azure LogicApps 培训。

您好，这是 2020 年 10 月的电话。 有关 .NET Core 上的 Workflow Foundation 的任何新闻/更新/发布？

还是我们都应该搬到艾尔莎那里？ https://elsa-workflows.github.io/elsa-core/

@wstaelens我认为MS 的答案很明确：WF 不会正式移植到 .Net Core。 建议的替代方案是CoreWF 。