Port "not-deprecated" System.Workflow.Activities.Rules components to .Net Standard components

[BlaiseD]

Issue: The .net rules engine (System.Workflow.Activities.Rules.RuleEngine) is not compatible with .NetStandard 2.0.

Proposal: Update the existing code to create the following .NetStandard library components (removing all deprecated code) for runtime rules generation, execution, and serialization/deserialization:

• System.Workflow.Activities.Rules.dll
• System.Workflow.ComponentModel.Serialization.dll
• System.ComponentModel.Design.Serialization.dll

Also add the following component .NETFramework assembly because it requires WinForms designer for rules management:

• DotNetStandard.Workflow.Activities.Rules.Design.dll

Please find a working preview solution here

The nuget package is here or here if the designer is required.

OK to do a PR at https://github.com/dotnet/corefx?

Thanks.

[karelz]

I think it would be best to discuss it in corewf repo with @dmetzgar - see details in https://github.com/dotnet/corefx/issues/2394#issuecomment-316170275

[dmetzgar]

@karelz, the rules are part of the old WF engine (System.Workflow) that was replaced in .NET 4.0 with System.Activities. The old WF included an implementation of business rules that uses CodeDom and can actually be run standalone. When System.Activities came along, the WF team didn't port rules with it (there was an effort, but it never saw the light of day). We know some people use rules without WF, but it doesn't seem common.

[karelz]

@dmetzgar what do you recommend? Leave it as external (non-MS) community-driven project? Or would you be interested in taking community contribution and maintain the port long-term?

[dmetzgar]

@karelz, since these essentially don't need WF and aren't deprecated, I think they should be under a different namespace and assembly. But that would mean breaking from the .NET Framework. Also, we wouldn't include the designer for going into the corefx repo. The WF3 runtime won't be ported to .NET Core or Standard and there aren't any other .NET components that depend on rules. I think it's really cool what @BlaiseD has done and I think it will have a greater chance for innovation as a community project. Or even a Microsoft.Extensions library.

[BlaiseD]

Thanks guys. Correct - the designer was updated to provide a UI for the new libraries - it was not meant to be added to corefx.

@dmetzgar Just so I understand your recommendations. In either case (community project or Microsoft.Extensions) it means maintaining the code in my own repository outside of the Microsoft github repositories? Or does Microsoft.Extensions carry a different meaning? Just about all the Microsoft.Extensions.* packages on nuget belong to aspnet or dotnet*.

I understand you recommend a new namespace for the libraries ported to .netstandard - Microsoft.Extensions.* sounds great.

Questions in summary:

• Where would a Microsoft.Extensions repository live - for this purpose?
• Not sure you're the right target for this question but Microsoft.Extensions is a reserved package prefix - (Error Message "Response status code does not indicate success: 409 (This package ID has been reserved. Please request access to upload to this reserved namespace from the owner of the reserved prefix, or re-upload the package with a different ID.).") does that mean the owner can issue permission to use Microsoft.Extensions or does that rule it out?

Thanks so much.

[karelz]

Community NuGet packages should not start with Microsoft or System. It helps everyone distinguish which NuGet package is supported by MS vs. not.

Given that Microsoft.Extensions is maintained by MS (mainly ASP.NET Core team), I don't think it's the easiest route for this corner-case package, unless there is a team which would sign up for owning the package long-term (that would be likely @dmetzgar's team).

[BlaiseD]

Clear - from earlier comments it sounded like @dmetzgar was saying Microsoft.Extensions was an option. Thanks much.

[dmetzgar]

Sorry for the confusion on that. I was trying to say if it was adopted by Microsoft, I think it fits better as an extension package than as a part of .NET Core. I think the reason this rules implementation never went further is because BizTalk has a better rules implementation. We wanted to build a common workflow and rules system that BizTalk and other MS products could use (like SharePoint, Dynamics, TFS, etc.) but the rules part never got off the ground. When WF in .NET 4 came out, it was orders of magnitude faster so the if/then/else rules logic could be replaced with activities.

[BlaiseD]

No problem - thanks all the same. If I'm correct BizTalk still requires IIS or can its rules engine run on any .Net Framework client without IIS like the WF rules engine? That might be the only loss?

[dmetzgar]

Sorry @BlaiseD, forgot to respond to this earlier. The problem with BizTalk is cost. About $11K per core for Enterprise. I think for people that want to use the System.Workflow rules in .NET Core/Standard, your repo and NuGet packages work fine. I encourage you to add issues to the repo so other people know how to contribute.

[BlaiseD]

@dmetzgar - thanks for the heads-up. I hadn't realized that this was in the 2.1 milestone. That's great news. I had created a separate not-online-yet repo with a different namespace as previously recommended. I'll double check that the code is otherwise identical.

[karelz]

@BlaiseD the 2.1 milestone means that this issue (question) was closed during 2.1 time-frame. There is no work associated with it for 2.1 - at least not as part of this issue. Given that there is no plan to add any code to CoreFX repo, I would recommend to find better place for follow up discussions.

[BlaiseD]

Ah - that makes more sense. Thanks @karelz . Sorry for misunderstanding.

@dmetzgar - I'll ping you from the new repo soon as it's posted (to Github) and published (to Nuget).