I would like to add an interceptor layer to my WCF service to send the Device ID to authenticate the device.
I am very very new to WCF Interceptors. Before I take all the time to figure them out, I would like to know if they even work with the Compact Framework.
So, do WCF Interceptors work with the Compact Framework and if so are there any special considerations I need to keep in mind as I research them. (Any C# examples of how to do this would be AWESOME!)
I am using Visual Studio 2008 SP1.
I haven't used WCF myself, but a quick glance at this article shows me you need the IChannelFactory and/or IChannelListener classes which are supported on .NET CF 3.5.
The article also has a downloadable sample app, which you probably can modify to run on .NET CF.
So I can't give you any considerations or gotchas, but it looks to me you won't be on a dead end road here.
Interceptors cannot be created on WCF for Compact Framework (NETCF). The IClientMessageInspector and similar constructs needed for interceptors are not present in NETCF.
You can add custom soap headers though. You just have to add them to each WCF Service Call.
Related
I am very basic in VB6 so sorry if I am asking an obvious question!
We have an old VB6 application and currently we need to do some re-enhancements in it. I want to somehow connect it to a WCF webservice to send and get files (WCF will take care of loading and storing them in DB).
Based on my researches, it is possible based on This article and some others, Now I am wondering if is it required to have .NetFramework installed on systems to do this?
You can use RESTFUL WCF Service and set the UriTemplate attribute for the method(OperationContract).
Full article for creating REST service
The article you have linked suggests that the VB6 code should call a .Net wrapper for the WCF service.
If you do that, then yes, certainly you will require the .Net framework to be installed on the machine that runs the VB6, because that machine will also have to run the .Net wrapper.
I'm working on project for old PDAs that run on the .NET 2.0 CF (compact framework). Right now we are using .NET 2.0 ASMX web services, but I find that severely limiting. It is missing all sorts of things like extension methods, funcs, actions, LINQ, generic data-structures like HashSet(of T), etc., that would be useful for getting stuff done.
Eventually we're probably going to get rid of the PDAs and replace them with some other technology. For that reason I'd like to, as best as I can, write a re-usable/RESTful-ish backend (thus WCF).
I've looked online, but haven't had much luck finding information. At the very least I'm hoping to upgrade the backend to .NET 3.5 for improved functionality. Is it possible?
if you just want the new framework libraries and c# syntax than your asmx services would work just fine on 3.5, no need to migrate to wcf.
if you want rest you should take a look at asp.net web api though it is .net 4 only.
I would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
I have a MVC pattern in place where I have been developing WinForms and WebForms against. Now, I would like to move onto Silverlight and thus need to 'web services'-enable my Model layer.
Where do I start? I can't seem to find any good resources. Many talk about EF or ADO.NET Data Services. What do I need to do to my Model layer to enable it for WCF REST?
There are many approaches you can take to build your server-side
ADO.NET Data Services - here is some documentation
ASP.NET MVC - if you do decide to use ASP.NET MVC, then this tutorial shows you how to access the service from Silverlight. Essentially Tim is showing you how to access the particular REST service exposed by ASP.NET MVC, but the same techniques (WebClient, etc) can be used to talk to any REST service
Build your own WCF SOAP-based service which implements the MVC pattern. This link shows you how to build and access WCF SOAP-based services in Silverlight.
Build your own REST service which implements a MVC pattern. There is a universal way to comsume any REST service from Silverlight, which is described here. To build the rest service you can use whatever platform you choose. You may consider the WCF REST support that comes out-of-the-box in .Net 3.5, or the WCF REST Starter Kit, which builds on the out-of-the-box REST support in WCF to give you some extra features. Or you can consider any other REST service framework of your choosing.
If you are going to proceed with the technologies you are talking about then forget completely about the term REST. What these technologies allow is you to do is object remoting over HTTP with the HTTP verbs. There is nothing wrong with that, just be aware of what you are trying to achieve.
The more you read and understand about REST the more confused you will get while trying to use Silverlight 3, ADO.Net Data Services, WCF REST Starter kit. These are all fine technologies to achieve what they were designed to do. Unfortunately, you will not learn how to do REST properly from these tools.
If you really want to do REST in .Net then start looking at OpenRasta.
A .net desktop application will send information to a central server, there will be potentially thousands and thousands of deskop apps sending info to my server(s).
The data will be small in size.
Would .net web services be good for this scenerio or would WCF be better suited?
What are the pros/cons?
I'd go with a WCF REST-based service, because you'll be able to transmit pure data without the overhead of the SOAP header (and other envelope nonsense) that comes with the SOAP-based classic .asmx web service.
the possibilities for throttling, concurrency, etc. are far more developed within wcf.
its a little bit more work in the beginning, but i guess that it's better suited for scenarios where you need to have full control over your bindings.
WCF is a more robust approach to SOA. Microsoft is committed to making it the primary framework for building the next wave of Microsoft business applications. The functionality available already, early in its lifecycle, is superior to plain old web services. It's only going to get better. By going with WCF early, you will be able to ride the wave and take advantage of future new functionality.
In some cases depends on the type and amount of data to send.
WCF will give you more options to tweak your calls.
On the other hand, I can't think of advantages of implementing asp.net web services over WCF. In WCF you could also implement plain 'old' web services
ASMX is like remoting, it's still around because it shipped with 1.0, but you shouldn't use it anymore if you are starting a new project. WCF will give you many more features and better tooling support.