New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port Workflow Foundation to .NET Core #2394

Closed
galvesribeiro opened this Issue Jul 16, 2015 · 166 comments

Comments

Projects
None yet
@galvesribeiro
Member

galvesribeiro commented Jul 16, 2015

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

@stephentoub

This comment has been minimized.

Show comment
Hide comment
@stephentoub
Member

stephentoub commented Jul 16, 2015

@jakesays

This comment has been minimized.

Show comment
Hide comment
@jakesays

jakesays Jul 16, 2015

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

jakesays commented Jul 16, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 16, 2015

Member

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

Member

galvesribeiro commented Jul 16, 2015

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

@joshfree

This comment has been minimized.

Show comment
Hide comment
@joshfree

joshfree Jul 17, 2015

Member

@zhenlan can talk towards current thinking around WF

Member

joshfree commented Jul 17, 2015

@zhenlan can talk towards current thinking around WF

@jakesays

This comment has been minimized.

Show comment
Hide comment
@jakesays

jakesays Jul 17, 2015

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

jakesays commented Jul 17, 2015

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

@zhenlan

This comment has been minimized.

Show comment
Hide comment
@zhenlan

zhenlan Jul 17, 2015

Member

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

Member

zhenlan commented Jul 17, 2015

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

@jimcarley

This comment has been minimized.

Show comment
Hide comment
@jimcarley

jimcarley Jul 17, 2015

Member

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

Member

jimcarley commented Jul 17, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 17, 2015

Member

@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

Member

galvesribeiro commented Jul 17, 2015

@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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 17, 2015

Member

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

Member

galvesribeiro commented Jul 17, 2015

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

@jimcarley

This comment has been minimized.

Show comment
Hide comment
@jimcarley

jimcarley Jul 17, 2015

Member

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

Member

jimcarley commented Jul 17, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 17, 2015

Member

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

Member

galvesribeiro commented Jul 17, 2015

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

@jakesays

This comment has been minimized.

Show comment
Hide comment
@jakesays

jakesays Jul 17, 2015

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 commented Jul 17, 2015

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.

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 17, 2015

Member

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

Member

galvesribeiro commented Jul 17, 2015

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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 17, 2015

@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 commented Jul 17, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 17, 2015

Member

@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

Member

galvesribeiro commented Jul 17, 2015

@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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 20, 2015

@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 commented Jul 20, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 20, 2015

Member

@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

Member

galvesribeiro commented Jul 20, 2015

@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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 21, 2015

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

dmetzgar commented Jul 21, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 21, 2015

Member

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.

Member

galvesribeiro commented Jul 21, 2015

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.

@svick

This comment has been minimized.

Show comment
Hide comment
@svick

svick Jul 21, 2015

Contributor

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

Contributor

svick commented Jul 21, 2015

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

@zhenlan

This comment has been minimized.

Show comment
Hide comment
@zhenlan

zhenlan Jul 21, 2015

Member

@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

Member

zhenlan commented Jul 21, 2015

@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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 21, 2015

Member

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

Member

galvesribeiro commented Jul 21, 2015

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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 21, 2015

@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 commented Jul 21, 2015

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

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Jul 21, 2015

Member

@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

Member

galvesribeiro commented Jul 21, 2015

@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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 23, 2015

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.

dmetzgar commented Jul 23, 2015

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.

@knat

This comment has been minimized.

Show comment
Hide comment
@knat

knat Jul 27, 2015

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

knat commented Jul 27, 2015

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

@diegohoyos

This comment has been minimized.

Show comment
Hide comment
@diegohoyos

diegohoyos Aug 5, 2015

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

diegohoyos commented Aug 5, 2015

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

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 19, 2015

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.

Mike-EEE commented Sep 19, 2015

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.

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Sep 22, 2015

Member

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

Member

galvesribeiro commented Sep 22, 2015

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

@karelz

This comment has been minimized.

Show comment
Hide comment
@karelz

karelz Jun 28, 2017

Member

Top post of this issue is best place.

Member

karelz commented Jun 28, 2017

Top post of this issue is best place.

@keesdewit82

This comment has been minimized.

Show comment
Hide comment
@keesdewit82

keesdewit82 Jun 28, 2017

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

keesdewit82 commented Jun 28, 2017

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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar commented Jun 28, 2017

Do you mean @ronljacobs?

@keesdewit82

This comment has been minimized.

Show comment
Hide comment
@keesdewit82

keesdewit82 Jun 28, 2017

@dmetzgar Probably yes. He is the true WF hero

keesdewit82 commented Jun 28, 2017

@dmetzgar Probably yes. He is the true WF hero

@danielgerlag

This comment has been minimized.

Show comment
Hide comment

danielgerlag commented Jun 28, 2017

@ccpony

This comment has been minimized.

Show comment
Hide comment
@ccpony

ccpony Jun 29, 2017

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.

ccpony commented Jun 29, 2017

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.

@ccpony

This comment has been minimized.

Show comment
Hide comment
@ccpony

ccpony Jun 29, 2017

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.

ccpony commented Jun 29, 2017

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.

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 11, 2017

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

dmetzgar commented Jul 11, 2017

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

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Jul 11, 2017

@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 commented Jul 11, 2017

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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 17, 2017

@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 commented Jul 17, 2017

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

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Jul 18, 2017

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

Suriman commented Jul 18, 2017

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

@dmetzgar

This comment has been minimized.

Show comment
Hide comment
@dmetzgar

dmetzgar Jul 18, 2017

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.

dmetzgar commented Jul 18, 2017

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.

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Sep 15, 2017

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

Suriman commented Sep 15, 2017

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

@karelz

This comment has been minimized.

Show comment
Hide comment
@karelz

karelz Sep 15, 2017

Member

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 #2394 (comment)

Member

karelz commented Sep 15, 2017

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 #2394 (comment)

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Sep 15, 2017

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

Suriman commented Sep 15, 2017

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

@turabek

This comment has been minimized.

Show comment
Hide comment
@turabek

turabek Nov 2, 2017

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.

turabek commented Nov 2, 2017

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.

@ewinnington

This comment has been minimized.

Show comment
Hide comment
@ewinnington

ewinnington Nov 2, 2017

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: dmetzgar/corewf#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.

ewinnington commented Nov 2, 2017

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: dmetzgar/corewf#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.

@turabek

This comment has been minimized.

Show comment
Hide comment
@turabek

turabek Nov 2, 2017

turabek commented Nov 2, 2017

@VenkateshSrini

This comment has been minimized.

Show comment
Hide comment
@VenkateshSrini

VenkateshSrini Dec 31, 2017

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.

VenkateshSrini commented Dec 31, 2017

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.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Mar 22, 2018

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?

Mike-EEE commented Mar 22, 2018

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?

@meatballcoder

This comment has been minimized.

Show comment
Hide comment
@meatballcoder

meatballcoder Aug 8, 2018

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

meatballcoder commented Aug 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment