Wcf: Call for Decision: Server-Side WCF

[hivanov]

I have increasingly come to the conclusion that, for the listed applications below, for us WCF is the most sane solution. I would like to offer help in developing the server-side bits and pieces needed. This seems to be easier now since the client-side code is already here, and we can start with some basic goals first, then build on that. Here are the use cases which come to mind:

• Developing a simple web service, which exposes SOAP, or any non-REST protocol, or a REST + other endpoints using the same code base.
• Developing a Microservice -- currently, we are limited to either SOAP or RabbitMq messaging, and providing custom tooling (either by bootstrapping, or by developing in-house libraries to host the projects).
  For us, the main selling point of .net core is the ability to write cross-platform containerized applications (namely, microservices).

I would like to volunteer by helping porting the Service Host with all relevant dependencies, by stepping on the already available building blocks and stripping out all but the essentials in the first phase.

Are there any blockers (be it legal, or technical) prohibiting this effort?

[curiousdev]

I too am interested in helping out. This would really help with our migrations.

[CDuke]

Me too. It will be cool have .net core server side wcf implementation at least with some restrictions

[Grauenwolf]

Are we allowed to port the WCF source code from Reference Source?

https://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/ServiceHost.cs

If not, then who do we need to ask permission from?

[Grauenwolf]

Forget my last comment. Reference Source is offered under the MIT license:

https://github.com/Microsoft/referencesource
https://github.com/Microsoft/referencesource/tree/master/System.ServiceModel/System/ServiceModel

We could start this tomorrow morning if we wanted to.

[CSharpenter]

Count me in too please.

[Lexcess]

Note that some libraries relevant to WCF (notably System.ComponentModel and various serialization libraries) made it into .Net Standard 2.0. Also System.ServiceModel.Primitives and System.ServiceModel.Http already exist as Nuget packages to support client-side WCF.

I think there are a couple of big decisions worthy of at least some thought up front (if not actually picking a direction):

• Configuration - Do you present something that works exactly like how it works now or do you adopt Asp.Net Core style idioms.
• Platform support do you port as much as possible with PlatformNotSupported throws for Mac/Linux or do you make every feature work across all targets (with all the additional work that implies)

I'd say the sweet-spot would be getting your proposed subset operational cross platform, but using the modern configuration conventions. That means that users stuck on NetFX have a place to go (and maybe contribute), but you aren't putting off NetCore users (who might need SOAP other protocol support). I am sure people would disagree with that though :)

[kscelfo]

Regarding configuration, I agree that adopting the Asp.Net core style would be prudent and would not present a high bar to jump over to bring existing applications into .NET Core.

With regard to platform support, I think you could compromise by releasing initial versions with PlatformNotSupported throws, and as additional work is done to bring other features over they will light up accordingly. I would imagine that some things like MSMQ would never light up for the Mac/Linux side unless there is some equivalent available on the platform that could be swapped into its place. MSMQ is probably a bad example because if you're using it and are suddenly attempting to run on Linux you should probably stop and ask yourself some important questions.

[Lexcess]

I agree entirely when talking about all the various implementations out (not least MSMQ), it should be case by case support.

I was only suggesting attempting to do multiplatform for the proposed SOAP implementation so that you get what is probably the big win for a lot of people (SOAP everywhere), but also a clear model is available for others to follow when handling platform specific logic where it does make sense to do so.

[Grauenwolf]

Ok, so what's the next step? Do we want to fork this project and start adding classes to see what compiles?

[shyamsundarb-arch]

I too would be interested in helping out. This would greatly help with on boarding a lot a folks to .net core

[tibitoth]

I would be really really happy if server side WCF could happened in the 3.0 timeframe, (it would be better if all type of bindings will be available: NetHttp, NetTpc, NetMsmq (Windows only))

[mack0196]

Me too. Where is this effort at and how can I help?

[Danielku15]

I would also be happy to help (if my time allows). I'm eager to move to .net core for our products but the lack of WCF is a small obstacle. It would be good to make a first analysis on what it would mean to compile to existing WCF codebase to .net core. Just out of my mind some steps that anybody could easily take over:

• Fork/Clone the existing WCF source, attempt to compile it, and summarize where we are.
• Identify the required framework components which might be part of .net standard, available via NuGet or would require porting.
• Think of a good package separation (e.g.: separation of shared core, server-core, client library, individual bindings,...).
• Think of potential ASP.net core integrations via middlewares.

I doubt that it makes sense to overthink this topic and start planning a "new" WCF from scratch like the EFCore team did with the complete replacement of the classical Entity Framework. We should stay realistic and port what we have to .net core. In worst case some parts must be cut out to a desktop framework only package in first the go, but adapting the existing codebase is something the community should be able to achieve.

[Grauenwolf]

I tried forking this repository, but I can't figure it out. Every solution I opened says that it is missing files.

So step 0 is probably getting someone at MS to walk one of us through this.

OR

We start over from scratch. Which means while new projects/ solutions based just on the older Reference Sorce code.

[elovelan]

@glennc, I see you're assigned; are you able to help with steer on this?

[dgxhubbard]

Does anyone know if WCF server side is going anywhere.
I would like to contribute also.

@glennc is there anything we can do.
We are at a point where we cannot use .net core 3 unless there is some sort of WCF server side?

@karelz #2695 references WCF server and mentions it is being added to the milestone. Does that mean WCF server will be in .net core 3.

From this grpc-dotnet 189 grpc-dotnet will not use an interface to generate anything rather they will use low level proto files so I am not sure why grpc-dotnet could replace WCF Server.

From this dotnet-core 2522 issue appears to be closed but in other places #2695 is referred to as tracking WCF Server.

Is there some hope that WCF Server or some form of it will be revived rather using RPC.

[karelz]

@dgxhubbard #2695 (closed issue) milestone says when the issue (question) was closed.

[Grauenwolf]

I don't understand what gRPC has to do with it. That technology doesn't solve the same problem that WCF addresses.

[dgxhubbard]

I believe that microsoft is pushing gRPC as the replacement for WCF Server in .net core 3.
I agree with you.

[Grauenwolf]

What bothers me is that the announcement comes from the ASP. NET community talk.

They do not do a good job of understanding and representing non-web developers and really shouldn't be involved in the decision.

[cbenard]

@Grauenwolf what announcement? Link?

[dgxhubbard]

I agree completely. In the bad old days we did RPC and its way more involved than is needed.
WCF takes an interface and does everything. Why asp.net makes the decision I don't know, but
.net core 3 is targeting windows forms and wpf apps. I am not sure how many developers will be willing to start over for their services which I think will hinder .net core 3 adoption.

[insylogo]

It's a comedy of errors over at the project management side that this still hasn't been decided either way. If people need to make breaking changes to switch over to .NET Core, you should tell us. If you need volunteers to port code to .NET Core, you should tell us. If you intend to do it yourself sometime in the next 5 years, you should tell us. Any way you cut it, we're in the dark right now.

[Grauenwolf]

One of the related tickets referenced an ASP. NET community stand-up. Supposedly it was announced in it that gRPC is the way forward, but I didn't want to watch an hour long video for two seconds of questionable info.

It's not important though, what we need is an official announcement.

[2mik]

It's a comedy of errors over at the project management side that this still hasn't been decided either way. If people need to make breaking changes to switch over to .NET Core, you should tell us. If you need volunteers to port code to .NET Core, you should tell us. If you intend to do it yourself sometime in the next 5 years, you should tell us. Any way you cut it, we're in the dark right now.

They just do not know themselves ))

[Lexcess]

I don't think it is that unclear. MS currently don't see the ROI in porting WCF themselves, that doesn't mean they never will, but in the foreseeable future it is the community who will have to do the heavy lifting. I imagine gRPC is mentioned because one big .Net Core gap covered by WCF was binary communication.

The old alternative was MS stopped investing and the technology was locked behind a closed door to fade away. I would try and take the positive angle, in that at least MS is leaving the door open for the community to bring WCF to .Net Core.

I no longer have skin in the WCF game, but it seems like many people do. That goodwill could be harnessed if somebody could help coordinate to get the ball rolling. Things like listing issues, sort out the build chain, organise an initial direction and set some achievable milestones. I would also suggest perhaps reaching out to former WCF/project Indigo staff like Don Box. I imagine Don would not want to get directly involved, but he might be able to suggest names of people who would like to see WCF as a viable concern again. You are more likely to get advice that way, than from the current ASP.Net or .Net Core teams.

@Grauenwolf seems to have had a go at forking and hit a few hurdles. Perhaps a starting point could be to help him get it building. I do think somebody is going to shoulder the burden of pushing this, but if there is a repo with buildable code at least people can contribute and start chipping away at the problem.

Who knows if there is sufficient activity behind this, maybe MS or the DotNet Foundation will lend a hand?

[dgxhubbard]

Quite a few people here have offered to help. To my understanding WCF for core is only the client side on github. If MS would open source WCF Server we can all lend a hand.

[Grauenwolf]

Reference Source should have a copy that we could start from.

[Lexcess]

@dgxhubbard The source I was referring to was the reference source MS released years ago. I believe that is what @Grauenwolf had a go at building. There are also some other areas of code released to support the client code that might help the server implementation.

I think the biggest thing which is missing (apart from the stuff actually building) is the unit tests, I remember the Indigo team at the time saying they had great test coverage, if those could be resurrected it would be a massive boost. I suspect they are not in the reference code though.

edit: I see @grauenwolf confirmed posting at the same time.

[Grauenwolf]

Here are the (current?) build instructions.

https://github.com/dotnet/wcf/blob/master/Documentation/developer-guide.md#building-the-repository

Looks like it ran clean on my machine.

Here is the starting point for the code we need to import

https://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/ServiceHost.cs,a4183a8b92082596

Do we have any GitHub ninjas willing to create the fork? (I'll do it if no one else volunteers but I would rather have someone who already knows how to keep it sync'd with official repo.)

[Grauenwolf]

I remember the problem I ran into now. No matter which solution I open, there are a lot of files being reported as missing. Anyone know what's up with that?

[Grauenwolf]

This is what I'm seeing in the project file for the missing files:

<ReferenceFromRuntime Include="System.ServiceModel.Security" />

What's a ReferenceFromRuntime?

ref: https://stackoverflow.com/questions/55526994/in-a-c-sharp-project-what-is-a-referencefromruntime

[Grauenwolf]

Tests may not be as hard as they seem.

SelfHostedWCFService is a .NET 4.x project I assume works with the existing tests. So if we build a SelfHostedWCFServiceCore service and point the tests at it, that covers a lot of the use cases.

[Grauenwolf]

Opened a separate bug regarding the build problems. https://github.com/dotnet/wcf/issues/3546

[Lexcess]

So the reference source isn't really meant to be built as such, since it contains the BCL amongst other things. MS offer a downloadable version that actually has some CSProj files and other dummy content to cover for files that haven't been open sourced in the repository. This version will at least open in Visual Studio (but still mostly not build).

Anyway, although as I said I probably can't help too much with this initiative, but in the spirit of being the change you want to see in the world I've done the following:

• I've downloaded the 4.7.2 .Net version of the reference source
• I've separated out the main WCF and System.Model internals
• I've uploaded to a new Repo and org on GitHub
• I've created a blank sln file
• I've created a public open source Azure Dev Ops instance
• I've created a build pipeline that 'builds' the sln file with dotnet build command
  
  
  
  • It is running on a brand new Win2019 agent with VS2019
  
  
• I've added a build bot that will build any PR if a team member invokes the build bot in the comments
  
  
  
  • /azp run see here for more details
  
  

Have a look see if you want to contribute. I'll setup some basic milestones and github setup stuff, but really it the community who will have to help make this a reality. I am unfortunately busy this weekend, but if people want to fork and start having a look at getting it running the following might be useful:

• The CSProj files need stripping and turning in SDK based .Net core projects
• Project references need to be turned into regular assembly references (or excluded for MSCorLib etc)
• These projects then need adding to the sln
• Unbreak all the things
• Bring in the already ported .Net Core/Standard code and exclude overlapping reference code
  
  
  
  • This is the dotnet/wcf code @Grauenwolf is referring to above
  
  
• We might need to re-namespace some code
  
  
  
  • this is almost mandatory if we want this to be .Net standard as it will heavily overlap with .Net FX and Mono.
    
    -Lets see where it gets to with core for now.
  
  

I should be around to validate PR build requests.

Lastly, I would say that if people do want to start looking into this, please don't try and refactor or improve things. We need this code to stay as similar to the existing WCF code at least until it builds and ideally has a few tests. It'll also make it way harder to bring in future updates from the reference source if even internal code starts moving around.

Git org + Repo: https://github.com/indigo-net/indigo-net
Azure DevOps: https://dev.azure.com/indigo-net/indigo-net/_build?definitionId=1

[Grauenwolf]

In case I was unclear, my complaint is that I can not build the Core version of WCF in Visual Studio.

[Lexcess]

In case I was unclear, my complaint is that I can not build the Core version of WCF in Visual Studio.

The current Core version only covers the components necessary for the client. This issue is around Server-Side WCF. I would hope that the dotnet/wcf maintainers will help you with your build issue there.

[mconnew]

@Grauenwolf, not being able to do full development in VS has been a very frustrating problem. There is a solution in sight. There's work being done on the AdoptArcade branch which converts all the projects to be regular .NET Core SDK based projects which will make VS compilation work. It's not ready for general usage yet and documentation also needs to be created but it will be ready soon. Until that's merged into master, you can develop in VS if you run sync.cmd and build.cmd on the command line first. Then when you load System.Private.ServiceModel.csproj into VS, all the code validation, navigation and refactoring will work. You just need to go back to command line again and run build.cmd when you want to actually build it. So while it's frustrating and annoying right now, it's workable.

[Lexcess]

After spending some time searching through related dotnet repos on how a port might work, I think there might be a hint of movement on WCF or at least something like it.

Given the massive effort it will take to port WCF server, and having waited years already, I'm tempted to wait a bit longer. At least until the post Core 3.0 plans are announced.

[cbenard]

Well they just introduced .NET 5 and the future of .NET.

.Net Framework is officially dead and we are officially marooned as far as WCF server is concerned.

In the words of Scott:

After .NET Core 3.0 we will not port any more features from .NET Framework. If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. If you are a remoting or WCF developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC (Google RPC, which provides cross platform and cross programming language contract based RPCs).

[mconnew]

@cbenard, WCF has a different place in the .NET Core world than .NET Framework. If you install the .NET Core Runtime, you basically get coreclr and corefx (and in 3.0 asp.net core) which is an analog to the .NET Framework which you have installed on your Windows machine. If you want to use WCF (which is currently client only), you need to explicitly add the WCF nuget packages which need to be downloaded. WCF doesn't come with .NET Core. WCF does come with .NET Framework in-box. So you can see WCF is released separately from .NET Core. That statement from Scott isn't talking about this WCF repo as WCF is now separate from .NET and is more like an external library than a part of the framework. Although I can't say anything at this time specifically about server-side WCF, the door isn't closed for porting more WCF features over and we do want to support more scenarios.

[dgxhubbard]

Scott's statement says one thing, "Have fun with gRPC!". I wish the people who made this decision had to also code with gRPC and replace some of the WCF server services, to see exactly what this statement means. .Net core 3 and beyond adoption is going to be pot hole filled road. We are going to have to rewrite our services to mimic WCF, so our adoption of .Net Core 3 and beyond will be shelved for awhile.

[cbenard]

We are going to have to rewrite our services to mimic WCF, so our adoption of .Net Core 3 and beyond will be shelved for awhile.

Same here. I don't see how gRPC is anywhere near a drop-in replacement. One of the huge selling features of WCF was ability to share DLLs between server and client side, filled with models and interfaces for the service contracts. gRPC relies on proxy generation, from what I can see. Some of our services store copies of serialized objects that we re-hydrate for use later. I don't see how gRPC is going to enable any of that.

I really don't want to go down the road of manually using NetDataContractSerializer and forcing the bytes down a gRPC pipe or something (~does NetDataContractSerializer even exist in Core? I hope/assume so~ It does not. But DataContractSerializer does). One more thing not supported from the full Framework).

The contracts aren't the huge deal to me. It's the model sharing between server/client with the same DLLs.

Also, the ability to have multiple endpoints on a single ServiceHost. We can have TransportSecurity on one Endpoint and MessageSecurity on another. We've used this to update the way we do security on the endpoints. None of this appears to be supported by gRPC.

Not to mention, we have institutional customers who have to open outbound ports one by one, and we can't just migrate on the same port to the cluster with gRPC.

This all means .Net Core is out of reach on the server side for quite some time. Thank god I've never been using WS-Security or anything on the client side, so I'm not stuck there, yet, I don't think. However, I'd have to retarget the server-side DLLs that are shared to netstandard2.0 and then try to see how that works between Core WCF client and Framework WCF server.

TLDR: This is a nightmare. I will sorely miss the full Framework.

Double edit: LOL gRPC doesn't even support named pipes for local cross-process remoting. Things I took for granted in WCF... Wow.

[Grauenwolf]

Although I can't say anything at this time specifically about server-side WCF

Ok, who can?

This has been dragging on for years. We need to know definitively whether or not server-side WCF is dead. And if it is, what is the real alternative because gRPC is clearly not it.

[cbenard]

Ok, who can?

@Grauenwolf, see my replies above. It's dead. Scott said to use gRPC or pound sand. He explicitly said no new features will be ported from .Net Framework.

It's dead, Jim.

[RyoukoKonpaku]

Magic Onion shows promise, from the same developer that made Message Pack and it uses gRPC under the hood for transport but doesn't need .proto IDL files as it uses Message Pack instead of protobuffers.

Though it does still miss things that WCF has in terms of features so it's not a full drop-in replacement either but it's at least more similar to WCF compared to gRPC-dotnet. I do hope at least we get some kind of closure here after years of waiting, a simple Yes or No so that we're not left hanging (a part of me still wants a server side port but it looks kinda bleak now).

[mconnew]

Scott Hunter said in a twitch stream yesterday that there's something in the works. I know it's been a long wait, and all I can say at this time is please have a little bit more patience and that WCF isn't dead.

[CSharpenter]

Has anyone considered Mono's implementation of WCF ServiceHost? Sure, it is a very small subset of .NET Fx's ServiceHost, but it might be a better choice as in a starting point rather than MS' "Reference Source" plus Mono is already cross platform, so its design might be a better choice for porting it to .NET Core.

[Lexcess]

@mconnew It would be really good to have some direction to get us out of the current limbo. It's not like this is an unknown technology, porting is a lot of work sure, but this position prevents a community coming together to do something themselves.

@CSharpenter That is actually a pretty reasonable suggestion. The lack of test suites and non-buildable code isn't a pleasant situation. Thinking further on, it might also be worth finding out exactly what will happen to Mono's implementation now that their BCL is going away. The Xamarin guys have promised they won't break anyone with .Net 5. If that is the case then they may be forced into porting what they have onto CoreFX anyway.

[CSharpenter]

@mconnew It would be really good to have some direction to get us out of the current limbo. It's not like this is an unknown technology, porting is a lot of work sure, but this position prevents a community coming together to do something themselves.

@CSharpenter That is actually a pretty reasonable suggestion. The lack of test suites and non-buildable code isn't a pleasant situation. Thinking further on, it might also be worth finding out exactly what will happen to Mono's implementation now that their BCL is going away. The Xamarin guys have promised they won't break anyone with .Net 5. If that is the case then they may be forced into porting what they have onto CoreFX anyway.

I'm sure Xamarin's promise is an honest one, but I'm afraid it is possible to fall under the pressure and influence of MS' marketing politics to put .NET Core as the "chosen Fx"

[ghost]

In a similar boat here, except we have used WS-SecureConversation on WCF for our paying customers (thousands of them), and now need a way to support that interface for long enough to migrate all those customers to something RESTful/JSON, which will be several years.

This appears to exceed the lifetime of .NET Framework, so I've been looking at SoapCore to provide the base protocol support, and emulating WS-SecureConversation to the point where customers code works, or something more drastic such as moving to Apache CXF on Java. Our challenge is not the local code base (although the least amount of work the better as it's eventually going to get binned), it's maintaining a 100% compatible WSDL/SOAP API for customers.

I have other reasons to emulate WS-SecureConversation, the poor/undocumented session management code in WCF that has killed our service a number of times with unexpected total failure (nothing graceful about running out of sessions you didn't know existed!), but that's a separate problem.

[Lexcess]

@PhlashGBG If your concern is primarily .Net Framework support being pulled you are almost certainly ok. Right now .Net 4.x is actively supported with Windows and has no end date for support.

This discussion is more about wanting WCF to fix the gaps in .Net Cores stack, use modern .Net Core tooling for WCF development and see active feature development of WCF.

If you want a more concrete expectation: .Net 3.5 was just divorced from Windows support as of Windows Server 2019 and Windows 10 1809. It is receiving five years of mainstream support followed by five years of Extended support. That is for a product that launched in 2007. Details here.

If it is of interest, .Net Core instead has policy around Long Term Support releases. That states that LTS releases are supported for three years or one year after the subsequent LTS release (whichever is longer). Or to put it another way, Net Framework 3.5 will have support longer than .Net Core 3.0 when it releases later this year. Details here.

[ghost]

@Lexcess thanks for the response, it was partly the longevity of Framework and WCF as-is, however the dependencies this brings impact our Microservices strategy - obviously a separate discussion but decisions in this space would be easier if we have a clear statement on support for WCF server-side on .NET 5+ :)

[mconnew]

@PhlashGBG, here's the page which describes the support lifecycle. I'll quote the relevant section here for convenience:

Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed.

So if you want a lower bound, look at the latest EOL date for all released Windows OS's (Server has the longest lifecycle). Each time a new Windows Server version is released, the EOL date for .NET gets extended. So basically, if you are happy staying on .NET 4.x for the foreseeable future, you don't need to worry.
I'm confident you will have a migration option for .NET Core well before that's a problem. Feel free to read between those lines but I can't say more right this moment 😉.

[Lexcess]

@PhlashGBG I'd agree it'd be nice to have a clear statement!

If I would recommend anything for now it would be to try and separate code relating to your domain from WCF code, even if that results in duplication of your model (in fact that sort of duplication can be a good thing), porting it over to .Net Standard. Then you can layer on a potential WCF.Next, SOAPCore or even WebAPI based on the situation at that time rather than worrying too much about it now.

[Grauenwolf]

The ironic thing is that the whole point of WCF was to detach the domain logic from the communication logic. The promise was that I'd we slap on this WCF abstraction layer now, we can sort out the communication later.

Now it looks like we're having to abstract the abstraction. And we all know where that rabbit hole leads.

[cbenard]

Anyway, although as I said I probably can't help too much with this initiative, but in the spirit of being the change you want to see in the world I've done the following:

• I've downloaded the 4.7.2 .Net version of the reference source

...
Have a look see if you want to contribute.

@Lexcess I honestly was/am considering working on this in my limited spare time. You've probably seen me freaking out in MS blog comments about them killing WCF. However, you made the LICENSE file MIT. I don't think you can just relicense this.

I was thinking MIT didn't sound right for an MS license, so I went to look for the Reference Source license, and what I found seems like it kills this possibility. Am I correct?

The Reference Source is licensed under the Microsoft Reference Source License (MS-RSL).

It specifically says:

"Reference use" means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

And:

(A) Copyright Grant- Subject to the terms of this license, the Licensor grants you a non-transferable, non-exclusive, worldwide, royalty-free copyright license to reproduce the software for reference use.

It seems they are specifically disallowing us the ability to port this software. Is this something anyone in this thread can work with MS about to get ServiceModel and its dependents relicensed to let the community port it? Otherwise, we're stuck with Mono as a base, and it's not feature-complete at all.

So, TLDR: 2 major issues:

1. You can't just relicense the Reference Source to MIT
2. The actual license precludes us from taking on this project, in my opinion/reading of it

[Lexcess]

@cbenard https://github.com/microsoft/referencesource/blob/master/LICENSE.txt

[cbenard]

https://github.com/microsoft/referencesource/blob/master/LICENSE.txt

How/why does this conflict with https://referencesource.microsoft.com/'s license? Very odd. Thank you for the clarification.

[mconnew]

@cbenard, a copyright holder can release their code under as many licenses as they wish, as they hold the copyright (obligatory IANAL but I think I'm safe on this one) so there's no conflict. If you aren't the copyright holder, you can't re-release the code under a different license, but the copyright holder can. Microsoft originally released the code with a license of "look, don't touch". In other words, everyone is de-compiling the code anyway and there's no harm in people knowing what the code does so might as well let people see the code which hasn't been butchered by a decompiler, but the company culture wasn't yet ready to yield control of the code. My understanding is reference source was originally released under MIT license to enable the Mono team to copy/paste large chunks of it across to make their life easier and improve compatibility and fill in gaps. This was once the company had a more enlightened view of open source and understood the benefit of letting other people play with your toys.
The volume of opinions that was made after //Build was heard, I promise. Please have a little bit more patience. Large corporate cogs sometimes can be big and heavy and take a lot of effort to turn, and then can be slow moving. Scott Hunter announced on twitch during Build that something is in the works, and it is.

[mconnew]

Please see the announcement blog posts:
https://devblogs.microsoft.com/dotnet/supporting-the-community-with-wf-and-wcf-oss-projects/
https://dotnetfoundation.org/blog/2019/06/07/welcoming-core-wcf-to-the-net-foundation

The repo can be found at https://github.com/CoreWCF/CoreWCF

[Lexcess]

Good to see this is finally happening. I hope despite the time and delays it has taken the community can rally around this.