I have a WCF service that I have to reference from a .net 2.0 project.
I have tried to reference it using the "add web reference" method but it messes up the params.
For example, I have a method in the service that expects a char[] to be passed in, but when I add the web reference, the method expects an int[].
So then I tried to setup svcutil and it worked... kind of.
I could only get the service class to compile by adding a bunch of .net 3.0 references to my .net 2.0 project. This didn't sit well with the architect so I've had to can it (and probably for the best too).
So I was wondering if anyone has any pointers or resources on how I can setup a .net 2.0 project to reference a WCF service.
One of those instances that you need to edit the WSDL. For a start a useful tool
http://codeplex.com/storm
What binding are you using - I think if you stick to the basicHttp binding you should be able to generate a proxy using the "add web reference" approach from a .net 2 project?
Perhaps if you post the contract/interface definition it might help?
Cheers
Richard
Thanks for the resource. It certainly helped me test out the webservice, but it didn't much help with using the WCF service in my .net 2.0 application.
What I eventually ended up doing was going back to the architects and explaining that the 3.0 dll's that I needed to reference got compiled back to run on the 2.0 CLR. We don't necessarily like the solution, but we're going to go with it for now as there doesn't seem to be too many viable alternatives
I was using the basicHttp binding but the problem was actually with the XMLSerializer. It doesn't properly recognize the wsdl generated by WCF (even with basicHttp bindings) for anything other than basic value types.
We got around this by added the reference to the 3.0 dll's and using the datacontract serializer.
Related
I wonder if there any way to extract the methods and the related input parameters from a WSDL web service in c#. Specifically i need a way to provide the endpoint URL of a web-service and get as a result the above information. Something like the "Add Service Reference" in VS. But what i want is to get those information by implementing a module and not by using any other tool. Does .NET provide any functions for that? I'm using .NET 4.5.
Thank you
You have 2 good options that come with .NET and you need to access both from VS command prompt.
wsdl.exe -> this does exactly what you are looking for.
wcftestclient.exe -> this helps you test any webservice even before you add it to your project.
EDIT 1: I think I misread your question. Well you can always use the generated class file by WSDL.exe in your application.
I'm (again and still) trying to consume some WCF services in Monotouch.
First approach: add a web reference in Monodevelop failed. It cannot create the reference file.
Then I tried SVCUTIL.EXE and get an error that the generic ChannelFactory is not available in Monotouch - I suppose because there is no reflection available.
Next I tried SLSVCUTIL.EXE from the Silverlight 3 SDK. This generates namespaces for the various services that differ from those created through SVCUTIL.EXE. As I have already lots of wrapper code I have to change a lot.
These questions arise:
Can I override the CreateChannel methods and return specialized channels for each service instead of being dependent on the non-existing generic version, as proposed by the exception that gets thrown? This means fixing the code generated by SVCUTIL.EXE.
How do I create a channel in an overridden method? I only have interfaces of my services. I googled and could not find any examples. What does code look like that has to be written in that method?
Totally unclear to me: what is the difference between the two service utilities?
If I get the namespace issue sorted out, will the stubs created through the Silverlight utility make my project work, or will that also suffer from the generic channel issue?
why can the Silverlight tool work without dynamically emitting code? What is the difference in the outputted code and what advantage does the dynamic version have?
which version of Silverlight is supported int MT. Can I use the tool of v4 or does it have to be version 3?
Does WCF in MT support streaming, like downloading large files?
WCF is a huge beast and it's very difficult to give general answers on it, too much depends on details. The general rule is that MonoTouch supports the same subset of WCF that was shipped with Silverlight (even if a few additions were made over time).
I suppose because there is no reflection available.
Reflection is available and works with MonoTouch. Reflection.Emit does not since Apple does not allow JIT'ing code on iOS devices. This can limit some API that requires code generation at runtime (but is not an issue if the code generation can be done at compile time).
... This means fixing the code generated by SVCUTIL.EXE. ...
Fighting/editing generated code is usually a bad idea (e.g. future maintenance). I suggest you try to use slsvcutil.exe before investing too much time in customizing the generated code.
... What does code look like that has to be written in that method?
The full source code for Mono's System.ServiceModel and System.ServiceModel.Web are available if you wish to provide your own channel (or customize the generated code).
Totally unclear to me: what is the difference between the two service utilities?
The SL prefix, in slsvcutil.exe, is for Silverlight. Microsoft made this tool to generate code that will only use the WCF subset available in Silverlight. Since this is the same subset supported by MonoTouch this is the best tool to use.
If I get the namespace issue sorted out, will the stubs created through the Silverlight utility make my project work, or will that also suffer from the generic channel issue?
It should work. That's how people are using (the available subset of) WCF with MonoTouch today. If there are issues with this (subset/tool) you can fill a bug report about it (with a test case) and we'll have a look at it.
I'm developing a .NET application that will have both a WinForms and a Silverlight client. Although the majority of code will be in the server, I'll need to have quite a bit of logic in the clients as well, and I would like to keep the client library code the same.
From what I could figure out so far, I need to have two different project types, a class library and a Silverlight class library, and link the files from one project to the other. This seems kind of lame, but it works for simple code.
My problem, though, is that the code generated by the SVCUtil.exe to access WCF services is different from the code generated by the slsvcutil.exe, and the silverlight code is actually incompatible with the .NET one: I get a bunch of problems with the System.ServiceModel.Channel classes when I try to import the class into .NET.
Has anybody done anything similar to this before? What am I doing wrong?
Unfortunately, as of Silverlight 3 and .NET 3.5sp1, there is no binary compatibility. You must share files, and maintain two separate libraries.
Silverlight 4 and .NET 4, however, will provide some level of binary compatibility. Depending on which assemblies you use in your client side, you may be able to use the same component in both Silverlight and Windows Forms.
I know it's too late to provide a solution but it was my problem too and I found Portable Class Libraries. It's a perfect solution to your issue.
Don't try and share a single proxy client amongst disparate clients - generate a proxy per client.
You can reuse the data classes between the projects using the add as link method you described. If a new version of the classes is created in the proxy, then you can just edit the generated proxy code files and delete out the class definitions. When you compile this up each client (Windows app and silverlight) will have its own version of the compiled class library, but it is all coming from the same source code.
I would like to connect to a SOAP web service using C#. Before I jump right in, trying anything Google throws at me I would like to ask what is the cleanest and best way to do it where most of the work is done for me.
I would like a high level method, where I give it a WSDL and it will basically handle a lot of things for me. I of course don't want to have to do any of the XML, except to see what it is doing to debug.
What is the nicest fanciest library/method that Microsoft has for doing this? Notice that I'm more concerned with optimizing developer time over performance, though there probably isn't much difference in this situation.
Here is a better explanation of what I'm trying to accomplish.
a better OOP approach to multiple SOAP web services
What Assaf said. You have the choice between using a Web reference (wrapper around WSDL.exe) and using a Service reference (wrapper around svcutil.exe). Service references are .NET 3.0+ and part of the WCF way of doing things.
Personally I still use Web references most of the time, but YMMV.
Edit: screenshot of the two menu options :)
That's what Web References in C# projects do.
When you add a web reference it parses the WSDL and creates strongly typed classes for the API.
No need for any fancy library... This is built-in functionality...
Just add a Service Reference to your project right from the context menu in Visual Studio.
I just built a asp.net 2.0 web site. Now I need add REST web service so I can communicate with another web application. I've worked with 2 SOAP web service project before, but have no experise with REST at all. I guess only a coupleweeks would works fine. after googling, I found it's not that easy.
This is what I found:
There is NO REST out of box of asp.net.
WCF REST Starter Kit Codeplex Preview 2 base on .net 3.5 and still in beta
Rest ASP.NET Example
REST Web Services in ASP.NET 2.0 (C#)
Exyus
Handling POST and PUT methods with Lullaby
ADO.NET Data Service
...
Now my question,
a) Is a REST solution for .net 2.0? if yes, which one is best solution?
b) if I have to, how hard to migrate my asp.net from 2.0 to 3.5? is it as simple as just compile, or I have to change a lot code?
c) WCF REST Starter Kit is good enough to use in production?
d) Do I have to learn WCF first, then WCF REST Starter Kit? where is the best place to start?
I appreciate any help here.
Thanks
Wes
If your looking for a project that templates a REST service, you're correct in saying there is no out of the box solution. However, RESTful web services are possible using WCF. The key part is to use several attributes when defining your service functions that let the .NET framework know that the function is not expecting SOAP. The main attribute to use is the WebInvoke attribute.
Here is an example from developer.com:
[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "/admin/post/{id}")]
void UpdatePost(string id, Post post);
The above code will actually be defined in an interface for your web service. The interface is created automatically when you create your WCF web service project. The actual code for the function will be placed in the class used to implement the web service.
Check out the article on developer.com for a full tutorial. It might seem overwhelming at first if your new to WCF, but after you dive into it, I'm sure you'll start to pick things up quickly. Here is the link for the artile: http://www.developer.com/net/article.php/10916_3695436_1
To answer all of your questions,
a) In .NET 2.0 you should be able to build RESTful services using WSE2.0, but if you have the option to use .NET 3.5, I would strongly recommend going the route of WCF since it is much easier and is designed with REST in mind.
b) Converting your project won't be hard at all. It's just a matter of targetting the new version of the framework in your project settings. Converting a web service from a WSE2.0 service to a WCF service will be a bit trickier though. The easiest way to do so would be to copy the code from each of the different web service functions into the class where you implement the new version of the function. Copy-Paste shinanigans :)
c) I'm not sure what this starter kit is that you're referring to. RESTful web services should be fully supported in WCF which was fully released as of 3.5
d) It would be helpful to understand WCF at least a little before beginning, but it's not crutial to understand it completely in order to get started. I would recommend just reading through the MSDN article on WCF at least once, and then begin working. I'm sure you will come across other questions as you begin, but you can look up those parts as you come across them.
Anyway, I hope this information helps. Good luck to you.
Edit
Some improvements have been made in the REST world. As Darrel Miller mentioned in the comments, WCF was not in fact built with REST in mind. I mis-spoke previously. In fact the framework is built with SOAP in mind and the WebInvoke attribute fills the gap. Although there is a lot of debate around the topic (Web API vs WCF REST), ASP.NET Web API is a new option for building REST services in .NET. I would strongly recommend that anyone who reads this post and is able to use .NET 4.5 in their project look into it as an option.
If you want a framework built with REST in mind, you should have a look at OpenRasta...
http://openrasta.org/
You could look at using ASP.NET MVC as a RESTful web services platform. WCF is probably the way to go in the long run, but MVC should easily handle it. Your actions would just need to be set up to return JSON or XML, depending on how you want to serialize it. MVC offers both a JsonResult and fully customizable ContentResult -- i.e., you serialize your response to a string property on the result and set it's type and encoding.
NOTE: MVC does require 3.5 SP1 so it's not going to be a 2.0 solution. If you require 2.0, you'll need to look elsewhere.
Use WCF REST.
You can use it today. The WCF REST library is ready to go, usable in production.
The WCF Starter Kit (see http://msdn.microsoft.com/en-us/netframework/cc950529.aspx) is something else. It delivers extra stuff; it includes a set of VS project templates, docs, samples and a few tools for building REST apps (client or server) with WCF. One cool tool is the "Paste Xml as Type" command add-in to Visual Studio.
On the other hand, building a REST client, in the general case, I'd recommend taking advantage of the HttpClient assembly in the starter kit (Microsoft.Http.dll). It's small, simple, and useful. A low-risk and high-value dependency even at the current "preview" status of the Starter Kit.
If you were consuming just a single REST service, then you don't need the general Microsoft.Http.dll assembly; you can do all the stuff it does in some code that uses WebRequest. But if you wanted a more general flexible class for manipulating client-side REST requests, then grab that Microsoft.Http.dll.
I'm not sure about a REST solution for 2.0. So I think WCF is going to be the way you'll have to go with this one. MSDN has a long introduction to it.
My personal philosophy is that if a technology is still in beta then I would rather not use it for something that will potentially be a production application so I would start with WCF since it was introduced in the 3.0 version of the framework.
3.0 and 3.5 is actually an update to the libraries, but the CLR is still 2.0 so if the libraries you're using are not deprecated or changed in the new frameworks it should be okay.
Take a look at this CodeProject for a starting point. It seems somewhat... hacky. Modernizing to WCF would be cleaner.
REST, or RESTFUL
Adding this to the System.Web in web.config will enable http get, and put.. aka REST-Like... but not full rest.
<System.Web>
<webServices>
<protocols>
<add name="HttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
</System.Web>