Skip to content
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

Call for Decision: Server-Side WCF #2695

Open
hivanov opened this issue Mar 20, 2018 · 56 comments

Comments

Projects
None yet
@hivanov
Copy link

commented Mar 20, 2018

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?

@Lxiamail Lxiamail added this to the S133 milestone Mar 26, 2018

@Lxiamail Lxiamail modified the milestones: S133, S134 Apr 6, 2018

@curiousdev

This comment has been minimized.

Copy link

commented May 3, 2018

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

@Lxiamail Lxiamail modified the milestones: S134, S135 May 11, 2018

@Lxiamail Lxiamail modified the milestones: S135, S136 May 18, 2018

@CDuke

This comment has been minimized.

Copy link

commented Jun 1, 2018

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

@Lxiamail Lxiamail assigned glennc and unassigned csharpfritz Jul 5, 2018

@Lxiamail Lxiamail modified the milestones: S136, 3.0 Jul 5, 2018

@Grauenwolf

This comment has been minimized.

Copy link

commented Aug 12, 2018

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

This comment has been minimized.

Copy link

commented Aug 12, 2018

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

This comment has been minimized.

Copy link

commented Aug 24, 2018

Count me in too please.

@Lexcess

This comment has been minimized.

Copy link

commented Aug 28, 2018

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

This comment has been minimized.

Copy link

commented Aug 29, 2018

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

This comment has been minimized.

Copy link

commented Aug 29, 2018

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

This comment has been minimized.

Copy link

commented Aug 30, 2018

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

@shyaamsundhar

This comment has been minimized.

Copy link

commented Sep 26, 2018

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

@totht91

This comment has been minimized.

Copy link

commented Nov 8, 2018

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

This comment has been minimized.

Copy link

commented Nov 9, 2018

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

@Danielku15

This comment has been minimized.

Copy link

commented Nov 14, 2018

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

This comment has been minimized.

Copy link

commented Nov 16, 2018

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

This comment has been minimized.

Copy link

commented Nov 16, 2018

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

@dgxhubbard

This comment has been minimized.

Copy link

commented Apr 4, 2019

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

This comment has been minimized.

Copy link

commented Apr 4, 2019

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

@Lexcess

This comment has been minimized.

Copy link

commented Apr 4, 2019

@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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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 comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

Opened a separate bug regarding the build problems. #3546

@Lexcess

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

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

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

@Lexcess

This comment has been minimized.

Copy link

commented Apr 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 7, 2019

@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

This comment has been minimized.

Copy link

commented Apr 10, 2019

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

This comment has been minimized.

Copy link

commented May 7, 2019

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

This comment has been minimized.

Copy link
Member

commented May 7, 2019

@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

This comment has been minimized.

Copy link

commented May 7, 2019

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

This comment has been minimized.

Copy link

commented May 7, 2019

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

This comment has been minimized.

Copy link

commented May 8, 2019

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

This comment has been minimized.

Copy link

commented May 8, 2019

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

This comment has been minimized.

Copy link

commented May 10, 2019

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

This comment has been minimized.

Copy link
Member

commented May 10, 2019

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

This comment has been minimized.

Copy link

commented May 10, 2019

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

This comment has been minimized.

Copy link

commented May 10, 2019

@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

This comment has been minimized.

Copy link

commented May 10, 2019

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

@PhlashGBG

This comment has been minimized.

Copy link

commented May 14, 2019

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

This comment has been minimized.

Copy link

commented May 14, 2019

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

@PhlashGBG

This comment has been minimized.

Copy link

commented May 14, 2019

@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

This comment has been minimized.

Copy link
Member

commented May 14, 2019

@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

This comment has been minimized.

Copy link

commented May 14, 2019

@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

This comment has been minimized.

Copy link

commented May 14, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.