Port Workflow Foundation to .NET Core

[galvesribeiro]

Hello,

I don't see in the plans neither here and coreCLR for porting Workflow Foundation for CoreCLR...

We want know how can we start porting it and add PRs for it here.

Thanks

[terrajobst]

@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.

[galvesribeiro]

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

[terrajobst]

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.

[MelbourneDeveloper]

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.

[Mike-E-angelo]

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").

[helmsb]

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.

[MelbourneDeveloper]

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!

[Mike-E-angelo]

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.

[helmsb]

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.

[rschiefer]

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!

[mmilling1]

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.

[MelbourneDeveloper]

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...

[Mike-E-angelo]

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. :)

[MelbourneDeveloper]

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?

[dmetzgar]

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.

[galvesribeiro]

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.

[MelbourneDeveloper]

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!

[MelbourneDeveloper]

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.

[Mike-E-angelo]

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). :)

[helmsb]

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?

[Mike-E-angelo]

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:

[dmetzgar]

@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.

[galvesribeiro]

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.

[Mike-E-angelo]

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

[MelbourneDeveloper]

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.

[Mike-E-angelo]

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

[jimitndiaye]

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.

[ronnyek]

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.

[rhyous]

+1

[freerider7777]

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?

[Centurys]

+1

[watertree]

@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?

[dmetzgar]

@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 <Activity x:Class="" as it's root node and it's needed to generate the activity class that you will use in your project.

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.

[Mike-E-angelo]

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)!

[watertree]

@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.

[bgr82]

Any update on that topic?

[ewinnington]

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.

[mtraudt]

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.

[InariTheFox]

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.

[ewinnington]

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?

[dmetzgar]

@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.

[galvesribeiro]

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

[InariTheFox]

@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.

[galvesribeiro]

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...

[helmsb]

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!

[aL3891]

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.

[rschiefer]

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

[freerider7777]

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... :)))

[Mike-E-angelo]

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. 👍

[freerider7777]

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