Runtime: Port Workflow Foundation to .NET Core

cc: @terrajobst, @joshfree, @weshaggard

We need System.Xaml to be opened before a serious effort can be made at porting.

I understand @jakesays .

The point is that WF can have its workflow definitions made in C# classes instead of XAML (for now) and many people don't even use the XAML representation of it. Later when System.Xaml is opened, we can integrated the visual designer and XAML definitions as well. Also, we have working on a Workflow engine that strictly follows WF usage/implementation but instead of use XAML as base storage for workflow definitions, we have it based on Json for the store, which open a lots of opportunities for new workflow designers on any platforms(not only VS or the hosted designer component for WPF/WForms) and have several benefits as faster reading/writing, simplicity of schema, faster loading/compilation and runtime operations. It can even be used to enpower client workflows, to guide application UI flows on Windows Phone/Store apps for example due to its lightweight runtime.

I really think WF is a REALLY powerful component on .Net platform, but for today technologies, XAML still a "limiter" of it but, if for a strategy decision of MS we can keep it as it is and port to CoreCLR.

Thanks

@zhenlan can talk towards current thinking around WF

@galvesribeiro many people may not use xaml, but many do, and it is indeed considered a core part of WF. We use xaml extensively, so I would see WF without xaml support hardly worth using.

I would prefer we continue lobbying Microsoft to open System.Xaml.

And using JSON as a replacement is just not appealing in the least.

@galvesribeiro @jakesays We really like to learn how much WF customers are interested in having .NET Core version of WF so it is great to hear feedback from the community. If there are enough demand, it will be helpful for us to move forward.

We are at early stage of evaluating the feasibility, dependencies, feature priorities etc. So it will be very helpful for us to learn what scenarios are in your mind, why WF on .NET Core (vs. WF in full .NET) will be useful to you and what WF features you like to see first.

@galvesribeiro In your scenario with building workflows in code and storing those definitions as JSON, what are you (planning on?) using for expressions? Are you using VB expressions, C# expressions, or do you have your own expressions activities based on CodeActivity to deal with expressions?

Thanks for the input.

@jakesays its ok for me to use XAML. I only care about performance...

@zhenlan We have a electronics payment switch that process billions of credit/debit card transactions a day for some banks here in Brazil, and some others abroad. We were full on-premises and we are updating the technology to be fully cloud, and offered as a service on Azure. We got an Enterprise Agreement in order to explore everything we need from Azure here as a multi-tenant payment processing platform for our customers.

We are investigating the usage of NanoServer for and CoreCLR so we can reduce footprint, attack surface and maintenance spent to run our services and we noticed that coreCLR does not have (at least) System.Activities ported yet. In other words, no Workflow Foundation.

Our core processing engine is a business engine built on top WF and it contains 40+ custom activities focused on our business. This engine process in real time the transaction process/rules in order to get the transaction approval. We need to scale it over demand, and does it with the current implementation of WF in cloud, let's say is not feasible.

Porting it to .net core, instead of keep it on the .net full(server profile) will open the possibilities to run client workflows, that is something we really miss on our business. Those client workflows can make people develop client-business logic declarative, in a way small devices like smartphones, wearables, IoT, and our payment terminal devices can take some decisions without writing real repetitive code.

Since we didn't found any efforts on WF for .net Core, and even it wasnt change for years and still depending on XAML, we decided to start our own Workflow Engine that behaves exactly same way as WF does. Same activities Model, same code style, etc, but a lot lighter and being based on Json as their definition store. This allow devices with small compute power, to process the workflows without the overhead of dealing with XAML/XML so most of our code made for WF is working without many changes on Json definitions instead of XAML-based workflows. Also, moving away from XAML, will open possibility for new workflow designers... Not stuck on Visual Studio and on WPF applications to re-host the VS designer.

What I'm trying to suggest is one of those option:

1. Port WF (with XAML) as is to .Net core. This options will take a lot more time since WF today depends on the server profile of .Net, which will make us spend a lot of time decoupling it in order to get it working with .Net core.
2. Port WF rewriting it to .Net core. This way, we can get the core concepts and focus on design a more lightweight engine that can run on servers, clients, IoTs or whatever is needed keeping the design principles and the features that are currently implemented on WF. This way we make it really small effort and friction-less process to migrate from XAML to (for example)Json based Workflow definitions. All the current activities must be ported to the new model.

I'm not asking you to build a team or to engage yourself into a new product. The community can do it as they are doing for ASP.Net and Entity Framework. Make it an external and auxiliary framework, not embedded on the core.

Thanks

@jimcarley The expressions would be compiled the same way they are today on XAML. In one of our workflows we have this(it can be a VBValue as well, just got a sample):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

The expressions on XAML today, are mostly returning a boolean, or assign some value to some variable, so this would be stored the same way as it is stored today on XAML, but in Json and it could be compiled following the same ideas it is today.

If you look at Azure Resource Manager(ARM), they already did that! They have the resources deployment made as a Json Template, which has dependencies and a flow, and the variables can be called as expressions. Take a look at this:

"variables": {
"location": "[resourceGroup().location]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameters('password'))]",
"authorizationHeader": "[concat('Basic ', base64(variables('usernameAndPassword')))]"
}

Ok, they are using JavaScript functions but the principle is the same. They have an $schema variable on top of the template which guide the document structure, steps on the deployment process that we can make as activities. The design is pretty similar of the WF but this DSL focus on the resource group deployment. We can make it more general, and use activities the same way they do in current WF implementation.

If you guys decides that it worth a shot, we can start drawing some documentation on another issue which will guide the architecture of the "new WF". If it sound so crazy and out of your plans let me know, we will still develop it at our end to support .net core, and release it later as a nuget for people. I'm just trying to make this wonderful framework up to date with the current(upcoming) technologies. This is really a business need for us. We depend a lot on WF, but if it doesn't get faster and supported on coreCLR, we will need to start preparing this new framework so when the NanoServer+coreCLR are RTM, we can move for it.

Please let me know if your have any questions.

Thanks

PS: I'm on gitter channels every day if you need chat.

@galvesribeiro So you are using the TextExpressionCompiler to compile the expressions after creating the Activity object from the workflow definition that is stored in the JSON. Right?

@jimcarley we don't have yet the expression compiler working. We still designing it using the same principles of TextExpressionCompiler but yes, it looks like pretty same concept. Current implementations looks like is tied to System.XAML yet. Since its not open, I can't confirm if will work the same way (internally) as TextExpressionCompiler but yes, after the activity is loaded, we should evaluate/compile the expressions(if not already in a cache) and expose a Expression object on it to be evaluated by the consumers of the activity (if required).

Last year I did some work on the expression side to enable C# expression support in self-hosted WF designers. It was based on bits of nrefactory and roslyn. I can dig it up if anyone is interested.

@galvesribeiro after thinking more on your json approach, in the end I guess it really wouldn't matter for new development. If MS won't open xaml support then this might work.

@zhenlan I agree with @galvesribeiro in that we're not necessarily looking for MS to form a team to port WF. This is definitely something the community could do with guidance from your team, etc.

@jakesays I agree with you that the storage actually doesn't matter if we are creating again WF for coreclr.

The point is, why keep using XML instead of Json since we have many tests around the web comparing the (de)serialization performance of both and json is far away faster and consume less resources than it?(for example comparing Newtonsoft's Json.Net with regular XML serializer) If WF would run on a small footprint client device(any IoT), each memory byte matters.

Also, with json, is a lot simpler to get new web based WF designers right away. The expression compilation and execution is not hard to implement. It is roughly a parser of the string to build the expression object. The hard part (imho), is to get intellisense on VS for the types used while designing the WF, but I'm pretty sure Roselyn and language services can help us with it and VS has infrastructure for it.

@galvesribeiro you mention you've already built your own workflow engine with JSON-based workflow definition and serialization. If WF were ported to Core, would you actually use it?

@dmetzgar we started developing and testing it as a proof-of-concept that we can achieve better result in a cleaner WF with almost no dependencies on the framework, which is good to get it working on coreclr. We don't have it ready.

I would love to not have to build my own engine and keep using WF even if it is based on XAML but ported to coreclr and if it follows the same concept of coreclr versions of EntityFramework and ASP.Net for example(don't depend on server libraries and runs everywhere).

The point is, if it will still depends on XAML and on Server profile, it will keep being slow(requiring too much resources), limited on designer choices, etc.

My suggestion is to port it to coreclr using Json, and removing lots of dependencies that it have today leaving the user able to run it anywhere they want the same way you can run ASP.Net vNext on a IoT ARM device(soon as ARM support is done!) and don't worry about dependencies and high resource consumption.

All our workflows today are created with current version with some of them wrote with pure code and some with XAML buth in both cases, we still have dependencies.

IMHO, port it to coreclr as it is, does not bring so much benefits unless someone comes with super new lightweight engine for XAML/XML parsing/rendering for both runtime and design time. But if you guys decide to port as is, we will keep using it anyway, since it will make my XAML workflows works(I hope) from day 0, even if I know it will not bring any practical benefits...

Again, I(probably @jakesays and other WF users) can help on this port in both ways(XAML or JSON) regardless of you guys decide. I just want to make sure this port is not just copy&paste&fix to get it working, and instead, it brings really benefits for people who are using it the following the same idea of coreclr and it can run everywhere without painpoints.

Thanks

@galvesribeiro I agree that XAML is too tightly integrated into WF. Going back to Dharma's original book on workflow, he had a sample that built a workflow from Visio. At least with porting to core, we can carve it up so the runtime is separate from XAML. That allows us to proceed with or without the XAML team porting to core and we can always add XAML workflow support later as a separate GitHub project/NuGet package. I am definitely all for making it possible to define and persist workflows in any format. Thanks, this feedback is helpful.

@dmetzgar I have no doubts that someday XAML will be ported to core... If .net core going to run on windows phone or any windows 10 mobile device, it will happens at some time and I completely agree with you that we can build a new core, and add the persistense of both definitions and state of the workflow later as well.

So, what we need to do in order to start porting it? (we already signed the contributor agreement and have other NDAs as a company with MS, etc)

Thanks

@galvesribeiro I appreciate the enthusiasm! As tempting as it is to open a GitHub repo and start hacking there are a few steps involved. Also, it's not only System.Xaml that has to be carved out. There are other dependencies deeply ingrained in WF like System.Transactions and some shared components with WCF. We're looking into each of these.

I understand. Well, I don`t want to push you guys, I'm just worried about time. We have a decision to make now to move forward building on our own, or to join the community here and port WF to coreCLR so it can meet our timeline for our product.

@dmetzgar Have you considered publishing the parts that can be open sourced right now to https://github.com/Microsoft/referencesource? I think that could be significantly simpler than creating a full-fledged open source project that actually works.

That way, you can take your time with the proper version, and others can create their own partial/custom versions in the meantime.

@svick WF components in full .NET have already been published on github referencesource a while ago. For example, you can find https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan yes, the problem with it is that some dependencies are not "resolvable"... I can't see what is the behavior of some classes correctly, due to its dependency on System.Xaml that is not public...

We can always figure out by our end, but it will mean that we don't know for sure if we are following the same way.

@dmetzgar System.Transaction is something that is not open (yet?), but I think we can deal with it (for now). Regarding the WCF, the dependency tree only show me activities and the Workflow Services Host. Nothing on the core (IIRC) is dependent on WCF...

@galvesribeiro The situation with System.Transactions is more complex than that. It's sprinkled throughout the WF runtime and is heavily depended on in durable instancing, which is where the base classes are for persistence. WCF and WF were merged into the same team around .Net 4.0 timeframe so we have things like System.ServiceModel.Internals used by both WCF and WF. .Net core has a lot of the big things ported, but there's plenty that's missing. Working around missing pieces may require design changes or rewrites of features.

None of these problems are insurmountable, I just don't want to trivialize the effort. That goes for the code and everything around it like getting legal approval, build environments, testing infrastructure, etc. We definitely want the community to help and we're working towards that. Whether you should write your own port or wait for the "official" one depends on your timeframe. Running workflows on Nano server is one of our biggest scenarios and I'd love to get your help on it.

@dmetzgar I understood, always had some delay when any question had to be forward to PR or Legal when I was on you side :)

Well, if at least we have a notion of some timeframe, we can prepare ourselves and can wait for it. I hate the idea off implement something in "the wrong place" or when there is already some efforts being spent somewhere that we can join forces to do better.

Please let me know if is there anything we can do, or if you have any news, or ping me if you need any suggestion regarding the design/port.

Thanks

As the timeframe gets clearer I'll make updates on this thread. I'd be happy to hear what other scenarios people are interested in. WF on Nano is the primary scenario right now, but it would be good to know what others are doing.

Hi guys, besides XAML and JSON, there's a COOL way of composing activities : metaprogramming. Take a look at my experimental project: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah).

@jakesays Can you provide some guidance about how to enable C# expression support in self-hosted WF.

Please keep Xaml. :) JSON serialized objects would be interesting, too. But I would prefer to see providers that are configured somehow in the framework to choose the preferred format.

@dmetzgar (and other MSFT folks) are there any news regarding this subject?
Thanks

We have been working on this and have made a lot of progress. XAML is currently not available in Core so we're focusing on the runtime. We're looking at opening up to other serializers. So instead of choosing sides between JSON or XAML, we'd prefer allowing you to bring your own serializer. There's still more compliance and legal things to get approved. Since not a lot of customers are pushing for this port it has been a lower priority.

@dmetzgar sweet! I'd be more than happy to contribute to it however I can to if this becomes a core project... whether that be a web workflow designer etc. Seems like xaml hardly needs to be there for definition format... excited to hear about this work!

Hello guys, merry xmas and happy new year!

So, do we have any update on that port or at least OSS release of the current work so we can help on it?

Thanks

@galvesribeiro I'll try to explain the situation as best I can. In my zeal to get WF ported to .NET Core, I failed to take into account the business side of this whole thing. WPF/XAML is not ported to .NET Core and that represents a significant chunk of WF. While XAML is not essential to the runtime, it is how most customers build workflows. This limits the audience which would find WF on Core useful. One of the fears is that we release WF on Core and there is not much community involvement. This adds to our support cost and doesn't improve the situation for most WF customers. While it's cool to see WF run on a Linux machine, it's hard to prove that anyone would actually use it.

I am aware of OmniXAML and we've managed to convince the author to change to an MIT license. So with some investment we could potentially get XAML working. But there's still the question as to how this benefits existing WF customers. If one day a big customer like SharePoint or Dynamics comes along and says they're moving to Nano, then we'd have a compelling case. That's all moot though if the .NET Framework team decides to make a package that can run the full framework on Nano.

If there was enough community interest and someone willing to champion the project, we could try to do it that way. Kind of like Open Live Writer. The tricky part there is that while my team would contribute to this as much as possible, that kind of project would not come with Microsoft support. I suspect most WF customers use WF primarily because Microsoft supports it.

I think it's important to highlight that .NET Core and the full .NET Framework are two different products. The .NET Framework is in no way dying. We will continue to support it, add features, etc. So it's not as if we have to port WF to .NET Core in order to keep it alive. WF on Core would basically be a new product. Coming up with a solid business justification is difficult. It might even be an issue of timing. As more companies adopt Nano servers, there may be a stronger case.

@dmetzgar How about Portable.Xaml, could it be an alternative? https://github.com/cwensley/Portable.Xaml It has been extracted for use for by the author of the fantastic Eto.Forms project for Eto. It is MIT licensed and (and so are the class libraries it derives from in the mono project).

@dmetzgar,

I'll try to explain the situation as best I can. In my zeal to get WF ported to .NET Core, I failed to take into account the business side of this whole thing. WPF/XAML is not ported to .NET Core and that represents a significant chunk of WF. While XAML is not essential to the runtime, it is how most customers build workflows. This limits the audience which would find WF on Core useful. One of the fears is that we release WF on Core and there is not much community involvement. This adds to our support cost and doesn't improve the situation for most WF customers. While it's cool to see WF run on a Linux machine, it's hard to prove that anyone would actually use it.

I think the biggest motivation for WF current users is Nano server and Micro Services and not Linux. Linux will add more users, but is not the real motivation.

But there's still the question as to how this benefits existing WF customers.

We are in cloud days. Remember, "Cloud first, mobile first..." and one of the big techs that are growing are containers, Micro Services, and a big offer from MS for all it is Nano Server.

If one day a big customer like SharePoint or Dynamics comes along and says they're moving to Nano, then we'd have a compelling case.

Even with the biggest Sharepoint or Dynamics deployment on earth, we will never reach the same number of users and I would even say the same level of revenue, than the one being made with cloud tech.

That's all moot though if the .NET Framework team decides to make a package that can run the full framework on Nano.

DNX today (as far as the RC1) is comprised of not just coreCLR. It has the full framework as well (dnx451) so we can currently use WF on DNX and that is not about the issue here. We are talking about coreCLR (dnxcore50)

If there was enough community interest and someone willing to champion the project, we could try to do it that way. Kind of like Open Live Writer.

I would not compare it to what was made on Open Live Writer... I think this is more or less what was made with ASP.Net, MVC, Entity Framework. Core "products" from .Net family and that today is open source.

The tricky part there is that while my team would contribute to this as much as possible, that kind of project would not come with Microsoft support. I suspect most WF customers use WF primarily because Microsoft supports it.

Indeed WF customers use MS Support contracts... Specially Dynamics and Sharepoint customers does it however, there are lots of applications outside this world which still requires support. Saying that people only use it 'cause of the support and the OSS isn't supported, is almost the same to say that CoreCLR, EF, ASP.Net will not have support from MS. Although those projects are OSS now, they heavly monitored and moderated by MS teams.

For example, I started as an user on MS Orleans project. It powers all Halo cloud services for almost 7 years. Skype, Outlook, and many other MS public/cloud services make use of it somehow. Few years ago, was OSSed from MS Research and now is maintained by 343 Studios, some folks from MSR, and some others from other groups inside MS but mostly maintained by the Community. Today, I consider myself an active contributor to that project and I support new user along with other MS and non-MS folks there. We have even people that are former(like me) and non-MS employees inside GH team for Orleans. Does this means that we don't have support? Well, I didn't bought Orleans so I legally ask for support inside my contracts with MS for Orleans specifically however, I can do that by targeting .Net framework or any other product related so, I don't really agree on your statement.

Coming up with a solid business justification is difficult.
I agree with you if you look only for Sharepoint and Dynamics customers.

Well, we, like many other companies around the world, maintain big Enterprise Agreements (EA) with Microsoft using most variable products on those contracts. In our case, we processes millions of financial (credit/debit card) transactions per day and each one represent one instance of a WF running on top of Orleans and inside Microsoft Azure. I don't know what would be big for you in order to act as a business justification.

I just think the core(System.Activities), without XAML, could be ported to coreCLR and designers could be created on demand for XAML, Json, HTML, XML, anything. By decoupling this dependency other possibilities are opened.

Like I said in the beginning of this thread, the most heavy work we want now, is to get it OSSed and someone (at least initially) from MSFT, become available to review the PR. The common sense here is to rewrite WF and not just copy & past it for coreCLR so we will expect big contributions on that.

If that is something that isn't going to happen, I think we can close this issue and at least people will start looking for other OSS or even paid Workflow engines that eventualy will get CoreCLR support. I just think it is a big lost don't have it inside CoreCLR...

I can give a very strong reason why WF should be ported to .Net Core.

Microsoft is ushering developers toward the UWP platform. UWP will be the Windows platform of the future. It's got nothing to do with the airy fairy idea of porting apps to Linux etc. there's a hard need to have WF running on Windows 10 machines, and UWP is the future for the Windows 10 platform.

We build occasionally connected apps. We have a .Net back end, and a UWP front end. Currently, all business logic is shared across .Net and UWP. But, we'd like to soft code business logic in WF. This will work fine in .Net, but WF is not currently supported by UWP, so WF is rendered useless because unless the user is connected to the internet, they are not able to make calls that are validated by WF logic.

UPW has a XamlReader, so parsing XAML is not really a big deal...

@MelbourneDeveloper agree with you with all reasons however, keep in mind that UWP and .Net Core (at least now) isn't under the same moniker, which means that even they sharing same lower level APIs, having same API surface(and .Net Core is OSS while UWP isn't), they are not the same thing and are not compatible. In other words, you can't add a .Net Core assembly to a UWP one. Those differences (IMHO) will eventually get rid but for now, they still exist...

Yes. Understood. It was with the working assumption that those two things will be brought together in future. If they are not, God help us!

Also @MelbourneDeveloper UWP's Xaml is a completely different, dumbed-down version of .NET's Xaml. WindowsDev's UserVoice is peppered with (what continue to be ignored, as with everything UWP it seems -- it's any wonder why they even have a UserVoice to begin with) votes to improve its Xaml system:
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

Hopefully they do the Right Thing and rally behind @cwensley's Mono Xaml port and/or OmniXaml as suggested. UWP's Xaml system as it stands is truly a joke and is part of the reason why its adoption rate is so terrible.

Along such note, I have a business use case for the MSFTies to consider: NodeJS. The longer we all scratch our collective nuts over this issue, the more value NodeJS accrues value in the marketplace, as it is truly cross platform and truly ubiquitous, something that MSFT tech simply cannot claim as of moment (or for the foreseeable future). NodeJS works on the server, and the client (ALL OF THEM) and enables code re-use between the two. One codebase will work in native (via Cordova) and web (via standard HTML5 browser) scenarios, which is much much cheaper than what you would have to do with a MSFT-based solution.

It will soon get to the point that redoing a system over in NodeJS and ditching MSFT altogether will become more palatable (and obviously less expensive) than waiting around for (what feels like) dysfunctional teams to catch up with the economic realities of the marketplace.

I also mention this as it is mentioned that it does seem that MSFT is counting on UWP for its client platform, but it reaches a fraction of the market that NodeJS does. And when I say fraction, that might be overstating it. We're talking 200m (last known install count of Windows 10) vs ~3B (BILLION) devices that nodejs-based applications can reach.

Don't get me wrong here, I love MSFT. I have invested over 15 years of my life with its technologies and I am completely invested here, personally. However, with that investment comes the passion to see everyone get it right and to be proud of the decisions and efforts made here with the new era of open source, cross-platform awesomeness. I also want everyone to be aware of the market threat that is looming (and also maybe to verify/confirm my fears).

Finally, if all goes well, we do have another big problem with our current state of cross-platform Xaml, as Portable.Xaml is different than OmniXaml, so at some point we as a community will have to figure out how to reconcile the two code bases... ideally. :)

@Michael-DST agree with you in all points. One of the targets that we want WF to run to are clients(specially mobile and embedded). We want to reduce client code for local business rules by adding WF on it. By clients I'm not strictly speaking about UWP like Windows devices(phone, tablets and IoT)...

I do believe that there are major products which rely on WF like BizTalk and Sharepoint but they still can rely on .Net full version while people on .Net Core(and later UWP) could rely on the brand new WF/XAML APIs. I know it will imply a lot of #ifs around the codebase, but that will be the way to go...

@galvesribeiro thanks you for the verification/support. It feels like I am skating uphill at times as no one seems to recognize this very real (existential?) problem facing .NET. In fact, .NET leadership is helping exacerbate this problem by recommending to pair .NET with AngularJS for web applications, basically daring organizations to switch to NodeJS altogether! (full disclosure, I wrote that. :P ).

I hesitate to post so much here regarding NodeJS, as WF is more of a server-side tech, but the way I (and other organizations are starting to) see it, this affects all spheres and threatens .NET across the board. It is simply more cost effective (and market-reach efficient) to use NodeJS as a solution stack at present and we are (again, hate to repeat myself -- but not really) seeing this reflect in organizations for their tech of choice.

Bottom line: I have to place my angst _somewhere_ and this thread is the victim. :P #sorrynotsorry

Regarding #if defs... yuck, I will quote the MvvMCross Manifesto here: "# is for twitter, not code." :P

FINALLY, I forgot to tag @SuperJMN as he should be aware of this thread/discussion as well (as the author of OmniXaml) -- no disrespect intended, dude! I will be tackling the OmniXaml vs. Portable.Xaml problem personally in the next week or so.

@Michael-DST yeah... Actually the #if is just one way... .Net Core team took the approach of "Native Shims" where the real(OS specific) implementation is abstracted on a thin lower layer of native code. In WF case it could be a shim for .Net Full and another to .Net Core for example...

I'm not a fan of Node.js and neither JavaScript (I tend to think that it still a scripting language, not a programming one but that is my own opnion), but I have to agree that nowadays, nothing is compared to it in terms of xplat. Microsoft itself uses it for its build agents on VSTS(just to name 1 case, there are others on MS) as it run on any platform for example...

I do think WF is an awesome piece of tech which current version was meant to be users on server side however, with .Net Core, and can perfectly on clients as well...

@galvesribeiro ... I am with you 100%. EF Core 1.0 is the same way... a traditionally server-side tech that can now be used on the client-side as well. It would be very handy to have WF available in such a manner as well.

Also, it is good to hear about the shims. Much approve. :)

Finally, I don't want to derail/hijack the thread (much) here, but to be sure re: JavaScript: I am in agreement as a scripting language. However, it is also a very flexible "language" that can be utilized in other forms, most notably byte code(ish). As I am sure you have seen, there is LVVM compiler magic out there for C++. The growing/popular ask in the .NET developer community is to do the same for .NET (transpile .NET into JS on an official capacity). This would truly correct all the current (major) evils in the current MSFT developer climate.

Anyways, back to your regular scheduled programming. :P Thanks for the dialogue and thoughts!

You guys are touching on some things that I've been dealing with for 9 years. There's something that a lot of people that work with Microsoft technologies don't grasp; namely the concept of distributed computing. A fundamental requirement of our software from the very beginning is that it work in occasionally connected mode. Over time Microsoft has taken various stabs at providing tooling for this, but no comprehensive framework has ever been developed. We've got a bit of sync framework over here, a bit of a LINQ database over there, but no comprehensive toolset to make everything work together.

Over the last 9 years we've been developing our own occasionally connected framework. It now runs on .Net, Silverlight, and UWP. We tried very hard to leverage Microsoft frameworks like EF, and WF, but no support was offered for these technologies on client technology platforms like Silverlight. We've literally built our own ORM and sync framework for Silverlight that is now compatible with UWP.

When there was a lot of buzz around WF in the first place, it was quite exciting because it offered a way to soft code business logic without code. But, as time went on, I became less and less inclined to think that there would ever be a port to a client side technology like Silverlight. I posted numerous questions about this on forums, but the response was always the same: WF is a server side technology, why would you want to use it in Silverlight?

As galvesribeiro said

"I do think WF is an awesome piece of tech which current version was meant to be users on server side however, with .Net Core, and can perfectly on clients as well..."

And

"One of the targets that we want WF to run to are clients(specially mobile and embedded). We want to reduce client code for local business rules by adding WF on it. By clients I'm not strictly speaking about UWP like Windows devices(phone, tablets and IoT)"

What people have to understand is that when it comes to distributed computing, there is no distinction between client and server technology. Think about the way Git works. The code for Git is the same regardless of whether you are looking at the central repo, or a node on the network somewhere. The code is duplicated everywhere. It's the same thing with our framework. Business logic is duplicated on to all nodes. That's because even if the user is not connected to the network, they still need to be subjected to the same business logic. In distributed computing, each computer literally IS a server. It literally runs the same code as the server.

We were never able to leverage WF, because we could not run the WF code in Silverlight, and now we can't run it in UWP. It's encouraging to see EF being ported to UWP. Perhaps this is the beginning of Microsoft coming to understand that distributed computing is a necessity. But, Microsoft needs to get on board with distrubeted computing and include WF as a part of the entire distributed computing framework. Maybe then, we will be able to delete our distributed computing framework, and I won't have to maintain that code anymore.

Really great perspective and thoughts @MelbourneDeveloper. Thank you for sharing them. I was also a mega huge fan of Silverlight and have been pawing at it since (hence my resulting vote and -- really -- site above). Also, I am curious what you think of Azure Mobile Services and if you have considered using that in your offline story? I am a newb w/ distributed computing (but dig what you have to say), but am really looking to get into it this next year (I am also hearing a lot of microservices, which I believe is the latest equivalent of this?).

What people have to understand is that when it comes to distributed computing, there is no distinction between client and server technology.

Really good point. At this point, it is all about where the technology is hosted. That is, you are really limited by the host of the tech that you are trying to "distribute" I would say (and again I am no expert with this). The most ubiquitous (or readily available) the host is, the better distributed/accessible the application is. Annnnnd.... I think you know where I am going with that. :P

In any case, it actually feels like we're all circling agreement on _something_ here with this discussion and that is a welcomed change/accomplishment for me. ;)

@galvesribeiro

keep in mind that UWP and .Net Core (at least now) isn't under the same moniker, which means that even they sharing same lower level APIs, having same API surface(and .Net Core is OSS while UWP isn't), they are not the same thing and are not compatible. In other words, you can't add a .Net Core assembly to a UWP one. Those differences (IMHO) will eventually get rid but for now, they still exist...

Take a look at this PR dotnet/corefx#5760, I hope this clarifies a few things.

The .NET side of UWP _is_ .NET Core. However, .NET Core provides multiple runtimes. UWP uses the AOT based runtime, so certain functionality that requires a JIT isn't supported (such as LCG or RefEmit). However, they share the same assemblies and (moving forward) the same NuGet packages. We specifically designed the stack to allow cross referencing assemblies (and packages) from UWP and ASP.NET Core.

Of course, there is VS tooling on top of this called portable class libraries (PCL) that tries to help you with building libraries that will work on a set of platforms. There are severeal choices you can make in the PCL targeting dialog that all result in your binary being .NET Core compatible. However, since portability in VS is determined by looking at the platforms, you'll not be able to reference a PCL from a UWP app unless that PCL says that it can target UWP. This behavior is by-design because the idea is that the PCL tooling helps you to not accidentally use functionality that isn't supported everywhere where you need to run. Conversely, you can only reference PCLs from platforms it says it targets.

Since you explicitly mention monikers let's talk about this for a second as well. The design of a moniker (TFM) is that it represents the entirety of the surface area. In our tooling there are two monikers:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Think of the TFM as identifying the totality of the managed, in-box, surface area while the TPM represents the underlying OS, i.e. the OS provided API set.

Since we designed .NET Core to be portable to several platforms, a traditional TFM doesn't really make much sense. That's why there is a new concept, called Standard Platform, previously called generations.

Does this help?

However, they share the same assemblies and (moving forward) the same NuGet packages.

Most assemblies have the same BINARY implementation DLL for both 'netcore50' NuGet target (WIndows UWP Store App) and 'dnxcore50' NuGet Target (ASP.NET v5 / ASP.NET Core 1.0) applications.

However, some NuGet packages like many of the System.Net.* library packages have different implementations for 'netcore50' target vs. 'dnxcore50' target. For example, the System.Net.Http library with 'netcore50' uses WinRT Windows.Web.Http implementation underneath. The 'dnxcore50' implementation uses something else (native WinHTTP).

However, some NuGet packages like many of the System.Net.* library packages have different implementations for 'netcore50' target vs. 'dnxcore50' target

Yeah, I should have mentioned that. The way I see this is that a NuGet package provides a container that allows the producer to provide different implementations for different execution environments while consumers don't need to know that. In that sense, NuGet packages are the new assemblies.

Thank you @terrajobst and @davidsh for share this deeper explanation and reference issue but, what is wrong with what I said that "1 assembly from one platform can't be referenced by other"?

The way I see this is that a NuGet package provides a container that allows the producer to provide different implementations for different execution environments while consumers don't need to know that. In that sense, NuGet packages are the new assemblies.

This concept is actually not new... People already create one Nuget Package which is nothing more than a reference to a bunch of other packages - the so called "meta packages". There are several ways to make a PCL work on many platforms. The most famous used by many popular libraries (like Newtonsoft's Json.Net) are Bait and Switch where you have a nuget that has a public interface (the API surface) and one assembly for each specific platform (the real implementation of the API surface) which can even have diff dependencies from each other and at runtime, the correct assembly for that platform will be selected. The difference now is that instead of have several nugets "inside" a single container nuget where all should be at the same platform or 1 interface assembly which is just used by development and which will Switch to the specific one at runtime, we have a mix of it! 1 nuget which is a container and at same time the public interface for all the platform specific nugets linked to it.

I think we are speaking the same thing, I just expressed myself badly at first place :smile:

Anyway, back to WF... I think is notorious that people want to have it ported to WF not just "cause its cool" to run it on linux or on Nano Server. People want to use it in a lightweight way on clients as well.

Again, I think there are enough people from the community whiling to make this port happen...

PS: For the ones who are interested in distributed computing (the real one not the offline client story) please have a look on our other project Orleans which is actually a good use case for WF on .Net Core and which empowers today big Microsoft services like Skype, Halo5, and which I personally use it as my core tech of my financial transaction processing platform which process billions of transactions in a distributed fashion...

@galvesribeiro

what is wrong with what I said that "1 assembly from one platform can't be referenced by other"?

It's not that your statement is wrong; it's just that it isn't right either :smile: Normally, I'm not the kind of person that likes to nitpick, but what threw me off was this part:

In other words, you can't add a .Net Core assembly to a UWP one.

I want to avoid giving the impression that UWP and .NET Core are different .NET platforms, such as .NET Framework and Silverlight were. We specifically designed .NET Core that you can author assemblies that work on all platforms. For instance, System.Collections.Immutable and pretty much all of Roslyn are .NET Core assemblies they will work fine in UWP as well.

So to rephrase: our goal is to build a platform where simple MSIL based components can literally use the same binary on all .NET Core based platforms. In cases where that's not possible, for instance, due to native dependencies or different implementations, we're doing exactly what Paul Betts described so eloquently as Bait and Switch PCLs: portable surface area, varying implementations per platform, and NuGet as the container and selector.

In the .NET Core world, the System libraries aren't really special. Anybody can use the same technique to make sure that most consumers don't have to litter their code base with #if directives.

I think we are speaking the same thing, I just expressed myself badly at first place :smile:

I think we've created a world where it's a bit too easy to confuse people -- which obviously includes us :smile: That's why I try so hard to be precise on how .NET Core was built and what problems we tried to solve.

Yes you are right. The impression is what matter.

I hope someday we call .Net Core on UWP as well so this will be over... So, we still need system.xaml

While related, I think System.Xaml is a separate component that adds value by itself. I've filed dotnet/corefx#5766 to track this separately.

Thanks Michael-DST

Also, I am curious what you think of Azure Mobile Services (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) and if you have considered using that in your offline story?

Excellent question. This prompts a bit of a history lesson about our company's experience with distributed computing aka occasionally connected apps and how that ties in to Azure Mobile Services, and distributed computing with Microsoft technology.

If people haven't seen the website mentioned above, I strongly recommend looking at it. It has a good video about Azure Mobile Services.

About 8 years ago we built an app for the original Windows Phone platform. The old school one with .Net Compact Framework. People may scoff at that, but on some key points this platform was more advanced than the current UWP platform in regards to occasionally connected technology. Although, it appears UWP is catching up. The keys for the success of occasionally connected apps on that platform were:

1) Full SQL Database implementation (SQL Server CE)
2) Sync Framework implementation between SQL Server (backend), and SQL Server CE (mobile device). This was Sync Framework version 1.

This app was successful. We wrote a data layer that sat over the top SQL CE, and SQL Server that was deployed to the server, and deployed to the devices. It almost maxed memory but it worked. Field workers were able to do data capture in the field, and the data was sync'd back to the central database.

We were horrified when Windows Phone 7 was released because there was a crucial problem: all the databases on the market were non-SQL databases. They were mostly implemented with LINQ. This was not compatible with our data layer, and EF didn't exist for Windows Phone 7. So, we were left unable to build an occasionally offline framework for Windows Phone 7 even though we had been able to build a full solution for the original Windows Phone platform.

Silverlight was a game changer. Again, we came across a full SQL database. But, Microsoft had not implemented the sync framework for Silverlight, or for the inline database in question. So, we set about writing our own sync framework modeled after Microsoft's sync framework. The Microsoft sync framework is based around timestamps. This is what we implemented in our sync framework. Again, we had complete success with Silverlight. Field workers were able to take Windows tablets out in to the field, capture data, and then sync it back to the central database. The problem was that this never available for phones. The database platform did not exist for Windows Phone 7.

As I've mentioned earlier, we wanted to implement business logic with WF, but Silverlight got abandoned and nobody even spoke of the possibility of porting WF to Silverlight.

Finally, we arrive at UWP. A wrapper for SQLite has been written for UWP, and with a few hacks to the wrapper, I've been able to extend the interface with SQLite to allow us to work again with a full SQL database. That means that our data layer is compatible with it. Our data layer, and sync layers now work on .Net, Silverlight, and UWP, with SQL Server, SQLite, and another unnamed database platform.

Today is the first time I've seen any syncing occuring with pure Microsoft technology thanks to Michael-DST. Basically, I can say that Azure Mobile Services syncing is just Microsoft Sync Framework rebranded. It's got a bit of a different API interface, but the basics are the same as the original Windows Phone sync framework that we used to get syncing to work about 8 years ago. I can see that it even uses the same two timestamp fields to track data changes. These were introduced in to SQL Server as a core feature in SQL Server 2008. Our sync framework works in more or less the same way as the Microsoft sync framework.

So, to answer Michael's question, I will be investigating this technology. I will see if it can replace our sync framework. I'd love to dump it and let someone else maintain it. Seeing that they have mentioned that it will support SQLite, it sounds promising because it sounds like we'll be able to hack the SQLite wrapper to continue using the full SQL database, and therefore be able to continue using our data layer. If that's the case, it's going to mean 5+ years of sync framework code will go straight in to the bin.

Anyway, the point is, Microsoft looks as though they are acknowledging once again that distributed computing is important. If it's important, WF should be ported to UWP. UWP is the future, and therefore it is also the future of distributed computing with Microsoft technology. The future of distributed technology needs WF.

While related, I think System.Xaml is a separate component that adds value by itself. I've filed dotnet/corefx#5766 to track this separately.

Thank you so much @terrajobst! I do not agree with everything you post online/twitter but I am a big fan of how you go about facilitating dialogue and communication amongst developers/community and I will always agree with that. :) This really means a lot to me personally as it seems like over a year of skating uphill to get anything from MSFT (and yes, I realize it is not commitment but at this point anything is meaningful).

So, to answer Michael's question, I will be investigating this technology.

Awesome @MelbourneDeveloper, happy to help! I feel Azure really has a solid handle on their group. Along with VSO/VSTS they really listen to their developers and get a *_lot *_done. In fact, this seems to be the case with every group in MSFT _except_ for the UWP group, which really doesn't seem to do much and doesn't even seem to understand their own technology (and let's not even get into their definition of "Xaml").

Currently we use WF for several of our core services and we are even now expanding our usage further because we've a had a great experience with Workflow and having our business logic in such a visual, easy to understand format.

Like @MelbourneDeveloper said

Anyway, the point is, Microsoft looks as though they are acknowledging once again that distributed computing is important. If it's important, WF should be ported to UWP. UWP is the future, and therefore it is also the future of distributed computing with Microsoft technology. The future of distributed technology needs WF.

WF has been under-appreciated technology by many .NET developers because they may not have seen the value of it at the time (I didn't in the past but now I'm a huge fan of WF because I understand how powerful it can be!) but in the era of distributed computing, now more than ever WF can really shine and I hope it ultimately gets ported.

I think there's little room for disagreement on this topic.

It certainly be argued that declarative, visual programming such as WF is not as efficient as writing code. I'd even tend to agree. But, having WF as a tool in the toolkit to round out a configurable platform would certainly be a good thing. Customers *_DO *_ want to see visual workflows, and empowering customers to modify their own workflows is certainly a good thing.

Time to get this done!

I think there's little room for disagreement on this topic.

Haha @MelbourneDeveloper have you even ever met a software developer? Or really, the human race? ;p

I personally feel the WF visual designer and existing tools has done a disservice to XAML, as the overly verbose files generated for MSBuild workflows have really given Xaml a bad name in this regard. That's really what developers associate with Xaml ("bloated files") and have helped spawn the flight over to "simpler" JSON files and "scripted" build files. Not to mention, the whole arcane, difficult, and cumbersome process (I still can't even get it fully working in my projects) of even creating a project to view the Xaml file to begin with.

When, in fact, how WF worked was the "right way" all along. Its real malady was in its tooling.

As such, if the designer tool was a little more friendly (and perhaps did a better job with serializing files in a more organized/compartamentalized fashion), this would be a non-issue (or less of an issue).

I am a big fan of the path of what WF aimed for, but it needs to be tightened up a bit and its tooling addressed and improved. Really, at the end of the day, a tech is only as good as its supporting tools -- designers and all. The better the tools/designers, the more accessible/understandable the better the tech, the better the adoption.

I definitely would like to see WF become more like EF and be accessible in any .NET scenario, and tooling improved to facilitate exactly this.

My understanding is that one of the original visions for WF was to support multiple file types for workflows, not just XAML. Overall other than some quirks here and there I haven't really had issues with XAML. It just took a while to get my head wrapped around it and to become comfortable editing it manually when necessary which I'm sure presents a barrier to entry for many people. So while I think XAML needs to be maintained for backwards compatibility (at least in the short term), I 'd really love to see other workflow file types start developing (like JSON). I could see some cool community contributions on that front! (Workflows written in Whitespace anyone? :smile: )

@Michael-DST I completely agree with you. Recently my team and I were reviewing likes/dislikes/wishes for Workflow and nearly everything we wanted to see improved was around the designer and not necessarily core WF itself. I think Microsoft has done a fantastic job with what they've built in WF and I think a few improvements and some evangelism we could see new life breathed into it. I think it's a tool that NEEDS to exist and I've gotten a ton of value out of WF and I want to see it continue for a LONG LONG time.

Our enterprise has made considerable investments in WF and is now a pivotal technology to our business. Given MIcrosoft recent commitment to open source and .NET Core, porting WF seems like the best next step for this technology. We need this!

Workflow has been a tool with many benefits to us as devs within our organization. If Microsoft is going to unify its frameworks, it would make our lives easier to have WF in the core framework.

Haha @MelbourneDeveloper have you even ever met a software developer? Or really, the human race? ;p

Haha, I'm a software developer. The human race is inconsequential to me.

Michael-DST

I personally feel the WF visual designer and existing tools has done a disservice to XAML, as the overly verbose files generated for MSBuild workflows have really given Xaml a bad name in this regard. That's really what developers associate with Xaml ("bloated files") and have helped spawn the flight over to "simpler" JSON files and "scripted" build files

You are probably right. But, I personally think that there's too much emphasis on the Xaml here. When I trialed WF (before realizing we couldn't use it because it doesn't exist on Silverlight), I built a WPF app. That app connected to our WCF services and stored the Xaml for the WF in a table in our database. This is how we achieved soft coding of WF.

But, the Xaml was manipulated entirely with the use of the WPF WF designer tool. The user never saw the Xaml. The xaml was irrelevant to the user. Think of it like the HTML markup behind a web page. It could be extremely convoluted, but as long as the end user likes the web page, it doesn't really matter. I think that if you're manipulating the Xaml directly as text, you're really not using WF in its intended way anyway...

The human race is inconsequential to me.

Nice. B)

But, the Xaml was manipulated entirely with the use of the WPF WF designer tool. The user never saw the Xaml.

Correct. This is exactly how MSBuild works and end users hate it because of how big the files it generates are (especially when you compare them to simple "script" files that are very basic and linear). I am in agreement with you that this is a tooling/designer issue, and I would also say that the tooling/designer could be vastly improved with WF.

Case in the point: blog posts and copy/pasting code (or really, copy/pasting _workflow_ :smile:). There have been several times where I have done some searching online for WF, and have stumbled on a nice blog post that showed some steps to perform to put in a workflow component (most likely for MSBuild). Well, in order to do this, I had to basically duplicate a bunch of steps. Usually on a coding blog post, the code is available for a simple copy/paste. Not so with WF. You have to do it step by step until it looks on your machine exactly how it looks on the blog post. This is obviously very tedious and error-prone (and totally feels like taking a step back, from a C# perspective).

The other issue we ran into with MSBuild is the size of the file, not only in bytes but also in the designer itself: it was really difficult to navigate a complex workflow. This seems like something that should be accounted for in a very comprehensive (and intuitive) manner.

Finally, I want to wrap up on the file size thing. I am not sure if you are aware of WordML and/or MSFT Frontpage from back in the day. But it would create the most bloated HTML in the world. Although users generally do not put their hands in the resulting markup, they do like to put their nose in it to get a feel for how "clean" it is. First thing they look at is the size on disk, and then secondly to open the file to see how it is formatted, etc.

Again, I am in agreement that how these files are built is strictly a tooling/designer issue, but developers do get curious and this should be accounted for as well. :)

Yes. All good points. I think that the designer would need to be cleaned up so that it does not create such verbose Xaml.

Who actually has the power to make the decision as to whether WF gets ported to .Net Core, or UWP? Is it just the case of some developer somewhere writing the code, and then submitting that patch to the administrators of the .Net Core codebase repo? What are the politics around this? Isn't there a core team of developers that are influenced by Microsoft? Are Microsoft employees? I still don't really get the whole setup. Who do we have to convince?

Actually @MelbourneDeveloper just by participating in this thread, you are helping make the argument. There is a team at MS that owns WF, currently mine, but we don't make the decision to release WF on Core. We have to make the business case. The discussion here helps me do that.

Its actually impressive how people started 2016 supporting this thread :)

Also the https://github.com/dotnet/corefx/issues/5766 from @terrajobst got a lot busier these days :)

@dmetzgar I hope you grab as much feedback as you can/need from those discussion so you have enough cases in order to OSS it.

I'm pretty sure if a dotnet/WF repo is opened of if it is added to corefx, people will definetively grow it up really fast.

Actually @MelbourneDeveloper just by participating in this thread, you are helping make the argument

That makes me feel warm and fuzzy.

Just FYI dmetzgar - I'm more than happy to document up our experiences and put a persuasive case forward to help build evidence for port business case.

I've been knee deep in Microsoft technology since 2000. I've watched all the major technologies relevant to this thread develop and fade out. While I'm immersed in Microsoft technology, I still see it from an objective point of view and think that WF is one of the key technologies that would help to develop business/government buy in to the .Net Core, and Windows UWP platforms.

Nothing gets a customer more excited than flow charts! Nothing!

I should also say that Microsoft technology is on the cusp of something big.

For so many years, I've watched good technology rise, and fall. The major reason why technology has fallen by the wayside is because of the changing device landscape. In the past, the strategy was to build a platform for each device family. There wasn't anything inherently wrong with this approach. But, it means porting technologies between platforms. That is onerous, and it's not uncommon for technologies to fall by the wayside because a platform suddenly becomes unpalatable (cough - Silverlight).

Microsoft is now getting behind .Net Core, and UWP. While I think that these two platforms should be one and the same, I'm still very optimistic that when a given technology is created or maintained, it will work across many platforms. Xamarin further enhances my optimism.

It genuinely seems that for the first time in history, we may be staring point blank at a collection of technologies that work across a very broad range of CPUs, and operating environments. If Microsoft pushes this hard, WF will be a part of that.

That makes me feel warm and fuzzy.

:+1: on that @MelbourneDeveloper and @dmetzgar. This is the sort of engagement and dialogue I personally like to see out of MSFT, rather than the ignored pleas and unanswered calls from its passioned base (that is just mean, that is mean, man).

A random aside here: to my point of NodeJS being the only business case/threat you need, a random article I happened upon lately.

Finally, to my point of "if .NET Core is good enough for EF, it should be good enough for WF" ... if WF did go to .NET Core, is there some way of integrating it with EF so that EF serves as its backend somehow? That is a compelling case right there, if so. If not, still worth the thought (see: discussion/dialogue/brainstorming/etc). :)

Finally, to my point of "if .NET Core is good enough for EF, it should be good enough for WF" ... if WF did go to .NET Core, is there some way of integrating it with EF so that EF serves as its backend somehow? That is a compelling case right there, if so. If not, still worth the thought (see: discussion/dialogue/brainstorming/etc). :)

That's an interesting thought. What is your use case for integrating EF and WF? Can you give an example? Is this for persistence?

Can you give an example? Is this for persistence?

That the very least it could be used as the backing model that the workflow works with in the application domain. At most it could actually serve as the storage mechanism for the workflow itself (but I wouldn't recommend this -- Xaml is much better suited for this).

I can see a WPF-esque paradigm here where you can define workflows in Xaml and then bind them to properties of workflow elements, using data from model entities defined, modified, and stored in EF.

Granted, my experience w/ WF is limited here (those with extensive experience might chime in here). But, if it worked for WPF, it could work for WF. In fact, I use this same paradigm (that is, of WPF-esque Xaml-based development) for a console application I use for my current project. Granted, it doesn't use data-bindings as I am suggesting (yet), but those are easily produced, as OmniXaml/Perspex has shown us. :sunglasses:

@Michael-DST I'd prefer to avoid too many integrations. WF should be a standalone NuGet package. Integrating WF and EF together should be a separate project. Start combining too many things and you could end up with Oslo.

I agree with @dmetzgar :+1:

EF is an storage/persistance provider. It should be a diff NuGet package and injected at runtime. WF must only provider a set of interfaces and thats all.

We did it pretty well with the Storage Providers on Microsoft Orleans.

@dmetzgar (and @galvesribeiro) agreed. I am not suggesting a required integration, but a possible use case/value proposition. (See: brainstorming. :smile:)

What is your use case for integrating EF and WF? Can you give an example? Is this for persistence?

I want to chime in on this one! Again, this relates to my company's experience. Ultimately, we would like to use EF for persistence of data in inline databases such as SQLite for occasionally connected apps. Ultimately, UWP/.Net Core would have EF, SQLite, Azure Mobile Services, and WF all working in harmony. I'd be repeating myself if I explained why we want this to happen, but I can explain why EF and WF would work well together. Although, we've found one limitation in EF that has stopped us in our tracks in the past - and it's the other reason we had to create our own ORM.

We have a system where data access triggers events like "BeforeLoad", "BeforeSave", etc. We leave hooks in these events so that when a given record type is saved, we can put custom business logic in there. Currently, we have done this by linking up to custom business logic DLLs. Each customer has their own set of custom events. We also implemented calls to WF. So, for example on the BeforeSave event, we could put some validation in there by making a call to WF which validates the mandatory fields. In this way, the validation logic was soft coded for a given customer. In the long run, we had to abandon WF for this purpose because it was never implemented on Silverlight, but it would have been nice to have it there as an option.

Anyway, I feel that this is a fairly universal requirement for any app. Generally speaking, you will always want a layer just over the top of the data layer which validates data going in to the database, or does general business logic. For example, we have business logic for some customers that send off emails when a record of a particular type is added to the database. This could be done in WF. It would be great to implement something like this with EF and WF working in harmony.

Alas, I never found a way to do this with EF even on .Net. The problem I found, was that EF doesn't tell you when a record of a given type is about to be saved. So for example, if you create a new "Task" object and persist that to the database with EF, there's no event fired by EF that has something like "RecordInserted". This would allow us to build hooks in to the data access so that custom business could be inserted. So, this is one of the reasons that we never went with EF. It's a pity because building our own ORM took years to refine.

Speaking to the "business case" of NodeJS: How NodeJS Is Dominating .NET in 3 Easy Charts

Patiently waiting for that GitHub repo. Only just realised that WF hadn't been ported to .NET Core which pretty much killed its viability for our product. Which is a shame as we love the changes coming to ASP.NET core and the whole cross-platform, slimmed down, modular idea of .NET Core but we need WF as it is the basis of our entire product.

I guess I honestly dont really care if this is WWF, or if its some other well supported workflow engine, but I do think for purposes of extendability, workflow of some sort could be absolutely huge.

+1

We used dynamic generation (based on imported external rules) and loading of workflows as WCF services. It would be super if we could use such model in .net core!
BTW - what's the problem of importing assemblies of full .Net? if it's mostly IL code, why doesn't it run in .net core?

+1

@dmetzgar It is incredibly exciting to see https://github.com/dmetzgar/corewf! From the readme, I was surprised to see that a port by the WF team did not gain much traction. Especially given the recent Powershell port having Powershell Workflow that will be limited to the full framework -- Linux and Mac obviously isn't a major target, but Nano server I would imagine be hugely important for Powershell. It's also mentioned in there that you are exploring alternatives to XAML does that include other Xaml implementations such as Portable.Xaml for instance already supports Profile 259 compatible with CoreCLR?

@watertree Portable.Xaml and other XAML implementations with .NET Core support that I've seen so far all have a missing feature. They don't implement the x:Class="" attribute. It's unnecessary for WPF but critical for WF. A XAML workflow typically has

PowerShell Workflow has a really nice way of defining workflows in script. It's much cleaner than writing the same thing in XAML or C#. However, PSWF converts that script into a XAML file behind the scenes. For PSWF to work on Nano, they would have to replace their existing pipeline and WF runtime so that it doesn't use XAML. And there really isn't enough pressure from customers to have PSWF on Nano.

Regarding alternatives to XAML, I have lots of opinions on this. My problem with XAML is that it is embedded in WF. With the old WF released in .NET 3.5, there was more encouragement from the WF team to convert whatever format you wanted into a workflow. They used the example of converting Visio diagrams into workflows. But when the new WF arrived in 4.0, everything was focused on XAML. Have you ever tried to write a workflow in XAML by hand? Not happening. Then there are debug symbols and viewstate. And try comparing one version of a XAML to another with a diffing tool.

I really think using XAML to define workflows should be a matter of including a NuGet package. Creating other means of storing workflow definitions should be encouraged. Maybe you need something that compresses well. Maybe you need security and only allow a limited set of activities. I prefer having options.

They don't implement the x:Class="" attribute

Indeed, compiled Xaml (baml?) has been conspicuously absent in all of the Xaml flavors that I have seen. I have thought about diving into this with my own spare time, but I have the feeling it will be available in some capacity soon, perhaps the next year. Also, Xamarin's Xaml system does support this, but it is closed and not extensible/accessible at all.

Have you ever tried to write a workflow in XAML by hand? Not happening.

True. Ironically WF is the most comprehensive benefactor (by far) of any Xaml integration. To a fault, perhaps. It is a shame that Xaml was built to be extremely designer friendly, yet the tooling around WF is a bit prohibitive for hand-written scenarios, and even for the designer itself. It seems they really aimed to make it a visual programming language, but without the significant amount of support/resources it would need to succeed.

I really think using XAML to define workflows should be a matter of including a NuGet package.

I like how you think! 👍

BTW, if you haven't yet, please take a hop over to the System.Xaml port request/issue and upvote the issue if you can. I for one would really like to see a new open source, cross-platform Xaml system that takes the best of all known systems and provides it as one official and authoritative flavor. Wouldn't that be nice? 😛

Anyways, it's up to 74 votes now. Which is pretty rad considering that the vote started before GitHub reactions were available:
https://github.com/dotnet/corefx/issues/5766

17 hearts are pretty cool, too. :)

Thank you for any support (and continued feedback)!

@dmetzgar Thank you for your efforts! Just comment on XAML -- I used to have a very negative view of XAML because most files I dealt with were created with visual designer-first dialects of XAML.

That all changed when I started programming with Xamarin.Forms which has a very nice declarative C# API in addition to XAML. There is no visual designer (only a previewer that came much later than the XF release). Surprisingly, I much prefer to work on their dialect of XAML than C# code! They did a much great job of it, and you don't have a ton of designer metadata polluting the meaning of the markup. Supporting frameworks like Prism.Forms also help tip the scales drastically towards XAML as well since it helps writing code with no code-behind very easy.

So I don't think XAML per se is the problem, but dialects designed to support designers first -- XF is pretty compelling proof for me.

Any update on that topic?

Well CoreWF is alive and exists at https://github.com/dmetzgar/corewf

It needs to be seen if DynamicActivity can now be ported with the new Composition APIs added to core and the .net standard 2.0.

Would be great if we heard from the WF team.

There have been many interesting and useful comments made on this topic. For my part, I believe that there is value in just the WF runtime and event tracking (i.e. without XAML, Transactions, or WCF bits) being ported to .NET Core and am glad that this was (sort of) done.

I agree that WF.Core needs to exist officially. If there was the ability to create a more flexible way of defining the workflows that work for developers, I believe that would be the best approach. I agree that XAML is a hard nut to crack if MS says that they aren't going to port System.XAML, but I really want to see WF.Core in my .NET Core Web API projects.

I think the huge elephant in the room here is that there isn't enough traction to get this project off the ground because MS and others have been very tight lipped on any information about WF. Sure there's some samples on MSDN, but there's very little information out there in the form of books or other solid (vetted) materials.

I am definitely willing to put in time to help bring this to life.

So OmniXAMLv2 (it's on a branch in the github repo), which is still in development, should support x:Class attributes (https://github.com/SuperJMN/OmniXAML/issues/12). Maybe we can use it for (Core)WF?

@ewinnington Thanks for pointing that out!
That's definitely a big chunk of it. Also, .NET Standard 2.0 has a bunch of System.ComponentModel types used by WF. System.Transactions is already in corefx. Only thing missing is WCF ServiceHost.

WCF ServiceHost can wait IMHO. Hosting model should be agnostic just like anything else in .Net Core/Asp.Net world I think...

@galvesribeiro I agree with this, given the fact that there are plenty of other ways that WF can work in a .NET Core world, including Web API.

Yup. However, I agree with @dmetzgar that there are a bunch of customers that today use WCF so having it supported is a must-have but again, it can be delayed...

In fact hosting and the "design language" should be abstracted from the core runtime...

We use WCF with WF but would happily switch to something like WebAPI if WF was in Core. In fact we've been going ahead and moving off of WCF to a RESTful alternative regardless. We get a TON of value out of Workflow and it's on of my favorite .NET technologies!

I also think WF on core shouldn't have to depend on either xaml or wcf, just having the wf engine and object model would be super valuable. You would then run that as a middleware on asp.net core, especially with the new pipeline/non-http work that is coming to kestrel.

+1 for having and supporting WF engine and object model in Core. We can work around XAML and WCF as well.

XAML is cool - it lets you make dynamic configuration - in one project we load xaml workflows from files and they are represented as WCF endpoints. And these XAML files are auto-generated from the registry of available services. So the wcf-services get endponts:
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
Would be nice to have such functionality in .Net core :)
Oh... I've written it here before... :)))

Yeah as I have gotten more familiar with the land here Xaml support in WF isn't so important per se, but rather it's really getting System.Xaml ported over that is the important part. Since that is clearly captured in another -- and I am quite pleased to say quite popular (but don't let that stop you from upvoting, @freerider7777! :smile:) -- issue, I am in support of making WF as dependency free as possible to ensure it gets into .NET Core. 👍

@Mike-EEE I've upvoted there a long time ago!! :)

Seeing that Workflows can be created through code, would the use of a Fluent API similar to EF Core be a valid option in bringing WF Core to life? Then the serialization/deserialization for runtime could be constructed afterwards and be much easier to implement?

FluentAPIs... so hot right now. Or at least, since they were incepted. 😄

FluentAPIs, Builder Pattern, they're both the same essentially. Providing a code based way that's chainable and easy to use I believe should be a solid principle behind this.

Without a designer it's all useless. Of course we can code everything ourselves - all the logic, all the chains and so on (with fluent or without it). But what is cool in WF - you can visually see the flow of processing. It's the link between managers (and other 'stakeholders') and developers! Managers don't undestand the code, but these high level diagrams are understandable by all. With WF you don't need separate diagrams (visio or other) if they are separated - they are commonly out of sync with real code :)

@freerider7777 WF definition serializing is not limited to xaml (see https://github.com/dmetzgar/corewf from @dmetzgar ). It could be implemented for JSON too.. and this would open up the possibility to integrate/fork existing projects like NodeRed http://nodered.org/ , which in many ways resembles the WF Designer features and UX (+ it would also run in a web browser, opening up new use cases for WF)

I think it's best to port WF to the .NET Standard and not just .NET Core. The WF runtime linked earlier already works on .NET Standard 1.3 (we can go lower if we drop the WriteLine activity). With the 2.0 standard coming out soon, we'll have the ability to fill in a lot of feature gaps like automatic cachemetadata, DynamicActivity, and transaction scopes. We should separate components into different packages so there's a pay-for-play model: if you just want runtime then you can stick with 1.3 standard, but if you want DynamicActivity you'll need 2.0 standard and you limit your platforms.

There is definitely a lot of room for improvement in the WF runtime code. For instance, I would replace activity extensions with dependency injection. Fluent API would be interesting for writing workflows in code (and along those lines look at https://github.com/knat/Metah by @knat) but I agree with @freerider7777 that the ability to communicate with your management and BAs using diagrams generated from what's actually used in production is a big plus. @helmsb has a lot of experience with this (check out http://dotnetrocks.com/?show=1236).

A new designer would have to be a web application. Targeting WPF or UWP would limit the audience. If OmniXAML pans out, people can create/edit workflows using the same tools they do today (VS or rehosted solution). The problem there is that since the current designer is built into the .NET Framework, any features or fixes would have to wait for a .NET Framework release. It's good enough to get started but not a long term solution. @erikcai8 did some experiments with a web designer, similar to nodered. I'll see if I can convince him to share.

For the workflow designer front-end, there is a first attempt available on github: https://github.com/gary-b/WF4JSDesigner and you can use it live http://gary-b.github.io/WF4JSDesigner/

This is what it already looks like:

@ewinnington: Great to see the web workflow designer POC. I have also built another one as below screenshot shown.

AWWWWW SNAP!!! IT'S a WF POC-OFF!!! 🎉

Heh heh. Hey @erikcai8 where's the Export to Xaml??? Ha ha. Just flipping you grief. Sorta. 👼

Both efforts look great. Good to see both of them. This seems sort of obvious now, but how awesome would it have been to have a web-based visual designer in the original WF? Everything is locked and loaded, ready to go, you just visit a URL. I think that would have really helped with branding and adoption. Unfortunately everyone seems to have landed on the TFS-based editor which was very difficult to setup and led to very verbose Xaml. This was a poor experience for the typical developer having to deal with it and gave anything to do with the experience (WF or Xaml) a bad name.

This, OTOH, seems like a great approach. Let the renaissance commence!

@Mike-EEE My E2E experiment enhanced the Workflow Core Engine to load JSON workflow natively so that XAML format is not required. The XAML workflow could be exported from Workflow Engine once it loaded the JSON workflow though.

That is the point. We should not tie the runtime and its object model to the designer and the serialized format the way it was in WF 4.5...

@galvesribeiro Understood the point. The experiment assumed that JSON format was supported as another option for Workflow Core though. As discussed above, XAML is not friendly for latest Web technologies yet.

We love WF please port it to .NetCore.

We need a web based workflow designer. Support for .NET core, for running the workflows would be double awesome. go go

Daniel Gerlag is working on a really nice light-weight core-compatible workflow engine here:

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

Daniel's has come a long way in a very short period of time. I would strongly encourage you to look at it and participate in this project if you find merit in it.

With all this interest, why not just build a Net Core compatible engine from scratch?

@ccpony Because you can use CoreWF on dot net core right now -> https://github.com/dmetzgar/corewf . The central components are ported and work. A few things are waiting for .net standard 2.0.

@ewinnington Thanks for responding, but I'm not getting this. WF was not a successful MS product and MS has done nothing to enhance it for years. The community is replete with testimonies of tried-and-failed implementations. It has not been widely adopted in the enterprise. It is unwieldy, over-featured, difficult to learn and (still) buggy. It's interface is widely maligned. It failed to become an end-user friendly technology. It's internals are essentially a black-box which can't be easily enhanced. It is SLOW with anything other than simple workflows. It is very difficult to test. It is based on old technologies (WCF, XAML). Ever since Ron Jacobs got sick, WF has languished and has no friend at MS.

In my estimation, WF tried to be everything for everyone and in fact, turned out to be little for anyone. Microsoft has all but dropped it. Why would we wish to resurrect anything like that? If any important technology called for a rethink and a re-write THIS IS IT.

Look at Daniel Gerlag's fledgling project. It's new and immature. But it takes a modern approach to workflow that would be easy to enhance. If everyone here would stop trying to retrofit a complex, dated and, frankly, over-engineered project and, instead put their efforts into something new and better, then we'd stand a chance of ending up in a worthwhile place - - incrementally building a world-class workflow engine instead of trying to re-write a behemoth from the get-go. Honestly, I admire everyone here who wants to engage in a VERY worthwhile effort - - creating, FINALLY, a well engineered, functional, light-weight, east-to-learn, cross-platform workflow (state machine?) tool. But, I'm sorry to say, if you all continue to follow this path, then all your efforts will just fade away into nothing. MHO.

@ccpony Thanks for sharing your opinion. Would you mind elaborating on what bugs you're referring to? If there's something we can do to fix issues in the .NET Framework, I'd be happy to know.

@dmetzgar Thank for responding, Dustin. During the period of time that was trying to develop WF applications, I did encounter bugs. Not just unexpected behaviors, but there were several times that a complex WF would "blow up" and generate errors in the XAML UI that were difficult to fix in the XAML code. I never really developed a great confidence in the WF technology. Really, it just got to the point that I felt like I was wrestling a 800lb gorilla - - for every one step forward, I would end up being set back two steps.

I know that is not what you're looking for in your kind request for me to elaborate on bugs. Frankly, I could work around those bugs. But I eventually abandoned WF for all the other reasons that I referred to in my previous post.

You are spearheading this effort and I salute you for it. But surely there comes a point when trying to retrofit a complex technology becomes counterproductive. Following this entire thread, I simply can't help but feel that progress is very slow - - if at all - - and eventually nothing will show from all this. I find it very unlikely that old workflows will be portable to whatever is produced here. People in this thread are talking about client-based workflow (i.e. JavaScript), REST compatibility, reducing dependencies, cross-platform, etc. For example, XAML is such an important part of old WF technology, what use is porting WF to core is XAML will not be a part of it?

So Dustin, I need to ask you this: here we are 18 months into this project and there simply doesn't seem to be consensus that real progress is being made. I respect your efforts and I can see that you're a great coder - - but here's my question: wouldn't it make MUCH more sense to garner all this energy and enthusiasm and create something new?

@ccpony The discussion in this topic is to support WF .Net Standard and not the opposite.

Just curious... Have you ever used or saw a Sharepoint deployment in action? If you do, you will see that it is really heavily on WF. Have you ever saw a BizTalk deployment? The same.

Those are major MSFT products in enterprise world, so yes, there are users that care about WF and there is usage for it. It is not a forsaken/dropped project like you said.

With that said, if you look at @dmetzgar repo, you will see that as much some stuff is similar or inherith some behaviors from old incarnation of WF, you will also see that it was redesigned to be lightweight. The persistense is decouple and people can easy create new ones. The designer is decoupled and people already created multiple tests.

I understand your frustration on wanting something new. Believe me, I want that to happen too. But you have to understand @dmetzgar and his team. This is not a priority since 95% of the customers are users of old WF which basically has it running on BizTalk and Sharepoint as I mentioned. I used the old WF for years in a very high tps environment (banking and financial transactions) and it served me very well.

My new tech is working with .Net Core, and the only reason I'm not using it again right now, is because we don't have it for .Net Core yet.

What I already suggested to @dmetzgar, is to bring WF repo to .Net Foundation, define milestones, put the code there and add tasks as Issues and tag it as up-for-grabs so the community would start doing it. However, that still requires some time from his team to get this work out and they possibly don't have that time available (yet).

@galvesribeiro I get your point. Yes, I have written SharePoint deployments. And I HAVE seen BizTalk deployments in action ( * shutter *). I understand the relationship between SharePoint and WF. (I don't know what you mean when you suggest that BizTalk somehow relies on WF. It doesn't.)

But I do have to disagree with you on one important point: WF IS a forsaken/dropped project. I truly understand the concern of SharePoint developers at this point. There is no reason to believe that MS will enhance WF's capabilities in SharePoint. I don't understand why you think that @dmetzgar's efforts will have anything to do with the future of SharePoint (or BizTalk). It's not like MS will retrofit SharePoint with @dmetzgar's code. Sorry, but the future of SharePoint has nothing to do with efforts being made here.

So, all the really matters is whether a good workflow engine will come out of all this. And it's my contention that trying to force a behemoth like WF into the future is not the best course of action. Better to build from scratch.

@ccpony I would like to remind you that there are numerous people here who are actively seeking to see this project come to life, and some are actually putting time in to making it happen. While you personally may view WF as a failed product from Microsoft, it continues to remain a part of .NET and is used by more than just us here.

This thread should be for constructive criticism and input in to making the transition a reality and not a slam on others or the product itself. While your views are respected, note that they are yours and that others may think differently in regards to how WF is important to them.

We actively welcome your input on ways to improve the product and how best to help those who are actively participating in the attempt.

Thanks =^_^=

@ccpony

(I don't know what you mean when you suggest that BizTalk somehow relies on WF. It doesn't.)

Sorry, I express myself badly (I'm on mobile). I had application which use both together and I know much other which does as well.

There is no reason to believe that MS will enhance WF's capabilities in SharePoint.

I'm not saying it will. I'm saying that the team who work with WF Today, is totally focused on support Sharepoint deployments. Even the latest version of Sharepoint are using the same/current version of WF.

I don't understand why you think that @dmetzgar's efforts will have anything to do with the future of SharePoint (or BizTalk).

I'm not saying it will affect Sharepoint's future. I'm saying the team is busy supporting Sharepoint if I understood correctly. (@dmetzgar can correct me if I'm wrong)

It's not like MS will retrofit SharePoint with @dmetzgar's code. Sorry, but the future of SharePoint has nothing to do with efforts being made here

If MS will use or not WF vNext on Sharepoint vNext, only they can tell it for sure. Again, the problem is that WF team isn't able to deal with both.

So, all the really matters is whether a good workflow engine will come out of all this. And it's my contention that trying to force a behemoth like WF into the future is not the best course of action. Better to build from scratch.

Nobody is porting it as is. @dmetzgar's repo is a proof that it is being redesigned from the ground up. Again, the problem is the backlog and bandwidth the team have to deal with both things. That is why I suggested to "open" it on dotnet foundation and make it a major community-driven effort with guidance and curation of the WF team so we trying to affect as less as possible their schedules.

Again, like @InariTheFox and myself mentioned, this thread is a push forward for port, which not necessarily means force-push the old fersion with all this features to the new version. However, its important to understand that people put a lot of effort(and money) on their current WF-based products, so @dmetzgar concerns on keey as much compatibility as possible with the old workflows, is indeed something to look after.

Ok. I see the passions here. Actually, if there was a good replacement to WF that addressed all the problems that I mentioned before, we wouldn't be having this conversation. For the record, a lot of us have walked away from WF and have waited in vein for the next thing to come along. It never did. To the best of my knowledge, there is NO current, supported, functional, .Net-based workflow/state machine solution that is widely regarded. Please understand: I stand by my contention that WF is a dead technology from Microsoft's perspective.

But, having said that, please help me understand. Does @dmetzgar's repo work as-is? How does one write workflows with it? I don't see any example code and there isn't any documentation. How would I proceed?

I think that there are many products / companies out there that made WF central to their product strategy, it is not just a Sharepoint dependency in support mode: at my current company we developed an automation platform with WF being the central tech (and I know other 2 competitors from this market that also use WF in their products); also I've discussed with people who use it in insurtech.. so I strongly believe that the audience for WF is still there.

That being said, .net core seems to be one of Microsoft's focus areas and a lot of tech innovation will go into it in the next period; I think it would be a great loss to not have WF as a part of it.

From my perspective the right path to make it happen is to make the WF core independent of xaml and make it easier to (de)serialize workflows in other formats too (ex: json). This would also simplify the implementation of scenarios like workflow designers hosted in web browsers. And with the https://github.com/dmetzgar/corewf repo we have a starting point.

For those interested in an overview about the current state of WF (which I don't see as abandoned by MS), a while ago I centralized the available info regarding WF in a post & a presentation http://andreioros.com/blog/windows-workflow-foundation-rehosted-designer/ ; I'm still keeping it up to date

We and our customers rely on WF and we would dearly love to see it working on the client as well as server. A WF free of XAML and other dependencies, designed to be lightweight but with the expressiveness of the existing WF that is also community supported with MS would be an exciting and valuable product indeed.

Once again, please allow me to ask: what does one do with @dmetzgar's port to give it a run? What is the current status?

I didn't know @dmetzgar's port was actually usable in its current incarnation...

From @ewinnington, above:

"Because you can use CoreWF on dot net core right now -> https://github.com/dmetzgar/corewf . The central components are ported and work. A few things are waiting for .net standard 2.0."

In which case I too would like to hear of its use...

Yes, it is the barebones of core functionality. You can run code-based workflows. The missing features from netstandard2.0 are mostly related to transactions support.

That is more one reason I still suggest to start it open and make people contribute to a central place. Having it spread will make things even more difficult to reach in a final product someday in the future.

Up vote for WF rewrite with tests and support for modern Roslyn features as a part of Core. I'd love to see how serverless and containers could affect the architecture, especially the deployment and scaling of rule sets within distinct domain contexts and business processes. I'd personally prefer a succinct DSL over a WYSIWYG designer. I did personally love the designer, but it felt quirky almost all of the time. WF itself had potential to be extremely solid, but required deep expertise. In facy, a large rollout of WF that included WF Manager and persisted flows in SQL Server required MS consulting and bug fixes. Although I now support Java teams the past several years, I like to keep an eye on .NET after just over 15 years of primarily focusing on MS tech. I was reading "Code Generation with Roslyn" by Nick Harrison (I have no ties to him or the book) and wondered about reapproaching the Business Rule Engine space once again, which led me to wonder about the fate of WF once more... in all honesty, I would think that Azure Functions compete with both MS resources as well as their general corporate willingness to support deep investments in WF anywhere. It seems obvious they'd want you to use that... so, perhaps the solution is to instead focus on an open source .NET version of OpenWhisk. But, in a containerized world, ... I can just use OpenWhisk as a service. So...

P.S. simply supporting a robust method of importing externalized expressions might solve 60% of the app requirements out there that think they might want WF. Was it CSharpScript? A simple way to import basic business rule configurations with a straight-forward API would go a long way (various persistence, retrieval, and caching options). With disposable virtual infrastructure (automation over Infrastructure-, Container-, and Platform-as-a-Service), WF vNext could focus on deploying version changes as a service over trying to in-line them in apps (i.e. a better solution for WF on WCF)

I'm extremely interested in this conversation. My team has been dealing with the frustration of XAML as well. Our dilemma is that we are creating our own UI designer to allow our customers to create their own workflows without needing Visual Studio or the rehosted designer. We need the ability to save chunks of XAML into reusable bits so that the customer doesn't always need to rewrite those bits (think of them as workflow functions). This requires us to know how to merge chunks of XAML together, which we've learned is extremely frustrating. What we're thinking of doing is creating an abstraction where we simply rely on a database model of our various activities and their linkages and ignore XAML altogether. We will then create the activities, etc programatically each time a workflow is executed. While researching this approach, I stumbled upon this thread. Keep up the conversation, I'm very interested to hear other's opinions.

@erikcai8 Workflow designer is very nice Idea. Can I get the source of your workflow designer?

I've been using WF for more than 5 years now in my automation projects and it was wonderful. I hope a lot of developers will support this request and make it happen. I have always used .Net tech since I started working and would want to continue doing so. However, being able to support cross-platform is the company's direction, thus I 'm really looking forward to see full WF in .Net Core.

With the arrival of net standard 2.0, it would be great to have an update on the issues of corewf:

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

How have the added API unblocked the porting process and what can we do to help?

I think regardless of netstandard2.0, this port should go as it was going IMHO... With a rewrite... Making it friendly to external task schedulers, async/await/Task, and other modern stuff. As much as I love WF, the current version is pretty outdated...

I mean this with no disrespect whatsoever. Honestly. But am I the only one here that understands that this project is hopeless? We desperately need a good workflow engine for .Net, but this is just not it. Shouldn't we be changing the conversation here?

I'm open to a new, better workflow engine. Bottomline we need one in .NET Core. We have used WF for years and it has worked really well for us so it's better than nothing if that is the alternative.

@kalokamgit, the source is available on reference source. It's in two assemblies:
System.Activities.Presentation and System.Activities.Core.Presentation.

Unfortunately, the tool that publishes the reference source only does the C# code. It doesn't include any of the XAML files. You can provide feedback about this to [email protected] and/or vote on the user voice issue.

The code is in the .NET Framework so you're free to use it in your own tools. Some examples are @orosandrei's project and an example project here.

I mean this with no disrespect whatsoever. Honestly. But am I the only one here that understands that this project is hopeless? We desperately need a good workflow engine for .Net, but this is just not it. Shouldn't we be changing the conversation here?

Well if you _really_ mean no disrespect. :) I am curious on what everyone's thoughts are around Flow? That is what I think of when I think "workflow" for the "modern day" ... also what Azure is peddling pretty hard these days.

I REALLY REALLY mean it :)

Guess Flow is the answer to growing Zapier ? I do not see how it would replace WWF in any way.

Is WF discontinued or am I missing something here? That would be very sad!

Where can I vote for WF?

Top post of this issue is best place.

I wonder what @rjacobs (WF guru) thinks of this matter.

Do you mean @ronljacobs?

@dmetzgar Probably yes. He is the true WF hero

This is my answer
https://github.com/danielgerlag/workflow-core

Ron Jacobs was the guy who put his heart-and-soul into WF for years and years. He contracted Dercum's Disease and left Microsoft in 2013. (here) When he left, that was it for WF. Once again, and hopefully for the last time: WF IS DEAD.

And once again - - I would encourage everyone and anyone to look at Dan Gerlag's project, above. It's eloquent, beautifully conceived and runs on Core. Anyone who wishes to contribute to a viable workflow solution needs to look it.

Also please take a look at the Durable Task Framework. This is being added to Azure Functions, see Durable Functions.

@dmetzgar This framework is in diapers to be considered an alternative to WF. I do not think it's serious that Microsoft proposes this sort of thing. Would not it be much better instead of reinventing the wheel, migrating WF to .NET Core and reusing it as a basis in all Microsoft projects? Sorry for the harshness of my words, but I think they represent the sentiment of many people who are very disappointed with the current situation of WF.

@Suriman, fair point

I updated the readme on the corewf repo to have a better description of what's involved in porting WF to .NET Core. Would you mind having a look?

@dmetzgar Thanks for the clarifications and for clearly showing the way forward to port WF to .NET Core. I understand from what you say that Microsoft is not going to do all this migration work and that it hopes the community does, is it? The answer to this question is the key, depending on the response, companies can opt for an alternative route or do the work that Microsoft should do.

Microsoft will not do an official port of WF to .NET Core. My team and I will work on this in our spare time, but not in an official capacity or with any scheduled releases. All of the issues listed are up for grabs. There are uses for such a port for some of the projects we do. That will be where most of our contributions come from. I think it's fair to close this issue for now and point people to the corewf repo to follow the latest work.

Hi,
The change from Future milestone to 2.1, does mean Microsoft will be porting WF to .NET Core?

The milestone change for closed issues just reflects during which release the issue has been closed.
This particular issue was closed basically as "Won't Fix" - see explanation above https://github.com/dotnet/corefx/issues/2394#issuecomment-316170275

@karelz What a pity. For a moment, it looked like the lottery had hit us.

We have a Solution based on WF. We are creating a steps of activities using WF and this workflow will be delivered to all subscribers and they will process the actions based on WF. We love WF to much. supporting cross-platform is our company direction. We are very interested to have WF on .NET CORE.

There is CoreWF which is the code of Workflow Foundation partially ported to .net core. You can use Workflow foundation cross platform now. You just cannot use XAML based workflows at this time.

I have a branch where I've worked on adding support for Dynamic Activity on top of Net Standard 2.0.

The XAML parsing process requires Microsoft to open System.XAML sufficiently for us to be able to make progress parsing the files correctly.

You can track the progress on the issue here: https://github.com/dmetzgar/corewf/issues/6 and in my various attempts at bringing notice to this issue:
On CoreFX
On ReferenceSource

The .Net compatibility pack has a "Maybe" on the System.XAML front. But no news has filtered about its inclusion. The issue Ship .Net Framework Compatibility Pack currently lists "no plans" for System.XAML.

Maybe also the issue Customer Adoption Epic could be used to tell your story of how adding Workflow Foundation (and System.Xaml) would allow your company to ship a product.

My company is also invested in WF: We have a product for Energy companies where our clients create workflows using Workflow Foundation.

Thank you for your reply.
it was very useful appreciate it.

On 2 Nov 2017 18:22, "Eric Winnington" notifications@github.com wrote:

There is CoreWF https://github.com/dmetzgar/corewf which is the code of
Workflow Foundation partially ported to .net core. You can use Workflow
foundation cross platform now. You just cannot use XAML based workflows
at this time.

I have a branch where I've worked on adding support for Dynamic Activity
on top of Net Standard 2.0 https://github.com/ewinnington/corewf.

The XAML parsing process requires Microsoft to open System.XAML
sufficiently for us to be able to make progress parsing the files correctly.

You can track the progress on the issue here: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 and in my various attempts
at bringing notice to this issue:
On CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
On ReferenceSource
https://github.com/Microsoft/referencesource/issues/39

The .Net compatibility pack
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
has a "Maybe" on the System.XAML front. But no news has filtered about its
inclusion. The issue Ship .Net Framework Compatibility Pack
https://github.com/dotnet/corefx/issues/24909 currently lists "no
plans" for System.XAML.

Maybe also the issue Customer Adoption Epic
https://github.com/dotnet/corefx/issues/24751 could be used to tell
your story of how adding Workflow Foundation (and System.Xaml) would allow
your company to ship a product.

My company is also invested in WF: We have a product for Energy companies
where our clients create workflows using Workflow Foundation.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Hi,
This is a world of micro services and the entire stuff is broken down into components . Now if we have to orchestrate it we will have to depend on Azure logic apps or some other external vendor who charges premium for a workflow. Though very little non .NET WF product like Netflix Conductor, we would love to have one in pure .NET core version. You can take the clues from Netflix conductor at https://github.com/Netflix/conductor and start building one from there. This will be of great boon to private cloud developers that do not have access to Azure Stack who cannot use Logic Apps.

Thought I would post here for the sake of awareness. I was reading over the following documentation and it made me think of this thread:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Looks like Dynamics365 and PowerApps are doing a mind meld and are using Windows Workflow in some capacity for its workflow handling now. This of course is all Windows-only, but in the new era of cross-platform, etc... how long will this last?

I don't know what I am supposed to be using. I wish MSFT would do this. Bring clarity Microsoft.

@VenkateshSrini, you should also look into Cadence: https://github.com/uber/cadence
The model is more like Amazon's SWF but it is open source. No .NET client yet though.

Looking for a. Net core version

Not going to happen.

From: VenkateshSrini notifications@github.com
Sent: Wednesday, September 26, 2018 12:30 AM
To: dotnet/corefx corefx@noreply.github.com
Cc: Jeffrey Michelson JMichelson@unitec-corp.com; Mention mention@noreply.github.com
Subject: Re: [dotnet/corefx] Port Workflow Foundation to .NET Core (#2394)

Looking for a. Net core version

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/corefx/issues/2394#issuecomment-424581034, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY.

Too bad

So what is Microsoft offering for ifttt or workflow in non Azure ecosystem. When they want to enable things like ml out of Azure why not workflows

Check out Dan Gerlag’s work.

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

From: VenkateshSrini notifications@github.com
Sent: Wednesday, September 26, 2018 8:34 AM
To: dotnet/corefx corefx@noreply.github.com
Cc: Jeffrey Michelson JMichelson@unitec-corp.com; Mention mention@noreply.github.com
Subject: Re: [dotnet/corefx] Port Workflow Foundation to .NET Core (#2394)

So what is Microsoft offering for ifttt or workflow in non Azure ecosystem. When they want to enable things like ml out of Azure why not workflows

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/corefx/issues/2394#issuecomment-424697799, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH-Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY.

There is CoreWF which is a port of Workflow foundation to .net core. This port is progressing. We are looking for people to help.

The next major stepping stone is to compile loaded workflows with Roslyn so that we can use code in the workflow parameters, this is needed for the XAML defined workflows. If you define workflows in Imperative core, you can use CoreWF now.

Thanks for your work @ewinnington and @dmetzgar ! The XAML support through Portable.XAML in CoreWF is a huge deal for that effort. @dmetzgar Do you plan on publishing a new version to NuGet soon?

Hi all,

Is this all production ready. We are lolling the work flow definition to be done from external Ui. But the engine should be able to load the definition and work from their on. More of an iffft kind

@VenkateshSrini, I don't think it is necessary for Microsoft to provide a cross-platform workflow framework. In the .NET Framework days Microsoft provided everything, which was to the detriment of the overall community. I'd like to see more .NET open source libraries adopted by organizations and made "production ready".

@watertree, I'm waiting on a new release of Portable.Xaml. There's a critical fix needed for CoreWF XAML support.

What's the alternative for long running workflows for now (with persistance)? Only paid ones?

@freerider7777

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

We use it in our company with very good results.

For those still following, the CoreWf project has just advanced a significant milestone with the integration of Roslyn to allow the execution of dynamically loaded XAML workflows. If you still need Workflow Foundation on dotnet core, check it out.

Hi ,
Does that mean I can take the existing XAML work flow and us it as it is. Do we have any limitation

Do we have any limitation

The instance store has not been ported yet, the designer is not on core and the WCF Service is not available due to WCF server not being on core yet.

Please make an issue on the CoreWf repo and list the requirements you have. We can continue the conversation there.

The current nuget for corewf is out of date and does not include the Roslyn based runtime Xaml execution which has just been merged. We are still looking for feedback to see what works and what doesn’t.

Does this mean that it is never going to happen?

It's not going to happen. It was never going to happen - - no offense to those who put in their best efforts. Check out Dan Gerlag's project (https://github.com/danielgerlag/workflow-core) or bite-the-bullet and jump on-board the Azure LogicApps train.

Hello, this is october 2020 calling. Any news/updates/releases on Workflow Foundation on .NET Core?

or should we all move to Elsa? https://elsa-workflows.github.io/elsa-core/

@wstaelens I think the MS answer was pretty clear: WF will not be officially ported to .Net Core. The suggested alternative is CoreWF.