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

[stephentoub]

cc: @terrajobst, @joshfree, @weshaggard

[jakesays-old]

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

[galvesribeiro]

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]

@zhenlan can talk towards current thinking around WF

[jakesays-old]

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

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

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

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

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

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

@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-old]

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]

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

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

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

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

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

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

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]

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

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

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

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

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

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]

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]

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

[Mike-E-angelo]

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]

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

[dmetzgar]

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

[ronnyek]

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

[galvesribeiro]

Hello guys, merry xmas and happy new year!

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

Thanks

[dmetzgar]

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

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

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

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

[watertree]

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

[galvesribeiro]

@dmetzgar,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[MelbourneDeveloper]

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

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

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

[MelbourneDeveloper]

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

[galvesribeiro]

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

[MelbourneDeveloper]

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

[Mike-E-angelo]

Also @MelbourneDeveloper UWP's Xaml is a completely different, dumbed-down version of .NET's Xaml. WindowsDev's UserVoice is peppered with (what continue to be ignored, as with everything UWP it seems -- it's any wonder why they even have a UserVoice to begin with) votes to improve its Xaml system: https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

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

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

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

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

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

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

[galvesribeiro]

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

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

[Mike-E-angelo]

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

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

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

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

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

[galvesribeiro]

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

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

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

[Mike-E-angelo]

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

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

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

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

[MelbourneDeveloper]

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

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

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

As galvesribeiro said

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

And

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

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

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

[Mike-E-angelo]

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

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

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

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

[terrajobst]

@galvesribeiro

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

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

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

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

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

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

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

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

Does this help?

[davidsh]

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

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

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

[terrajobst]

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

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

[galvesribeiro]

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

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

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

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

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

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

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