Here is the basic difference between the two -
1 File Format/Extension :
i) ASP.net service - '.asmx'
ii) WCF service - '.svc'
2 Hosting :
i) ASP.net service - Can be hosted in IIS also can be hosted in a Windows Service.
ii) WCF service - Very flexible, can be hosted in IIS, Windows Activation Services(WAS), Managed Windows Services and It also supports Self-Hosting.
3 Transport Protocols/Binding :
i) ASP.net service - It supports HTTP & TCP protocols along with custom binding.
ii) WCF service - supports HTTP, WS-HTTP, TCP, Custom, Named Pipes, MSMQ & P2P(Point to Point) etc.
4 Data Transformation :
i) ASP.net service - XML serializer for Data Transformation.
ii) WCF service - DataContractSerializer for Data Transformation.
5 Serialization NameSpace :
i) ASP.net service - System.XML.Serialization
ii) WCF service - System.RunTime.Serialization
6 Supported Operations :
i) ASP.net service - only One-Way and Request-Response type.
ii) WCF service - Includes One-Way, Request-Response and Duplex.
7 Encoding :
i) ASP.net service - It uses following encoding mechanisms -
XML1.0, MTOM (Message Transmission Optimization Mechanism), DIME (Direct Internet Message Encapsulation)
ii) WCF service - It uses following encoding mechanisms -
XML1.0, MTOM, Binary
Read more differences - http://www.csharptutorial.in/2012/01/cnet-difference-between-web-service-and.html
I'll share the way I ended up doing this, that was part of the original question.
First, the problems I encountered:
With customErrors on (i.e. in production) the global HandleError
attribute swallows exceptions and renders your error view, but then you can't log it with an addon tool like elmah, since elmah never sees it. You could log it in your view I suppose, but it's a view, that seems wrong. The global HandleError attribute appears new in the MVC 3 RTM Visual Studio project template.
customErrors with urls for MVC endpoints returns 302 status codes. There is the redirectmode property, but you cannot match mvc urls in customErrors and use the ResponseRewrite mode. ( https://stackoverflow.com/questions/781861/customerrors-does-not-work-when-setting-redirectmode-responserewrite/3770265#3770265 )
Avoiding customErrors completely and handling everything custom in your app leads to a lot of complexity, IMO. (Iloved this: https://stackoverflow.com/questions/619895/how-can-i-properly-handle-404s-in-asp-net-mvc/2577095#2577095 , but it wasn't right for our project)
My solution
I've taken MVC out of the equation completely. I've removed HandleErrorAttribute
global filter in global.asax and focus entirely on the customErrors configuration, shifting it to use WebForm redirects and change to redirectmode to ResponseRewrite
in order to avoid the 302 HTTP response codes.
<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
<error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>
Then, in NotFound.aspx
page_load event, set the Response.StatusCode
to 404 and in Error.aspx set the code 500.
Results:
The goals for both have been achieved with the Elmah logs, the friendly error page, and the status code with one line of code on the code-behinds.
We're not doing it the "MVC Way" as the earlier solution does, but I'm OK with that if it's two lines of code.
Best Answer
So I'm not sure "terrible" is the best word here. However, it has limitations, and as soon as your needs do not fit how the membership provider was designed you end up with a lot of glue code. If you can use the membership provider out of the box, I would say go for it. As soon as you start writing a custom one I question using the membership stuff anyways.
In my experience the membership provider buys you...
I'm sure there's something else I'm missing but I think those are the big ones. Now when you need custom password management, two factor authentication, to work with an existing data model, or a whole host of other things you start to lose out. The code that's already written for you with the membership provide should take on the order of a few days to duplicate if you know what you're doing.