The time has come to start saying goodbye to Windows Communication Foundation (WCF). Yes, there are plenty of WCF apps in the wild — and I’ve built a number of them. But when it comes to selecting a web services stack for greenfield applications, you should no longer use WCF.
Note: A number of commenters have misunderstood the nuanced position I’ve taken in this blog post, so I thought it would help to add a statement at the beginning clarifying my position on WCF. I am not saying that WCF is going away or that you should discontinue using it for non-HTTP communication, such as MSMQ or Named Pipes, or where SOAP is a requirement. I am also not saying that most WCF apps should be re-written; on the contrary, they will need to be maintained to support SOAP-based clients. What I am saying is that, if you plan to build a greenfield HTTP-based web service, you should seriously consider using ASP.NET Core instead of WCF or ASP.NET Web API 2.x, because it is cross-platform, modular and designed for Cloud-based deployment, and it supports modern development methodologies where dependency injection is an essential requirement.
Update: ASP.NET 5 has been renamed to ASP.NET Core 1.0 and MVC 6 is now called MVC Core 1.0.
WCF is dead
There are many reasons why WCF has lost its luster, but the bottom line is that WCF was written for a bygone era and the world has moved on. There are some use cases where it still might make sense to use WCF, for example, message queuing applications where WCF provides a clean abstraction layer over MSMQ, or inter / intra process applications where using WCF with named pipes is a better choice than .NET Remoting. But for developing modern HTTP-based web services, WCF should be considered deprecated for this purpose.
Didn’t get the memo? Unfortunately, Microsoft is not in the habit of announcing when they are no longer recommending a specific technology for new application development. Sometimes there’s a tweet, blog post or press release, as when Bob Muglia famously stated that Microsoft’s Silverlight strategy had “shifted,” but there hasn’t to my knowledge been word from Microsoft that WCF is no longer recommended for building modern HTTP-based web services.
One reason might be that countless web services have been built using WCF since its debut in 2007 with .NET 3.0 on Windows Vista, and other frameworks, such as WCF Data Services, WCF RIA Services, and self-hosted Web API’s, have been built on top of WCF. Also, if you need to interoperate with existing SOAP-based web services, you’re going to want to use WCF rather than handcrafted SOAP messages.
But it’s fair to say that the vision of a world of interoperable web services based on a widely accepted set of SOAP standards has generally failed to materialize. The story, however, is not so much about the failure of SOAP to gain wide acceptance, as it is about the success of HTTP as a platform for interconnected services based on the infrastructure of the World Wide Web, which has been codified in an architectural style called REST. The principle design objective for WCF was to provide a comprehensive platform and toolchain for developing service-oriented applications that are highly configurable and independent of the underlying transport, whereas the goal of REST-ful applications is to leverage the capabilities of HTTP for producing and consuming web services.
But doesn’t WCF support REST?
Yes it does, but aside from the fact that REST support in WCF has always felt tacked on, WCF has problems of its own. First, WCF in general is way too complicated. There are too many knobs and dials to turn, and you have to be somewhat of an expert to build WCF services that are secure, performant and scalable. Many times, for example, I have seen WCF apps configured to use the least performant bindings when it wasn’t necessary. And setting things up correctly requires advanced knowledge of encoders, multi-threading and concurrency. Second, WCF was not designed to be friendly to modern development techniques, such as dependency injection, and WCF service types require a custom service behavior to use DI.
One of the first signs that WCF was in trouble was when the Web API team opted for using ASP.NET MVC rather than WCF for services hosted by IIS (although under the covers “self-hosted” Web API’s (for example, those hosted by Windows services) were still coupled to WCF). ASP.NET Web API offers a much simpler approach to developing and consuming REST-ful web services, with programmatic control over all aspects of HTTP, and it was designed to play nice with dependency injection for greater flexibility and testability.
Nevertheless, ASP.NET Web API duplicated many aspects of ASP.NET MVC (for example, routing) and it was still coupled to the underlying host. For example, Web API apps requiring secure communication over TLS / SSL required a different setup depending on whether the app was hosted in IIS or self-hosted. To address the coupling issue, Microsoft released an implementation of the OWIN specification called Katana, which offers components for building host-independent web apps and a middleware-based pipeline for inserting cross-cutting concerns regardless of the host.
Web API is dying – Long live MVC 6!
As awesome as ASP.NET Web API and Katana are, they were released mainly as a stopgap measure while an entirely new web platform was being built from the ground up. That platform is ASP.NET 5 with MVC 6, which merges Web API with MVC into a unified model with shared infrastructure for things like routing and dependency injection. While OWIN web hosting for Web API retained a dependency on System.Web.dll (along with significant per-request overhead), ASP.NET 5 offers complete liberation from the shackles of legacy ASP.NET.
More importantly, ASP.NET 5 was designed to be lightweight, modular and portable across Windows, Mac OSX and Linux. It can run on a scaled down version of the .NET Framework, called .NET Core, which is also cross-platform and consists of both a runtime and a set of base class libraries, both of which are bin-deployable so they can be upgraded without affecting other .NET apps on the same machine. All of this is intended to make ASP.NET 5 cloud-friendly and suitable for a microservices architecture using container services such as Docker.
So when can I start building Web API’s with ASP.NET 5 and MVC6?
The answer is: right now! When RC1 of ASP.NET 5 was released in Nov 2015, it came with a “go-live” license and permission to use it in a production environment with full support from Microsoft.
Instead of hosting on IIS, which of course only runs on Windows, you’ll want to take advantage of Kestrel, a high-performance cross-platform host that clocks at over 700,000 requests per second, which is about 5 times faster than NodeJs using the same benchmark parameters.
Shiny new tools
Not only has Microsoft opened up to deploying ASP.NET 5 apps on non-Windows platforms, it has also come out with a new cross-platform code editor called Visual Studio Code, which you can use to develop both ASP.NET 5 and NodeJs apps on Mac OSX, Linux or Windows.
ASP.NET 5 is also released as open source and is hosted on GitHub, where you can clone the repositories, ask questions, submit bug reports, and even contribute to the code base.
If you’re interested in learning more about developing cross-platform web apps for ASP.NET 5, be sure to check out my 4-part blog series on building ASP.NET 5 apps for Mac OSX and Linux and deploying them to the Cloud using Docker containers.
In summary, you should avoid WCF if you want to develop REST-ful web services with libraries and tools that support modern development approaches and can be readily consumed by a variety of clients, including web and mobile applications. However, you’re going to want to skip right over ASP.NET Web API and go straight to ASP.NET Core, so that you can build cross-platform web services that are entirely host-independent and can achieve economies of scale when deployed to the Cloud.
Tony Sneed's Blog 
Hi Tony, Would you also discourage new projects in WPF? It looks like ASP.Net MVC is getting the lion’s share of investment, and WPF is getting little. Would you start a new project in WPF?
(I am a Simple MVVM user and fan.)
Great question, and a complete answer deserves another blog post. :-)) But I can respond briefly here … For Windows desktop apps, WPF is alive and well, especially since there is still a large installed base of Win7, 8, 8.1. But on the horizon is the Universal Windows Platform, the successor to WinRT, which offers the ability to deploy via the Windows app store and run on devices as well. But I don’t think UWP has feature parity with WPF, which is a rich UI platform and can be used to build quite sophisticated Windows desktop apps.
BTW, I am looking at revamping Simple MVVM for UWP apps — and I would love some help with that effort. 🙂
I don’t think it’s a good time to personally invest in more XAML technologies, since they’re not cross-platform, and I’m unconvinced that Microsoft is committed to it long-term. My plan is to spend most of my time maintaining my WPF LOB applications and learning MVC6 for future projects (or ASP.Net Core.1 – Can’t they think of a sexier name than that?)
Can desktop app use MVC 6? what about duplex channel communication? It’s so ridiculous about the name WCF – Windows Communication Foundation, it’s a very nice name (along with Windows Presentation Foundation, Windows Workflow Foundation, …) but it’s going to be dead? If so it’s totally a failure in Microsoft’s development path. I don’t believe what you said here. We cannot just put a lot of time into something and just throw it away like that. For such as Windows Forms, when it went away, WPF became an official replacement. For WCF, if it went away, there should have been another one replacing it but I don’t think it would have been MVC. Finally I would say that WCF is never easy as well as the networking and security issue, so it’s not just because of its own complexity (and only for expert), it’s just because of the complexity of networking, threading and security – which are never easy to any developer. We need time to experience and become skillful about it.
Hello @VipHaLongPro, Let me respond to each of your points.
I take it your question is whether a desktop app can host an MVC 6 service. Technically this is possible, but I would not recommend it. This is a case where would use WCF, because, as I stated at the beginning of the post, WCF is still a good choice for certain use cases, one of which is inter or intra process communication using named pipes. I’m not saying WCF should never be used, but I would say it should be considered “dead” for building new (greenfield) web services.
Note that it is possible to host an MVC 6 web service in a windows service. Here is an article on how to do that.
Is is possible to achieve this with MVC 6 as well. Duplex in WCF is simply two services using one-way message exchange patterns. This can be replicated in MVC 6 using HttpClient on both ends.
Unfortunately, this is the reality of software development. Remember DCOM, MTS, COM+, Enterprise Services, ASMX, .NET Remoting? They were all succeeded by WCF, which was in turn succeeded by ASP.NET Web API, OWIN / Katana, and now by ASP.NET 5 and MVC 6.
Remember that WCF was released 9 years ago and was built with SOAP and XML at its core, and it does not play well with modern development techniques, such as dependency injection. Microsoft could have updated it to meet modern standards and development approaches, but it has chosen not to update it and instead focus on an entirely new web services platform which was built from the ground up to support development of RESTful services using modern patterns. Like I said, there is still a place for WCF when it comes to inter/intra-process and message queuing, but aside from those cases, new services should be developed using ASP.NET 5 with MVC 6.
The complexity of WCF went well beyond networking and security issues. It was relatively straightforward to create a WCF app, but you needed a high level of expertise to use it in a scalable fashion. One example would be choosing the correct binding. To get the best performance with .NET clients outside a firewall, you needed to create a custom binding, specifying an HTTP transport with a binary encoder. This is just one example — there are many more, including concurrency settings and async services, neither of which relates to networking or security.
This is not to say that greater expertise is also needed for MVC 6 when you wish to use it in a scalable fashion, but the level of expertise required in general is lower for MVC 6 than it is for WCF, mainly because MVC 6 (and also Web API) leverages the HTTP protocol, whereas WCF strives to be transport-independent and therefore requires more to be done in the platform space.
The answer here was even more valuable than the article, Great stuff put together. Thanks
:-)))
Now I understand why, as a WCF newbie, I was having problems with endpoint bindings, SOAP error messages and XML configs.
I tried a ASP.NET MVC5 Entity Framework 6 tutorial and I seemed to make faster progress. Thanks for your searchlight article.
lolz. You are not going to replace SOAP and the need for it with OWIN and MVC. (sound of spitting cool aide out). They solve different problems. Industry specific XML schemas that pretty much require SOAP are not going anywhere. True your next grinder clone will be better off running on MVC. WCF is only complicated if you are a millennial snow flake man bun skinny jeans tard that can’t handle reading a manual and spending about 20 minutes learning how bindings work.
So tell me, what is the most scalable WCF binding for use by .NET clients?
Hello Tony. We are making new desktop WPF big LOB app and need technology for n-tier. We have very big model, need custom functions (usually uses stored procs), need work with navigation properties and collections. dynamic data (open types). In future plans to connect to this tier not only desktop but also mobile, web sites, 3rd party systems. What can you reccomend now? Now we’we made some RnD propotypes and choosing between 3 :
1)your self-trackable entities
2)N-tier EF https://ntieref.codeplex.com/
3)Odata 4
To my mind every has its own advs and disadvs , every can be made on base of web api 2.2.
Because of the need of dynamic data and future connection of another apps and systems the main contender now is odata, also lots of components has out-of-the-box support for it (DevExpress grid for ex)
Also how this question corellates with this article and asp.net 5? As i get it main feature is .net core and ability to run from linux, but our web service layer is pretty heavy and need lots of references that may be wouldn work on .net core (ef 6, Devexpress DB libraries, own libraries, etc)
Thank you, i really appreciate your work and expertice.
Hello Andrey,
ASPNET 5 / MVC 6 does run on the full .NET Framework 4.6, so there’s nothing stopping you from using MVC 6 with Entity Framework 6, which is mature enough to give you everything you need, including good stored procedure support. I don’t know if N-Tier EF will work with MVC6, and I do believe that the OData team will eventually provide support for MVC 6, but we don’t know how far off into the future that might be.
While I am admittedly biased regarding Trackable Entities, it has great support for EF 6, including both designer-based (EDMX) and code-based (aka Code First) modeling. And it should be possible to build an MVC 6 web service that uses Trackable Entities with EF 6. In fact, I will be happy to come up with a sample for Trackable Entities with MVC 6! (Just stay tuned to this blog and you should soon see a post on it.)
If you decide to go with OData v4, you’ll need to use ASPNET Web API 2, but in that case I would recommend OWIN hosting, because it will be easier to migrate to MVC 6 in the future. I like a lot of what OData has to offer, but I’m not a huge fan of using IQueryable with web services because it’s a leaky abstraction. The big selling point of OData is its use of embedded links (the HATEOAS principle), which is great especially for data syndication. So there’s no reason why you’d have to choose between OData and a framework such as Trackable Entities. You could use both if you wanted to, for example, by leveraging OData for data syndication and then use TE for the rest.
Thank you for reply, i have few questions.
“ASPNET 5 / MVC 6 does run on the full .NET Framework 4.6”
I know that it works on 4.6 (end even more stable there) i meant that the only profit i found as WPF dev is crossplatform run of service, other pros is more for asp.net mvc developers. So the question was can i run my service on .net core maybe not now but in future. Maybe i missing something, what is another pros of using aspnet 5 for desktop dev?
As for Odata:
1) thank you about pointing on owin, though i dont get the profit vs using regular self host using ODataConventionModelBuilder yet, but i will read.
2)As for leaky abstraction – yes i’ve read about it. Btw i think its more the problem of client, not the server, for example there’s some clients for odata like Simple.OData.Client that provides its own methods to query service. But i dont know either its good cos its not using linq and can be painful when you decide to refactor. Ideally i see making some extension methods that use linq syntax but restricts some methods that not working in Odata to avoid leaky abstraction.
As for principles used in your TE its on the diametral other side – it has only strict service methods and sometimes its not conveniently to use it. Example: for every additional condition (give list of clients , but also started with letter “A”) you must make new method. IQarable good here. Also you can combine some condition rules from few methods on .net
Btw i had some success to pass some query to method along with other data in your TE. Took linq expression, serialised it to string, and deserialised in method, dont know whether its good practice though.
By syndication you meant exposing resources to 3rd party users ot also for your needs like mobile platform etc?
No problem, I’m happy to answer them.
I’m not sure I understand this point. WPF is a client-side UI stack — it has nothing to do with the web service stack on the other side of the wire. The client-side code in the WPF app will be exactly the same, regardless of whether you are using Web API v2 or MVC 6. Unfortunately, the name MVC implies a web UI, but in reality MVC 6 includes what Web API was all about, which is a web services stack. That’s probably the source of your misperception.
MVC 6 has value far beyond its cross-platform capabilities, which is why I recommend it for scenarios such as yours, in which your web services require the full capabilities of Entity Framework 6, which only runs on Windows. Architecturally, MVC 6 is superior to Web API v2, first, because there is no dependency on WCF when not hosting in IIS (Web API without OWIN couples you to WCF, which can haunt you when you need to configure SSL), and second, because there is no dependency on IIS as a web host or System.Web.dll, which carries significant per-request overhead. And in general, MVC 6 is designed to play well with cloud-based deployment models, even with Windows Server virtual machines.
As I mentioned above, the main advantage of OWIN over self-hosted Web API services, is that self-hosting in Web API uses WCF under the covers. OWIN allows for self-hosting without a dependency on WCF.
Whether you favor IQueryable depends on your preferences and needs. It’s an anti-pattern and I don’t care for it personally, but I can see how it could be useful.
If ad-hoc querying is important to you, this could be a viable solution — at least your query parameters won’t be part of the request URI and possibly expose sensitive information, which could be a problem with querying OData.
Content syndication is all about using a format such as RSS or AtomPub to provide data in a RESTful manner, that is, with embedded hyperlinks to aid in further queries. This is really what OData is all about, and I continue to recommend OData for this scenario. What I don’t recommend is using OData as a replacements for good Web API design based on your domain. A balanced approach might combine both OData and Web API’s in MVC 6, perhaps using Trackable Entities to track change-state across service boundaries.
I hope this helps!
“…which is a web services stack”
I meant that as a read about asp.net MVC it not only deals with web-service as logical tier for controllers, but also serves as service for exposing pages (may be thats why it still called MVC 🙂 And as i read about most of new features is about that (Tag Helpers, View Components, GruntJS, NPM etc) Yes also it provides out of the box DI mechanism and new testing framework but what was the difficultie to do it yourself when doing self host?
“Architecturally, MVC 6 is superior to Web API v2, first, because there is no dependency on WCF when not hosting in IIS”
Though my last project with Odata selfhost doesnt rely on WCF or IIS, but yes it needs System.Web. Asp.net 5 from Net4.6 doesnt use it? Ok i think i keep that in mind, thanks.
“If ad-hoc querying is important to you…”
Maybe i just missing something. Suppose we have huge model, classes with lots of properties, lots of navigation collections in them that could be loaded. We need to query some repository or maybe some method that already applied some filtration to repository (ie get list of all goods with quantity > 0) . But depending on different checkboxes, user settings, company settings the query need to differ, another filtration, grouping, include or not include some related collections. So as i get it with TE we have 3 options: 1) make separate functions for every such need or atleast some big part of logic 2)get all info and apply logic on client (could be huge traff and client load, but we have full linq and no leaky abstraction 3)calculate all this conditions like checkboxes, settings etc on server and return correct info, but for that also need to pass some object inside of methods)
Another common scenario when you want to query some big data but to show only first 100 rows in datagrid, then load more when scrolling, thats how i discover Odata – some controls like Devexpress have outofthebox capability for that, i know that theres Breeze.js and KendoUI for web. Btw there’s no leaky abstraction cos components takes responsibility of what methods to use and what info to query.
What you can recommend in such cases?
Can you please point to some links why IQueryable itself is anti-pattern. I can see when leaky abstraction is bad ie when some of the linq methods just dont work cos odata doesnt support them but could it be solved by making your own layer that defines what we can and what we cant do? As for security you can manipulate expressions to avoid injections as well as unauthorized access to certain properties on server.
Thanks again for replying, if its crapping your blog we can continue discussion via email, i have few more question regarding implementation of TE 🙂
If you were self-hosting with ASP.NET Web API, then **you were using WCF** under the covers but did not realize it. Try configuring it for SSL, and you’ll find out that you need to configure the WCF binding used by Web API.
Your options are not specific to TE but rather ASP.NET Web API (without OData). TE’s sweet spot is tracking change state across service boundaries when you wish to persist multiple updates in an object graph within a single transaction. But TE has no role to play when it comes to querying. However, the problem you’re describing can easily be solved with OData and is a good use case for it. The other option would be sending a query object from the client and have the service translate it into an EF query, as suggested by the SO answer.
That might be true if you had no other consumers of your web service. I’m not sure if even that would seal the leak. This post is the best I’ve read on the IQueryable anti-pattern.
In terms of security, I’m not talking about tampering, because SSL does protect the request URL, but it’s known that privacy cannot be assured because they can be recorded in server logs, so it’s not recommended you include sensitive data in query string parameters. With OData you just need to be a bit more careful about that.
I hope this discussion is beneficial for others, so I’m glad to have it on the blog. But I’m also happy to address TE questions, either by email or on the issues tab of the TE GutHub repo. The best way to exchange email might be for you to follow me on Twitter and send me a message there. I’ll follow you in turn, so we can exchange direct messages.
Hi Tony. Found your post is very helpful, as well as the discussion with Andrey Stepanov.
You mentioned that SOON you will have a sample for Trackable Entities with MVC 6! Any idea when? and the other question: how simple will be the changes if we start developing using the Web API?
thank you,
andrey
Hi Andrey, So glad you asked about it. There has been a great deal of churn with MVC 6 lately, which has been renamed to MVC Core 1.0 and is being updated to sit on top of DotNet CLI. But I think we’re at a point where I can come up with a sample for TE, as well as update the EF RC1 sample I did. So stay tuned here, and I’ll reply with a link to the new samples.
For more information on OWIN hosting, you can watching my WintellectNOW video. It’s a paid service, so be sure to use the promo code: SNEED-14.
Concerning migrating a vCurrent Web API to vNext, the migration will be easier if you use OWIN with a Startup class.
Thanks for your reply and promo code. Tried to watch the video. but get the message that promo code is expired.
I’ll check on the promo code. Instead, you can get a 3 month subscription to WintellectNOW by joining Visual Studio Dev Essentials, which is free.
Great Article!
What are your recommendations for people stuck on framework 4.0?
We are currently using WebApi v1 SelfHost (4.03) to expose POCO’s and Odata V3 support is weak.
I’m in the process of building a new n-tier model/DAL, based on a EF6 encapsulated as a remote repository and question the best\modern way to expose the entities over IP for remote CRUD with linq?
We are in control of the client software, so I can share the Model DLL, but transport & expression tree to verb support is really the question.
Any suggestions besides upgrading all my servers to gain Net 4.6 support ? 🙂
Regards,
Mike
@Mike:
For CRUD support I recommend either OData or my own Trackable Entities. The advantage of OData is its support for both change-tracking and IQueryable, which it sounds like you need. The disadvantage is that some people view it as a leaky abstraction and not as architecturally clean as implementing Repository and Unit of Work patterns. But if that’s not too much of a concern for you, you might want to stay with OData.
In terms of your web services stack, I would recommend you move to Web API v2 with OWIN and Katana, which allows you to use OData with a REST architecture but without any dependence on WCF for self-hosting (which is what you get with non-OWIN hosts).
You could also have a look at ASP.NET Core (vNext, aka ASP.NET 5), but it is still pre-release and is a complete re-write. It is possible to use EF 6 with ASP.NET Core, and I also have a sample of using Trackable Entities with ASP.NET Core.
If you are able to upgrade to .NET 4.6 from 4.0, I would recommend it, because you’ll benefit from support for async / await, which provides greater scalability when using EF 6.
I had seen Your Trackable Entities and another e-tier Entity Framework as possible solutions, Good to see you still recommend your own code today
Repository and Unit of Work pattern is exactly what I need, but one which is remote. I could resort to .Net Remoting, Nancy or other Proxy solutions, but again the point of the discussion was aligning for the future which seems to be WebApi. Just would have loved along with OSx and Linux support they would have included 4.0 support.
I would recommend you move to Web API v2 with OWIN and Katana, which allows you to use OData with a REST architecture but without any dependence on WCF for self-hosting (which is what you get with non-OWIN hosts).
I Agree, Just that I’m stuck in Framework 4.0 and as far as I can see Owin & Katana need 4.5 too. I love the newer async/await syntax, it was one of the main features of 4.5 release, I use it with 4.0 since Microsoft also released it as a Nuget package. I have rebuilt many 4.5+ projects with 4.0 and the Async BCL Lib, just not ready to take on the OWIN stack. I think they also added faster Socket handling in 4.5 which was the other reason most newer self-host stacks also shifted to 4.5.
Regards,
Mike Pisano
@Mike:
Trackable Entities includes remote support for Repository and Unit of Work using Web API (see this blog post). But Trackable Entities does require .NET 4.5, so it’s probably not an option for you.
The OS X and Linux support are for .NET Core, not .NET 4.x, which is Windows-only.
Yes, you would need to upgrade to .NET 4.5 or greater to get OWIN / Katana. If there were a way for you to upgrade your servers, it would be worth the effort because of compatibility with OWIN. The reason is that architecturally OWIN is similar to vNext and uses a Startup class with a middleware-based pipeline that is host independent. And, as I mentioned, the problem with self-hosting with Web API is that it uses WCF under the covers, and MS has stopped working on WCF. Coupling to WCF for self-hosted Web API’s becomes a problem when you want to implement security, because you need to do it in a WCF-specific manner, which makes your hosting options less flexible.
If you can wait until later this year, you could consider using ASP.NET Core, which will stabilize by then. But the problem there is that Entity Framework Core (aka EF 7) may not yet have all the features you need. If it does, you could use .NET Core and you would not have to upgrade your servers, because .NET Core is not installed on a machine but is instead copied to a directory.
We are currently upgrading our desktops from XP to 10, but the servers (40 across the globe) won’t be upgraded from 2003 until after the desktop upgrades are completed – So I have at least 2 more years until that starts and 3-4 until it’s all completed.
Sounds like Asp.Net Core is what I should be looking at, I just don’t know if it going to be supported on 2003 Servers older kernel and API’s. So my reading continues….
What was the “Last preferred way” of implementing a “Remote Repository” pattern? Keep in mind that my need for IP layer is across a VPN. My EF provider still relies on OleDb so my need for the Remote repository is to keep the SMB requests off the VPN and local, and the Expression tree/Results on the wire.
Thanks again for your insight
Regards,
Mike
@Mike:
According to this, you should be able to install .NET 4.5 on Windows Server 2003 without upgrading the OS. And according to this from Scott Hanselman, you should be able to install .NET 4.5 on your servers without affecting your exisitng .NET 4.0 apps, since 4.5 is supposed to be 100% (or maybe 99%) backwards compatible with 4.0.
I believe you should be able to use .NET Core on just about any version of Windows. It has it’s own CLR and BCL which are simply copied to a folder on the machine and not installed into the GAC. And while there is a central location for the Core CLR and BCL, it is also possible for an app to have its own version that is completely isolated from other apps.
The repository pattern is implemented server-side only. It is simply a way of insulating your service from any particular data access API, which enables you to more easily switch from one API to another without impacting the rest of your service. No there’s no relationship with network or serialization concerns. I recommend a generic implementation of Repo-UoW. Have a look at the source code for TrackableEntities.Patterns for an example (this library is not actually tied to Trackable Entities).
You would probably want to use some sort of Dependency Injection framework as well. I recommend Simple Injector for performance, features and documentation.
More info on .NET Core minimum Windows version .. According to this, and info from the team, min version is most likely Windows Server 2008 R2, although it would be interesting for someone to try to install it on an older version of Windows. 🙂
Thanks Tony, we are accustomed to these practices as software industry is still in its infancy and it will be a long time before it matures. On top of that software has to always play a catch up with the hardware! Now to your point there was a discussion about this about a year ago:
https://visualstudiomagazine.com/blogs/data-driver/2014/04/wcf-data-services-and-odata.aspx
@Bijan,
Thanks for the article on WCF Data Services. Although it relates to WCF Data Services, and not to WCF itself, the shift to Web API was an indicator that MS was moving away from WCF and SOAP, toward a more RESTful approach that focused on HTTP. But so far I haven’t seen many indications from MS that it considers WCF a dead technology, although all the signs point to this reality, including OData. Cheers.
I can see what you’re saying about WCF not being a great solution for REST (it isn’t, and I don’t think it was really was intended to be – Microsofts biggest mistake was trying to bake REST into WCF instead of just directly pushing out a framework like WebAPI to meet that particular need), but in contrast WebAPI is not a great solution for distributed architectures. It seems like you’re making a really broad generalization about this framework without addressing its core purpose and how it’s ‘replacement’ meets those needs. Azure is built on WCF, not WebAPI, for a reason and it seems unlikely that Microsoft would deprecate a framework that is making their core strategic product possible.
Hi Jeff,
Thanks for your insightful comment. I agree with your statement about REST support in WCF — it was never a natural fit, mainly because WCF was designed at its heart to be transport-independent and a unification of disparate networking API’s on the Windows platform.
Assuming you’re referring to Web API (not WCF), let me see if I can add some clarification. Web API had a number of design goals, but its main purpose was to provide a first-class API for HTTP to aid in building RESTful services, and to incorporate modern programming principles, such as greater modularity and support for dependency injection to enable looser coupling and greater testability. The replacement for Web API, which is MVC Core (aka ASP.NET 5 with MVC 6), accomplishes all these same goals, but it adds better compatibility with Cloud-based architectures, because it is completely host-independent (no dependency on WCF for self-hosting and no dependency on System.Web.dll), cross-platform (and deployable as a microservice on Linux or Windows via Docker), and bin-deployable (CoreCLR and CoreFx are not installed machine-wide). The other problem with Web API is that it duplicated many constructs from MVC 5, such as filters, routing, DI and configuration. MVC Core completely eliminates that duplication with a single unified web stack.
That’s an interesting one. “Deprecate” might be too strong a word to characterize MS’s stance toward WCF. A more accurate depiction might be that MS is not investing in further development of WCF and is instead urging the use of ASP.NET Core for new web development. That means WCF will continue to have a prominent place in legacy applications and services, including Azure. But you can bet MS will not use WCF for the next iteration of Azure — they’re going to want to dogfood ASP.NET Core on Azure.
Cheers, Tony
The piece that still seems to be missing there is “distributed”. I’m sure you can make a .NET core host communicate with another .NET core host, but I haven’t seen anything that demonstrates a robust communication infrastructure built in to or built around this new concept. Their goals seem to be more about small, lightweight, cross-platform execution with a modernized and more granular programming model (which is great!), but not necessarily about distributing functionality or building a true micro-service infrastructure. I haven’t delved into the .NET core element as much as you have, but I can’t find any answers to these basic questions– Question 1: How would you execute a transaction across two .NET core hosts? Question 2: How would one .NET core host discover and address another .NET core host? Question 3: How do you abstract the communication channel from the message with .NET core to keep yourself properly insulated from changes at either level? Question 4: How do you deal with call queuing? (I think you mentioned this as a specific use-case for WCF in your article above). The list could go on, but you get the gyst of it.
.NET core seems to have the potential to under-gird a new iteration of WCF (for example, augmenting its hosting model to include .NET core as an option), so I’d put my money on the development of “WCF core” as a framework that sits on top of .NET core rather than .NET core replacing WCF altogether. The scope of the core framework and its design goals just don’t lend themselves towards this.
For microservices with a robust infrastructure, MS is relying on external factors, such as Docker and all of the service orchestration tools that go with it, which are designed to play well with Cloud-based architectures. These replace all the WS-* specs that were designed to provide things like distributed transactions and reliable messaging.
And actually, that got me thinking along those lines and I stumbled across this. It looks like efforts may already be underway towards fleshing out “WCF Core”. I haven’t looked at the bits yet, but this does look very relevant to the conversation.
https://www.dotnetfoundation.org/blog/wcf-is-open-source
“We’re excited to announce a new open source project on GitHub from the WCF team at Microsoft. This new version of WCF targets .NET Core and has been donated to the family of .NET Foundation open source projects.
Check out the WCF project for more details. The team is actively developing WCF in this repository, and they will review any issues and pull requests you wish to contribute. The wiki describes how to build and contribute to the project.
WCF targets the .NET Core framework which is designed to support multiple computer architectures and to run cross-platform. Right now the WCF project builds on Windows, but .NET Core offers the potential for it to run on OS X and Linux. The WCF team are working hard to make this a reality and to keep up to date as platform support for .NET Core grows, but if you want to help I know they would love contributions especially around improving and testing the platform support.
In this guest post from Ron Cain, he explains more about the new project and how to get started with the new, open source WCF and .NET Core.”
Oh yes I know about this, but note that it’s WCF client, not the server side. MS does not intent to port WCF itself, they just want to make sure that a .NET Core app can call a legacy WCF service. They are not advocating the use of WCF going forward for greenfield projects. 😉
Thanks for the input Tony!
This is from README in the WCF Github repo (https://github.com/dotnet/wcf):
“By targeting .NET Core, WCF now has the opportunity for much wider reach across PCs, laptops, mobile devices, Xbox, HoloLens etc. It can also be ported to other operating systems since it runs on .NET Core, which is adding support for Linux and OS X.”
If you owned a piece of server-side technology, and you were thinking of deprecating it, would you be opening it to more uses, especially high-profiles ones (such as HoloLens)? Would you risk angering Linux and OS X developers you are so desperately trying to attract by giving them access to the technology there is even a slight chance of being deprecated any time soon?
Let’s watch Build (https://build.microsoft.com/) announcements this week and see if we hear anything interesting about WCF or it successors. WCF might be dead the way Internet Explorer is.
I can see how you might get the impression from reading this that MS is trying to breathe new life into WCF as a server-side stack. But you also have to consider WCF’s history and where things are headed. To be sure WCF isn’t going away, but WCF on the server is not going to have a place in cross platform because it is tied to Windows. And it was built at a time when development approaches are much different than they are today. That’s why I think the .NET Core implementation of client libraries for WCF is mainly a way for clients today to talk with SOAP based services, which are really fading in favor of REST based architectures.
WCF is alive and well. Just because WCF is not really suited to to HTTP web services it does not it is dead as a softtware stack, WCF is great of interprocess communication (.net remoting ) for example.
Although the post headline is attention-grabbing, my actual position is much more nuanced: WCF is dead for greenfield HTTP web services. It is still alive for things like intra/inter process communication, as well as apps which use message queuing (MSMQ). And it is also very much alive for legacy or brownfield apps based on WCF. A careful reading of the post makes this clear. 🙂
quite disappointed from this article, author did not mentioned MVC 6 is DNX material so there is no way to reference libraries\DLL written in prior .NET frameworks – and thats even occurring while the DNX system supports the .NET common marshalling eco system (ie streams, native calls, rpc etc) from other parts of the DNX framework\WINDOWS DLLs
lol WEBAPI is dying? lol you are living in a movie, and not a good one.
DNX, even if quite very impressive, is just in the diapers and for the next 5 years we will experience BREAKING changes in core functionality that will make CLR and CLI change in such a way that the MSIL will lose most of its potency.
This statement is incorrect. MVC 6 (or MVC Core, as it is now called) can reference libraries written in prior .NET Frameworks. An example would be Entity Framework 6, which is based on .NET 4.5. See my other blog post here for illustration of this, including sample code: Using EF6 with ASP.NET MVC Core 1.0 (aka MC 6).
By Web API, I am referring to the Microsoft product which is call ASP.NET Web API. This is being deprecated by ASP.NET Core, which will be released sometime later this year. It’s fine to use Web API today, as long as you do it in a way that will support migration to ASP.NET Core in the future.
Where are you getting your facts? First, DNX will go away when RC2 comes out in the next few weeks, and it will be replaced by DotNet CLI. The team is taking their time and doing it right, so as to minimize breaking changes after .NET Core is released. I can’t predict the future, but it seems like your statements are mostly hyperbole.
Thankyou for a very well written and argued article. I am currently evaluating technologies for web services for various client apps in a proof of concept project.
This post is mainly musing out loud while I avoid getting back to Visual Studio and real work. 😉
My background is 25+ years in Windows development, mainly C++/C# going back to Win 3.0 days (and, ahem, OS/2 prior to that). I have been responsible for a great deal of true “cross-platform” development which has amounted to writing lots of generic C/C++ and easily convertible C# (so not using lexical fluff like LINQ, anonymous types, etc).
Over the years, I have followed and used most of the Windows stack technologies you mentioned (and seen them come and go) but find MV__ approaches to be too intrusive and syntactically ugly, and just want a very thin layer from incoming HTTP calls to management code. (I know MVC etc is very popular, but so are numbers of folks who dislike the model for various reasons.)
Web Services could have been a good way of doing things as their expressiveness allows greater flexibility and elegance than shoe-horning everything into REST-style terseness.
For a generic “service” application scenario (not web site) like below:
[Client App][Binding Model][Binding Model][Service App]
I want the binding model code on both client and server sides to be as thin as possible and mainly exist to abstract away the crap that environment frameworks (e.g. ASP, REST, LAMP, etc) impose via their implementation details. I’ll abstract my data layer thank you very much. (Funnily enough, a long time ago, before I read about things like MVC, dependency injection etc, I had already abstracted a bunch of this stuff in our own cross-platform libraries but without the branding baggage which comes from adopting these framework artefacts.) It’s called defensive programming…
if I need to stick anything (client or server side) in a DLL for performance reasons, it’s a doddle to convert the code to C++ (unmanaged of course) if the C# hasn’t been tainted with lexical fluff.
Sorry if this is irrelevant ranting from a void* dinosaur, but your excellent article got me wound up that given the shifting sands of development “paradigms” over the past few years, there isn’t a straightforward choice for me in terms of connecting client to service without the middle layer infecting outwards where it has no business being.
– I feel much better now, time for a coffee. 🙂
It’s nice to hear reflections from a void* dinosaur 🙂 — thanks for sharing!
Hi Tony,
In terms of concurrent request Handling, which one is better : WCF or Web API
Neither. 🙂 The best is to use ASPNET Core with Kestrel – over 1 million requests per second.
Article is a flaming pile of fly covered crap click bait. WCF and specifically WS-* is still widely used in banking, finance and insurance verticals. We are still building new greenfield systems using it. Yes your new grinder clone might be better off as a docker based micro service using whatever flavor of the night hosting tool. There are still some widely used industry specific Soap and XML message based standards that are a nightmare to build using Web Api style rest tools. WCF isn’t the new hipster shiny but it is also far from dead.
I’m going to ignore that first sentence. 🙂 But I would like to address the rest of your comment. I’m not disparaging anyone who chooses to continue to use WCF to implement SOAP-based web services using WS-*. A lot of systems have been built this way over the years, and there is the need to support that ecosystem for many verticals. I’m also not suggesting that you try to implement SOAP and XML-based messaging using REST tools. What I am saying is that, if you developing a greenfield web service and do not have the need to support existing SOAP-based web services (and you’re not using MSMQ or Named Pipes), you should think twice about using WCF at this point in time. In this case, the drawbacks far outweigh the advantages.
I’m not saying this because I’m anti-WCF — I have developed many enterprise-level WCF systems over the years. But the reality is that, in order to better support modern development paradigms, it would need a major overhaul, and I don’t think that’s something Microsoft is going to undertake in the near future. I could be wrong about that, and maybe there are some internal discussions about it, but I would be surprised if Microsoft were to move in that direction. So what I mean when I say that “WCF is dead” is that I don’t think it’s going to be updated in any major way to keep pace with with things like Cloud-based app development.
So feel free to continue to use WCF, but I don’t think SOAP ever really achieved it’s promised ideal, and RESTful services which leverage HTTP offer a more compelling choice, especially when it comes to support for mobile clients and browser-based applications, as well as achieving economies of scale where you need greater decoupling from the underlying OS.
Pretty self explanatory and realistic article. .NET Developer, I appreciate the difference to the target that I am between WCF and ASP.NET Core (API Rest). -architecture, scalability and learning curve.-
Thanks for taking your time more in the answers that article :).
Sorry for bad english.
…or maybe only you just love MVC. What happen with WCF security, encriptation,mtom,transportation, brokers, and any other features provided by WCF? MVC will cover all? I don’t think so
I don’t think the idea of MVC is to “replace” WCF, that is, to cover all the features that WCF offers. MVC has different aims from WCF and wasn’t designed to be the same kind of comprehensive framework or a unification of networking API’s.
A good example would be message-level security. WCF was really designed to provide this kind of thing out of the box when you select a binding that supported it. Many times, however, people had it without understanding that you really only needed it in a situation where you wanted to secure the message as it was bring routed. But for the case where you did not have routers involved, and were simply relying on point-to-point transport, then message-level security was not needed. I saw situations where people selected the WSHttpBinding just because it was the default or they thought it was more secure, without understanding the added overhead that came with it.
In general, I would say that the approach of MVC is to address the same issues by leveraging features of HTTP and using TLS or ipSec to secure the transport. But in the area of security, MVC is better suited to play nicely with modern security standards and mechanisms, such as OAuth token-based security with JWT’s (JSON Web Tokens).
Hello Tony,
One thing i want to ask leaving all technical complexities. For me web service is a collection of Functions that interact with other web service functions or with database and provide result to UI. I still remember, when using [WebClass] attribute, we had made a class as web class. Now why such complexities that each time we need to learn the new wrapper on actual thing (Function), which is the main purpose of any web service.
Why such complexities (Wrapper) are not hidden by Technology, leaving the developer to do code for “Function”, that actually serves the purpose. Why “WCF”, “Web API” etc for web service purpose.
Thanks for your question. So the short answer is that WCF (and ASMX) is an abstraction over a SOAP-based web services architecture, while MVC is an abstraction over a REST-based architecture. The main difference is that SOAP was built to be transport independent, while REST is built on HTTP and leverages the semantics of the protocol that powers the World Wide Web. Over the past several years we’ve seen SOAP decline in prominence and REST rise in importance and popularity. So the reason why the whole thing can’t be abstracted is that you need to choose an underlying architectural foundation for your web services. I hope this makes some sense and helps answer your question.
Thank you Tony for replying such odd question.
I understand that doing software code is not same as learning driving car, that once you learn driving car, you can drive any car whole life with same pattern and skill.
But i wish, such thing should happen in software development also.
The thing in software development which is constant is change. But what may be difficult for many people to comprehend are the reasons for the kinds of changes we are seeing. The changes are not arbitrary, but they reflect a communal learning experience, and also conflict among various schools of thought based on collective experience.
We use WCF because we want MSMQ ? I want to laugh a lot but I have to sleep.
MSMQ has its own API, so I would say that WCF is not required, but it can add benefits for things like contracts and WSDL, among other things. So it all depends on your scenario if WCF makes sense for you, or rather straight MSMQ.
This article seems to take a few liberties with some of the claims that are presented. And since there aren’t references to back up these claims, I have to assume they are just conjecture with a journalistic flair added for dramatic effect.
Specifically…
WCF isn’t dead and no official statement has been released to that affect. Like another commentor pointed out, WCF is still widely used. It is extremely unlikely that Microsoft will be discontinuing the stack as it is still extremely useful for different situations. That said, WCF isn’t the only option anymore. Certain use cases that would have previously required a WCF solution now have much better alternatives (like Web API). As developers we still need to evaluate the right tool for the job; it’s just that we now have more tools to choose from. Also WCF is on the roadmap for .NET Core (http://forums.dotnetfoundation.org/t/wcf-5-for-net-core-5/1223).
Web API isn’t dying. We are seeing the beginning of a transition taking place around the current technology stack used for Web API. I get that you are actually referring to the ASP.NET Web API 1&2 stacks specifically, however Web API exists in ASP.NET Core (albeit with some differences). Saying that Web API is dying would be like saying MVC or Entity Framework are dying (they aren’t).
I do agree with your recommendations in the article and comments around legacy vs greenfield projects, WCF vs Web API, or Full .NET vs .NET Core. I just take issue with how you’ve presented the “facts” that lead into those recommendations as they can be very misleading if not taken in the appropriate context.
Overlooking all that though, the article was a great read and I really enjoyed it!
Thanks Phillip for your comments. It’s important to understand the subtle nuances of my position, which may be difficult to distinguish from my dramatic flair. 😉
When I say, “WCF is dead,” I mean that it is “dead” in the same sense that Windows Forms or Silverlight is “dead,” in other words, that I would not recommend it for greenfield HTTP-based web service applications. Have Windows Forms or Silverlight been discontinued? No they haven’t — you can still develop UI apps based on these technologies, and they can even be installed with Visual Studio. But I would not recommend them for general use, except for specific, narrowly defined scenarios. It is in this sense that I would call them “dead,” which is admittedly an overly dramatic term, albeit one that gets the reader’s attention.
Yes, I am referring specifically to ASP.NET Web API 1 & 2, not to the concept of a Web API in general. I would not recommend using ASP.NET Web API for greenfield web services, because it is based on an outdated architecture. The exception would be if you are using it with OWIN for Windows-based deployments, but even in this case you need to understand that ASP.NET Core supersedes ASP.NET Web API.
Glad you enjoyed the article! I would want to point out that it should be interpreted in light of the comments I wrote in response to questions and comments. That’s the best way to grasp the nuances of my position and recommendations. It’s true that Microsoft is loathe to pronounce any of its technologies as deprecated, but this leads to possible confusion and misguided architectural choices — which is why I decided to author the article in the first place. There are lots of teams out there who are building greenfield HTTP web services on WCF when they should not. The goal of my blog post is to try to prevent those missteps and avert deficient technology choices based on lack of information about the evolution and current state of web services architectures.
wow! Nice update on MVC that ASP.NET 5 has been renamed to ASP.NET Core 1.0 and that MVC 6 is now called MVC Core 1.0. I read this blog and really got many information about all these. As a web hosting user I use Myasp.net and from there I got the idea regarding MVC. Thanks a lot for sharing.
Hi Tony, Thanks for the article. It is very educational for me. We have a large WCF service and that works well with WPF client. We would like to add a new Android client to the offering. What path would you take? Would you try make WCF work on Android or would create a new REST based service just for mobile?
WCF does have REST support, so you can use that for an existing (brownfield) web services project.
Hey Tony, what about Workflow Foundation Service? It’s built on WCF, is there an alternative in the future coming?
Here is something that might relate to WF’s future: http://andreioros.com/blog/windows-workflow-foundation-rehosted-designer. In terms of WF – WCF integration, I would view it as legacy, that is, something worth using if you need it, but not on the cutting edge in terms of x-plat on .NET Core. I haven’t seen anything on the horizon on the .NET stack as a successor, so you would be constrained to the Windows platform, or look to a non-.NET alternative.
Great article and I read all comments and replies and learned. But I would like to say that nothing is dead is just the evolution. There are many many situations in which many many old things are better than new things and vice versa. So I think we should encourage people to evolve with the evolution in programming not conclude things as dead or gone.
Thanks
Yes I agree that the term “dead” is overkill, so to speak. It’s kind of an attention-grabbing headline, but I try to lay out my more nuanced position, which is that WCF, in my opinion, should be considered deprecated at this point for greenfield HTTP-based web services. There are always lessons to be learned in the evolutionary process that is software development. With respect to WCF it is, in a nutshell, that the idea of transport-independence turned out to not be as important as it was thought to be.
The term “dead” can also be taken to mean, “not growing or continuing to evolve.” This is also certainly the case with WCF, which has not been revisited by MS to bring it up-to-date with modern development approaches, such as the ability to play nice with dependency injection frameworks. In short, the world has moved on, and WCF should be considered legacy at this point. But I would agree that WCF is more accurately described as deprecated rather than dead, because legacy software will always have an important role to play.
Tony good article.
Question: for a high performance web service architecture (REST based with custom format instead of JSON, XML, etc.); would you recommend:
a) ASP Core Web API with Kestrel OR
b) Service Fabric based Stateless service
I think before too long you should be able use both together. See this article: https://jonhilton.net/2016/04/13/azure-service-fabric-goes-live/
Yes, but what would you recommend Kestrel based approach or straight Service fabric? I am leaning to Service fabric, since it gives ability to manage multiple nodes, fault management, load balancing, recovery, health checks, etc.
However not sure which is more performant…
If you are able to use Kestrel together with Service Fabric, you would get the performance benefits of Kestrel, as well as the other benefits of Kestrel, which is really fast, according to the Tech Empower benchmarks.
Is there a modern replacement for WCF TCP and NamedPipe bindings and such inter-process communications we can consider in instead of existing WCF integrations? For example for communication between hosted MVC 6 site and Windows Service hosted on same or different machine?
If you are doing inter or intra-process communication on the same machine, then I think WCF with a named pipes binding is appropriate. I would generally recommend avoiding the (greenfield) use of WCF with the NetTcp binding and instead favor an MVC Core Web API with JSON and possibly a protocol such as ProtoBuf if you to reduce payload size for better performance. The main reason why NetTcp was used for .NET clients was so that messages would be binary encoded, which was a concern especially with the verbosity of XML and SOAP headers.
With regard to communicating between an MVC Core service a WCF service, which could be hosted in a Windows Service, you can use the new .NET Core WCF client libraries on the MVC Core side. Note that this project is client-side only and does not represent a port of WCF services to .NET Core. Some people have the false impression that the existence of this project implies that WCF services are being carried into the modern era, but as I’ve pointed out previously, it is simply to support interoperability between .NET Core and (legacy) WCF services, which should be considered deprecated for greenfield HTTP-based services.
Thank you for your time!
We have a similar need where in the same Web API service will run on cloud as well as local machine. So if the payload is binary reduced (Proto Buf, Msg Pack or ?), then using HTTP + Rest API still makes sense, instead of changing bindings for local vs remote. Self hosted service fabric with Web API or Kestrel server is the route we are going with.
The testing and code maintenance will be simpler and on the same machine HTTP will not cause perf issues, since payload itself is small. It is not going to be as compact and efficient as NetTCP or Named pipes binding, however the difference would not be an order of magnitude slower.
I think that is definetly a good starting point rather than tweak and have 2 different packaging formats.
Hi Tony,
Thank you very much to share such a great information. This is really a great article and very fruitful information in the discussion.
Tony I need your few minutes, actually Nowadays we are working on the design of an application(related to Telecom domain) this application will be SOA based application and it will support
SOAP and REST both to make it easily integrate able with other applications. Clients of this application can also built UI on top of these Web Services and also can use it as a Service in their existing services.
Before reading this article I was thinking about these two options WCF and WEB API to build this application but after reading this article now I am thinking about these two options WEB API and ASP.NET 5 with MVC 6.
As a expert opinion can you please guide me which technology is fit for this scenario.
Thanks in advance!
I would need more information to make specific recommendations. If you follow me on Twitter (@tonysneed), I can send you my email via direct message.
Tony, this post and the discussions around it have ROCKED with so much useful information! Love the way you keep in touch with your readers’ replies! Keep up the EXCELLENT work!
I’m working with an existing WCF Service Application and am investigating which of these two directions to migrate toward: Web API or ASP.NET Core. I know, I know – reading through the post, it may seem a no-brainer to start migration efforts toward ASP.NET Core. But with many other factors at stake with the current application, I may have to take a gradual approach to getting to current technologies, frameworks, etc. I was hoping you could provide some answers/feedback with two questions I have to help me with my migration efforts:
1. With Web API and MVC 6 both being melded into ASP.NET Core, do you know if MVC 6 will be available separately? If so, do you know if it can be used with ASP.NET 4.6?
2. If a move to ASP.NET Core is not possible right away, would it be advised to at least migrate to Web API? Which, I would hope, would help with the transition to ASP.NET Core? Is it easier/less painful to migrate from Web API to ASP.NET Core versus from WCF to ASP.NET Core?
Thanks, in advance, for any insight you can provide me with! 🙂
@Sonny,
Thanks for the kudos. I like to think of my posts as the beginning of a conversation and that we all learn something in the process.
Actually, the name was changed from MVC 6 to MVC Core, so it’s the same thing. The term “Web API” is also a bit confusing, because it refers to an actual (deprecated) product, ASP.NET Web API, with the latest version being 2.2. With MVC Core, it is no longer a separate project and everything is now just MVC Core 1.0. Although there is still a separate “Web API” project template in Visual Studio, it simply creates a RESTful service using MVC Core.
Yes, stay away from WCF if you plan to migrate eventually to ASP.NET Core. If you can’t move to ASP.NET Core right away, then should use ASP.NET Web API 2.2, but do not use the standard Web API templates from Visual Studio. Instead, you want to use OWIN/Katana from scratch. You can find a fgood tutorial for that here. The reason is that the ASP.NET Core pipeline is modeled after OWIN/Katana, where you have a Startup class and your components are configured there.
P.S. Stay away from self-hosting with ASP.NET Web API, because it uses WCF under the covers.
All the best!
Tony,
Thank you very much for clearing up the ASP.NET Web API/MVC6/MVC Core bit. One more question relating to this topic: Would you know if the MVC Core NuGet package can be used with .NET 4.6? Or is meant for .NET Core only?
Thank you, also, for your input around migrating to ASP.NET Web API 2.2. Since I’m working with an existing WCF Service Application, would migration to ASP.NET Web API 2.2 be a matter of, from a high-level aspect, the following?:
1. Get the ASP.NET Web API 2.2 NuGet package
2. Define routes
3. Create new controllers that inherit/derive from ApiController
If more needs to be done, could you point me in a direction?
Thanks, again, for any additional insight you can provide!
MVC Core is compatible both with .NET Core and .NET 4.6.
Everything depends on the specifics on your situation and what kind of WCF service you are working on. If you follow me on Twitter (@tonysneed), I can send you a direct message with my email address and we can converse via email. In terms of a good tutorial, the one I recommended earlier seems like a good place to start: https://dotnetcodr.com/2015/07/02/building-a-web-api-2-project-from-scratch-using-owinkatana-net-part-1.
Cheers,
Tony
Hey Tony, I have a question regarding all of this.
I’m very new to the .NET Framework and C# and using all these different services. I am working on a project with a team where we are using SOAP services with WCF and having our Rest Service use our API that references our SOAP service(I believe that is how we are doing things).
So we have a database that talks directly to our Entity Framework(Could be changing to Dapper soon) and then we have a SOAP service that takes our Database information for our Gets/Posts/Puts/Deletes and then we have our WebApi that has a service reference to our SOAP.
I wanted to implement Authorization and Authentication, so I created those using the MVC 5 and avoided using the Rest and SOAP service. However, my supervisor wants us to use Owin throughout the application, so I have to implement a WebApi that uses Owin and Identity, however, I also have to have that information go down to our Entity Framework side as well to interact with our DB. Personally, I believe that that is a lot of overhead on the server but seeing as I am new I don’t know which way is best.
Would you recommend that we do things that way where we send everything down through the pipeline in that manner? Or do you have another suggestion? Thank you!
Yes, for the ASP.NET 4 bits, including Web API 2.2 and MVC 5, you should use OWIN (tutorial here). For the Auth piece, Identity Server 3 uses OWIN / Katana as well, so it would be a good match (docs here). If you have any other questions, send me a tweet: @tonysneed. Cheers,
Tony
How do you think companies (especially larger enterprise level companies) that should go about moving from WCF to ASP.NET 5 with MVC 6? How long of a transition should that take for some of the larger companies?
I’m not a developer – I am a .NET Recruiter/Account Manager. I have a few clients who are still on WCF and have no immediate plans on moving away from it (they may have not gotten the memo). A lot of the developers I work with, have no interest in working at shops that aren’t using MVC. Based on your article it seems like they have very good reasons to shy away!
Like any other deprecating technology, companies will employ different strategies in migrating to newer technologies and platforms. Basically WCF was not designed with the Cloud in mind, so companies will most likely drive their decisions by the business need they may have to leverage the Cloud. It’s as much of a business decision as it is a technological one.
Pingback: WCF Is Dead and Web API Is Dying – Long Live MVC 6! - How to Code .NET
Pingback: WCF Is Dead and Web API Is Dying – Long Live MVC 6 !!! – Ramani Sandeep's Blog
Hi Tony, that’s a very compelling story you wrote.
I’m now working on a relatively fresh intranet project. Currently MVC5 is a front-end framework used. Developers perceive it as an “ancient” technology and would be glad to replace it with Angular2, which we can do as this is a technology choice for fronted my company is going to embrace, even though we are all Microsoft shop.
You haven’t touched a bit on SAP vs. MVC6 in your post, but it would be great to know your thoughts. I think more and more .NET applications these days are written this way – REST API + SAP front-end.
The beauty of a MVC Core Web API back end is that you can use whatever front end stack makes most sense for your scenario. SPA frameworks like Angular or Aurelia are preferable to server-rendered UI’s like classic ASP.NET MVC and Razor pages, but desktop or device front ends like WPF, Electron, Swift, or even SAP, should be able to work just as well with a middle tier based on MVC Core, where you get a cloud-friendly cross platform solution where your team’s C# skills can be leveraged.
Hi Tony,
I have successfully build an entire API infrastructure at my company so that all the applications can use them. I primarily used WCF because of WSDL, so the engineers could just add a service reference in Visual Studio and forget about the details. If WCF is dying (which I do agree on) what would that replacement be? Would intranet applications use REST? That doesn’t entirely make sense to me. If so, we wouldn’t have a centralized way to connect to them using Visual Studio like we have in the past, aka the service reference. I always saw REST as a way to allow for external systems to consume yours or really for mobile because of JSON. So in the end, what should I use if I have a WPF or WinForm application that want to use a mail api IN our enclosed company environment?
Thanks
Ralph
Hello Ralph,
Excellent questions! Here are my answers:
WCF and SOAP were based on the idea of strong contracts, so you could generate WSDL for your contracts and tools like VS Add Service Reference could generate client code based on the WSDL. With REST things are different. 🙂 Instead of strong contracts, which can become brittle and require strict version control, REST proposes a more flexible arrangement called HATEOAS (Hypermedia as the Engine of Application State), where hyperlinks in responses provide the client with info it needs to navigate to other resources. Also, REST tends to be resource-centric, while SOAP leans toward operation-centric API’s. These are the reasons why VS does not offer “Add Service Reference” for RESTful services.
Another thing that might help, is to understand that a lot of things in REST are done by convention rather than configuration. So URI segments have a certain convention, and also HTTP verbs are conventionally mapped to CRUD operations.
That said, there are tools out there that try to bridge the gap. The most popular is called Swagger, which lets you describe your RESTful Web API’s and can even generate client code. Check it out.
Yes, and Swagger can help by providing metadata that is both human and machine readable.
You can use any client for a RESTful service, which is really part of the argument for using a REST-based Web API. Any kind of client can use it, including desktop apps (WFP, WinForms, etc), mobile apps (Xamarin), web browers (MVC, SPAs), other web services, etc. Your friend here is HttpClient.
Cheers,
Tony
I think a lot of the community is drinking the web koolade. WCF was a way of reducing the complexity of two systems communicating with eachother. Not just web sites, not just Http. REST is fine if you’re dealing with call-response to Data sources, but if you are doing something outside of the websphere, such as controlling disparate machinery and other systems, SOAP and XML were specifically created to allow a common language. From the complexity of security and interop, came WS-* and Transport and Message level security. REST is just the transport medium, and to be honest, only a small part of what WS Specificationns, SOAP and the wrapper of WCF gives developers and System Engineers.
So, you’re right, if you’re building services that are just chatting about a extended CRUD layer, then REST will be a great fit. But, shoehorning a system that was specifically built to solve a specific problem to be the panacea, just because its popular is just foolhardy.
And WCF can use REST, and any communication layer or protocol you want, that’s why it is powerful, because of that extensibility, because of the ideals it embodies of a universal framework for communication.
Ultimately, you’re conflating a Architectural Style with a framework.
@neilhighley:
Thanks for your comments on SOAP vs REST. Rather than saying one is bad and the other is good, I would say that each takes a different approach to solving a similar set of problems. It’s not really a question of which is technically better, although this is an important aspect. You also need to consider which approach is more likely to gain dominance, and where Microsoft is investing its resources to bring WCF into the modern age with support for things like TDD and Dependency Injection.
WCF uses SOAP in part as a way to achieve transport independence, and the WS-* specs were written to provide standards for metadata, for example, message encryption and integrity, transactions and reliable messaging. All this is well and good, but after many years of experience, it turns out that very few systems have a real need for most of these things. A good example is message-level security. The only reason you would need it is if you had intermediaries and needed to keep them from seeing or altering the message, but many people turn on message-level security, even if they don’t have any intermediaries, because it’s the default for WSHttpBinding.
You have an overly simplistic understanding of SOAP and REST. SOAP was not created to allow a common language for things like controlling disparate machinery, and REST is not merely for call-response to data sources. You can use JSON with a schema to accomplish the same thing as XML with a schema, and you’ll get better performance because JSON is not as verbose as XML.
Again, your understanding of REST is incomplete. It is not just a transport medium, but it relies on HTTP as a protocol, together with the infrastructure of the web, to achieve goals of statelessness, scalability, etc. If you are using custom SOAP headers, they can be implemented as HTTP headers in a RESTful web service.
I’m not saying that you should go back and throw out all the SOAP-based systems and replace them with REST. WCF will be around for a very long time, and maybe it will see a renaissance (although I doubt it). Brownfield apps built with WCF and SOAP don’t need to be replaced — if it ain’t broke, there’s no need to fix it. My recommendation concerns greenfield web services, where I suggest you prefer REST with MVC and ASP.NET Core going forward. And this is where Microsoft is investing heavily, by building a modern framework that is DI-friendly and runs on non-Microsoft platforms, such as Linux, where it is common to use a microservices architecture with Docker for containerization.
Yes, WCF was updated early on to support REST. But it was never a natural fit, which is why the OData team at Microsoft discarded WCF Data Services in favor of MVC.
WCF is a framework that expresses an implicit architectural style that relies on SOAP and XML for transport independence. However, WCF does not require this .. you can use it in a message-centric manner as well. REST, on the other hand, is not a framework, but rather an architectural style. ASP.NET MVC Core is a framework built to implement RESTful web services, but you can obviously use it in a way that is non-RESTful.
Thanks again for your comments!
What’s ASP.Net WebAPI or MVC 6 gotta do with WCF ??? WCF does a lot more than just creating web services. All the major high volume, low latency LOB enterprise applications that use end-to-end Microsoft stack, use WCF over net tcp at the least, if not msmq or net pipes. So, this whole idea that someday a web based technology would replace something like WCF is for the illiterate really!
Besides, the only ground that Microsoft has lost substantially over last 2-3 years is to on its bouquet of web based technologies. Is it anybody’s guess… that the web development job market is flooded with Angular JS, node, react and the likes and barely 10% web dev jobs are there for Microsoft web developers (ASP.MVC, web Api, oData w/ REST). However, the only ground that Microsoft has held strong yet is with WPF and WCF.
Lack of knowledge! Get your facts right!
@Dan, precisely, I am also a hard-code WCF user, but just for REST APIs, I have transitioned over to using ASP.NET Core 1.1 based REST service. It uses MVC, and btw in this case there is not “V” part, just the Model and Controller, so I was confused initially too on why would i need MVC for rest.
May be MS should rethink the naming for REST APIs.
However I have a single DLL based on ASP.NET Core 1.1, that could work on standalone desktops, or cloud AMZ, Azure, could be docker based and also run on linux and other platforms, since it is based on .NET Core.
It is simply not possible to get the same done on WCF, a single binary level code base, that works on all platforms, desktop, cloud and non-MS OSes.
Given that it has slightly more overhead that net pipes or TCP, but for local scenarios, where it on localhost or intranet, if network is fast, it is fast anyway even though it uses HTTP as transport.
I was suspicious of this, but benchmarking for our own case with WCF/Pipe or WCF/TCIP vs HTTP hardly showed the difference.
For local or fast intranet scenarios, the time taken is for the IO (database, etc.), rather than the network. However for real internet or cloud scenarios especially with VPN, network lag becomes an issue, hence Binary custom object transfers would work better with WCF.
However in our architecture, I have developed a custom binary protocol that yields better results than the Google Protobuf or MSGPack based object packing frameworks, and with this in place, it matches or is almost on par with the WCF scenarios for internet usage.
I use the compact binary stream further use Deflate to compress it, reducing one sample case from 40MB to under 2MB of data exchange.
So I would say, rather you should catchup and clear up your facts!
@Rajesh: Nice work! I’ve used Google Protobuf and seen some significant reductions in payload size. Is your protocol open-source?
@Tony
No, I did not have time to write it in a generalized way or to make it open source, may be in future!
I use EF T4 generator to generate DBWrapper classes for each table with type specific property. Each field is either DB Nullable or have a default value either type based default or partial custom classes inject the default.
Each record transmitted has a flag for each ‘Omittable’ field based on NULL/defaults and are not shipped. Secondly each type is reduced to use min bytes. Ex: 7bit encoding for unsinged integers, a modified 7bit encoding for signed integers, decimals are compressed based on flags, precision, scale, etc.
DateTime are reduced based on Request/Reponse header timestamp so only 7bit encoded values of reduced Timespan and so on.
Secondly the application based logic is used to omit shipping values if they can be derived based on certain conditions, i.e. for A + B + C values of the fields, the other field values are derivable, then they are not shipped and so on.
Also I implemented a method to reduce strings using various different algorithms. One good part about it is even a “Hello World” string is reduced in size and not readable on wire at all. Otherwise a default BinaryWriter encoded String is visible in clear.
Finally I use Deflate stream from .NET to deflate it.
Net result is better than what I got from either Proto or MsgPack.
When I have a chance, could open source this.
@Dan: I think you misunderstood the meaning of my post. I did not suggest that ASP.NET Core was intended to replace everything that WCF was invented to do. In fact, I said quite the opposite:
The point of my post was that, rather than trying to use WCF for building greenfield web services, you should instead use ASP.NET Core, which is cross-platform and supports modularity, cloud-friendliness, and modern development approaches such as TDD and DI.
In scenarios where you would like to communicate over a non-HTTP transport, such as named pipes or MSMQ, then you can of course still use WCF. But you should be aware that Microsoft is not investing heavily in the continued evolution of WCF, because it was built in an era where SOAP-based systems were more dominant than they are now. In fact, I’ve just heard from the ASP.NET Standup on 29-Nov-2016 that Microsoft is planning to build a new platform to support communication over non-HTTP protocols, which, in my view, will help fill the gap left by the unofficial deprecation of WCF. A huge advantage of the new channels stack is that it will be cross-platform, overcoming a significant limitation of WCF, which is that it requires Windows and the full .NET Framework.
Wow thanks a lot for that post!
I was cconfused about your last comment “you’re going to want to skip right over ASP.NET Web API and go straight to ASP.NET Core”. In fact, ASP.NET Core MVC includes support for building Web APIs providing a single, consistent way of building web applications.
https://docs.microsoft.com/en-us/aspnet/core/migration/webapi
That line should read, “skip over ASP.NET Web API 2.x,” which refers to the product used to build Web API’s prior to ASP.NET Core.
hi Tony…i have a wpf desktop app(client) and a asp.net core mvc app(server)…that communicate with each other…Which is better for the association 1-web api or 2-wcf ???
Go with ASP.NET Core web API on the back end rather than WCF.
Pingback: WCF Is Dead and Web API Is Dying – Long Live MVC 6! | Tony Sneed’s Blog | .NET Monitor
I agree with many comments here. I don’t think WCF is gonna be dead so quick. Web API doesn’t provide what WCF can. For enterprise LoB applications WCF is hands-down the far better solution, even for cross-platform consuming (Xamarin for instance).
Thanks a lot of the post and comments
So if WCF is dead what microsoft technology do you suggest one use in a large scalable distributed application that requires transactions support with net.tcp and msmq?
I can see that Web Api and Owin and MVC are very cool technologies to use but somehow it does not feel serious enough? – it seems limited to smaller http solutions? Or am I wrong in my thinking?
I have looked but have not seen anything that can yet replace WCF when it comes to support for transactions, throttling & concurrency? What about Instance management, version tolerance and tracing?
WCF was invented to support a particular architectural style (SOA with SOAP independent of the underlying transport) that has been overtaken by another architectural style (RESTful embracing HTTP as an application-level protocol). You can accomplish many of the same things using a different approach. I’m not saying that you shouldn’t use WCF for things like MSMQ or inter-intra process communication. But for many greenfield web services, I recommend ASP.NET Core, which is cross-platform, container-friendly, and has better support for dependency injection. Web API’s built on .NET Core are plenty serious and can perform and scale much better than what WCF can do without a great deal of customization. Kestrel performance, for example, blows away classic web or self-hosts with WCF. Net.Tcp can be replaced by Protobuf, which is interoperable. The WCF features you mention have equivalents in the world of REST, but it requires a different mindset.
WS-* is a set of specs for SOAP interoperability. The need for standards still exists, even if WS-* is fading in adoption. To fill the gap we now have things like OpenID Connect, an identity layer on top of the OAuth 2.0 protocol. Identity Server and associated client libraries provide the recommended implementation of OpenID Connect on the .NET Core stack.
WCF is a great product that was many years in the making, and Visual Studio provided the kind of tooling that made it relatively easy to use out of the box (remember Add Service Reference?). But it’s important to recognize that we live in a different world today, where cross-platform is much more important and HTTP is much more than a transport protocol. While WCF supports REST, it’s not a core aspect of the product.
There will be a WCF client on .NET Core, but it exists to support legacy SOAP-based services. On the server side, it is important to see how modern RESTful services are really the way to go, and to use token-based security and claims for authn-authz. Other WS specs, such as transactions and reliable messaging, may require custom REST implementations.
Hi Tony. This is the 4 time i visit your post from another pager. I think this question of SOAP as still relevant tooling for web service is crucial for many people and this time i would like to say something.
I’m still don’t understand why you want to throw away all of the effort put in WS*. At least in security.
There are many things I’m wondering how would you do it in a RestFull way like WS Trust.
I agree with you and most people about how easy is to develop a rest service in asp.net core (MVC)
. All the configurations are in place by http. and security? no problem.. SSL.
But express the business logic in a long list of uris. i don’t like it.
and some benefits that the SOAP protocol have have sense to me.
When I see that you don’t need any complex tool more than just a http client to deal with a rest service was a big deal. Nobody wants to make a SOAP call itself right?
In WCF you need more dlls in order to comunícate with the service and i know that there is a project in net core about wcf client in order to be interoperable in most scenarios but http request model is a big advantage in tooling. I think the hard work is because the WS* specification
Well as I said. I like the way SOAP expose the operations in a verbose mode, It can express the intention of the business naturally and I like intellisense in the client. When you follow the best practices of course.
Many people always compare this two topics only in KBs used in messages and tooling.
but a standard way of coordinate problems like how autenticate in different services with the same token, claims authorizations and so on. Is always out of the discussion. You need a standard protocol.
I think for many companies that has a robust SOAP services inventory in place don’t want to re-implement again. And build a restfull solution in top of SOAP services is the best choice.
I’m still waiting the wcf net core project in order to bring more scenarios at least in mobile.
even UWP doesn’t support the WS*. Come on.
I think more Interoperability and fast development is the key of restfull success
There are so much topics to learn about what SOAP is and the WS* that most people said no. Go for rest. But there are in place for some reasons right?.
Greetings. And sorry about my poor english.
Sebastian.
Good article there. But I had great difficulty reading on once you blamed WCF for being too complicated.
This: “Yes it does, but aside from the fact that REST support in WCF has always felt tacked on, WCF has problems of its own. First, WCF in general is way too complicated. There are too many knobs and dials to turn, and you have to be somewhat of an expert to build WCF services that are secure, performant and scalable.”
People’s weakness to understand something should not be pilled upon WCF as it’s (wcf’s) failure or drawback.
Solid insights though!
Pingback: Journal 05/26/2017 (a.m.) | Journal
I didn’t actually read every comment here but wanted to post in case no one else has mentioned it already.
As much as I like .NET Core, it bothers me that everyone wants to jump on the .NET core bandwagon – especially if you are at a Microsoft shop. I’ve worked with .NET since v1.1, with some Perl, Java, PHP and others before that, and if you are at a company that uses Windows desktops, Windows servers, and MS SQL Server exclusively, there is not a good reason to switch to .NET Core. Especially if said company has no plans to migrate to the cloud because it already has its own infrastructure in place.
So very true. Now more than ever… I honestly believe Microsoft should outline a solid deprecation policy and stop creating so many expectations on technologies that are now halfway gone… Its almost like they expect them to ‘just die’ at the hands of the community.
WCF, WPF, Windows Forms, Silverlight, etc. I know, some of them are still going and there’s always the “we are committed to continuing supporting..” discourse but in the end, it’s just to stop the outrage of a whole lot of devs left in the dark having to move codebases to whatever is deemed next-gen by the cool kids.
Everything in dev world is so frustrating these days…
Hi Tony,
I arrived here after searching for “WCF is dead ” on google !
The thing that made me believe that was that the WCF Certification has been expired by MS on july,2016 !
Do you think this(that its dead!!) is the reason that this certification has been expired !
Thanks,
Shaarang
Here is an interesting view
https://www.erikheemskerk.nl/benchmark-wcf-webapi-aspnetcore-mvc/
Simple but effective strategy is to, never practice designer coding (MVC 6, Web API, REST, Angular) . Most of technology out there is the same old round wheel (same old stuff) with a shiny new skin. What hot or whats dying in terms of technology is so passe. Do practice sound design and coding principles and apply appropriate technology stacks into your solution.
Most of you reading this would red arrow me to death but a least I make my own path 🙂
Happy coding!!!
Tony, I’m curious I’m researching the best way to transfer binary data over the web and not finding any good resources that discuss this. Can you point me to one or have an suggestions. This is not a publicly consumed service but on the web none the less. From what little I’ve read WCF is better for binary data but again I’ve only found a couple of resources that address it.
Try protobuf for binary with RESTful Web API.
The point is well made that WCF is way too complicated. But the point is not well made that WCF doesn’t support such techniques as “dependency injection.” WCF is meant to be a service layer, with the underpinnings in a different layer Meaning the underlying layers behind the service layer can and do support various patterns we may wish to use as is the case with REST..
Having worked extensively with WCF lately (2018), I must confess I have a dual feeling about it going away. Notice, I don’t disagree with you, I completely agree with you that WCF is definitely dying, and probably has been for a very long time. But I am still struggling to see how web APIs can entirely replace WCF. For instance, I’ve got one service with a duplex channel, for retrieving and sending emails. The duplex is used for incoming POP3 emails, and the normal channel is used for sending emails over SMTP.
This is all hosted in a service host, from where I supply a callback, which basically stores incoming emails into my db.
To replace this with web APIs, would be close to impossible the way I see it. For instance, I don’t even have any guarantees of that my “retrieve emails from POP3” thread is even running in a web API.
There seems to be something “missing” here, and I predict a market for 3rd party tools, supplying portable solutions, fully functional with .Net Core too, allowing to do some of the things WCF used to do before, such as e.g. duplex …
As I prophesied some 20 years ago, “ASP is the longest, slowest and most painful path between CGI and CGI.” (Common Gateway Interface.) ‘New’? No, not even a bit. I still have “CGI Developer’s Guide” by Kim from ’96. Still, it’s nice to see the world finally catching up. But having said that, Nothing ever dies. The pundits fiercely insisted that CGI was dead when ASP came out. Now we see were that went. All things have a place. WCF isn’t B.A.D. as such – it’s just a niche system that MS tried to make general-purpose. Web API has its uses, too – it simply doesn’t serve all needs well. Similarly, REST/MVC won’t serve all needs, either, and eventually Dependency Injection will fall by the wayside when even the most enamored can’t avoid seeing the Hell they’re digging for themselves. It will all be fiercely championed by the pundits for awhile of course, and achieve wide acceptance, and in ten or 15 years time its limitations will have become painfully obvious and people will seek to address those issues with something new. It’s an infant technology. It grows fast. That is what you can truly depend on.
Hi Tony.
Nice post. I have to say that for some project we can’t use .Net Core yet. It’s my case. I’m developing a WebAPI that interfaces with MS Dynamics CRM dlls to connect to our app and execute operations and it works jsut with .NET 4.6.2 or lower (I gues, but I’m sure that did not work with core).
The option is to use its CDS but once again i can’t get the access token since I can’t register the app on azure (2 different instances).
I don’t knwo how it is for other microsoft products such as NAV but we still have limitations.
I was going through various technical blogs and stumbled upon your article @ https://blog.tonysneed.com/2016/01/06/wcf-is-dead-long-live-mvc-6/ .
It was very intriguing considering I am exploring on similar lines. We are working on an Enterprise Application Development Framework, where the product was developed in the late 90’s. The components are deployed as COM+ application. Over the period of time, some of the framework components were moved towards managed code, and we have them rewritten in C# and some are retained as native C++ projects. For those native C++ projects, we have managed wrappers written in managed C++.
Of late we have had issues with Windows updates and patches, breaking the internals of COM. Since there is little support for COM, DCOM, we believe it is time to move to alternative framework. One of the possible solution is gRPC (https://grpc.io/). Whilst some suggested to explore WCF, I read your article and am interested to know your insight on this front. A legacy DCOM application, which is to move to alternate framework.
Hi Tony,
I was going through various technical blogs and stumbled upon your article @ https://blog.tonysneed.com/2016/01/06/wcf-is-dead-long-live-mvc-6/ .
It was very intriguing considering I am exploring on similar lines. We are working on an Enterprise Application Development Framework, where the product was developed in the late 90’s. The components are deployed as COM+ application. Over the period of time, some of the framework components were moved towards managed code, and we have them rewritten in C# and some are retained as native C++ projects. For those native C++ projects, we have managed wrappers written in managed C++.
Of late we have had issues with Windows updates and patches, breaking the internals of COM. Since there is little support for COM, DCOM, we believe it is time to move to alternative framework. One of the possible solution is gRPC (https://grpc.io/). Whilst some suggested to explore WCF, I read your article and am interested to know your insight on this front. A legacy DCOM application, which is to move to alternate framework.
Yes, gRPC is now Microsoft’s recommenced alternative to WCF, and there is first class support for gRPC in .NET Core 3.1 or later.
WCF is dead, You cannot write WCF severs or port existing WCF server code to .net core or .net 5.0 as of November 2020. .Net core and .net 5.0 support WCF client code but not server code.
WebAPI is also on its life support tract. Microsoft has invested heavily in WebAPI for many Azure functionality.
gRPC is Google’s replacement for binary RPC being much faster, lightweight and more secure, no readable by anyone HTTP headers mess. gRPC’s support for RPC as well as client to server, server to client, and bidirectional streaming is something that WebAPI cannot do.
gRPC is only partially supported in Azure with some streaming not supported.
What’s old is new, gRPC *cough* is nearly identical to what I used on Unix system V in the 1980s with IDL file based RPC in C.
Recommendations from one who has done RPC in many different technology stacks:
1) Foremost, do not rely on extra tooling or special features of any vendor
2) Do not rely on extra features of a protocol such as HTTP headers
3) Use whatever protocol you want to, build out a generic data block to serialized stream and then serialized stream to data block code in your programming language
4) Put your data into structure of (header, operational code, version number, payload) and have your RPC endpoint decode that structure and route the call to the appropriate function in your server code.
5) If you host in the cloud, your business plan should have a disaster recovery plan showing the steps, cost, details on how to move off the cloud and get your data back in house or into a different cloud vendor’s software. This plan should be part of your cloud planning and the cloud vendor should sign a legal agreement that they will provide your data back to your company in a usable format within 90 days of being notified. XML, JSON, flat files, etc. are not a viable format for a large amount of data. A SQL Server backup is a viable format. A large collection of JSON/XML documents from a document database is not a viable format.
Really Informative.
For a big application which is using WCF, what are the recommended strategies for migrating to RestFul APIs? Like Should go ahead with hybrid approach, or a clean one time upgrade approach ?
I know many factors may impact decisions but in general? by keeping in mind maintainability of code and Quality.
I’d try the new minimal api. You wont feel forced to reorganize your api to use controllers. Easier to learn than gRPC since it’s all C#.