I am facing a problem.
Please explain if this is possible or not.
1) I created a Service Library (.Net 3.5)
2) I created a Windows Service (.Net 3.5), added ServiceHost and implemented my ServiceLibrary to work as a TCP Endpoint.
3) Next I created a Console Client (.Net 3.5) and tried to get data from my TCP Endpoint…(svcutil….proxy.cs generation). Worked absolutely fine.
4) I have a Windows Client(.Net 1.1). How do I configure it to use this new Service? I can't add Proxy.cs as it says that servicemodel cannot be found…
You will need to use a basicHttpBinding, which is backward compatible and can be consumed by a .net 1.1 client. You should be able to find plenty of useful examples on the web: Consuming WCF with .Net 1.1 Basic Binding. For example, this Link describes that binding and usage of Soap 1.1 to make it compatible with .Net 1.1.
For more details on different scenarios and the range of wcf configuration possibilities, try exploring this CodePlex Link, specifically the Application Scenarios section that provides details of different setups. I believe that you will require a basicHttpBinding rather than a netTcpBinding in order to work with legacy protocols. The netTCPBinding would assume that you have .NET 3.0 at both ends. See this MSDN Bindings Link.
Related
As I know DevForce use WCF for the communications between client and server.
But in newer version of .NET (Core 3.1, .NET5, .NET6 etc) WCF services not supported.
Is it possible to configure DevForce to use endpoints based on GRPC\WebApi instead of WCF?
As a trend for the future, you can try using gRPC, CoreWCF, and ASP.NET Core MVC instead of WCF. With the.NET upgrade, some technologies have been fully ported, but not WCF, and the replacement for WCF is the technology mentioned above.
The following article lists some of their characteristics for your reference, I hope it can help you.
I have developed a WCF service (framework 4.0) which should communicate with a client through BasicHttpBinding.
I have kept my (data)contracts in a separate assembly cause I want them to be reused by multiple clients.
Everything works as expected if I reference my WCF Service as a service (Service References) in a .net 4 client and set "Reuse types in referenced assemblies".
The problem is I have to consume the same WCF service with a .net 2 client.
In this situation the generated proxy is different from my shared assembly datacontract and I don't seem to be able to reuse it or cast it to the generated proxy.
Is there a way to solve this issue?
Thanks for your help.
Well, .NET 2.0 has no WCF API at all because it wasn't added until 3.0. So forget sharing the library because there's nothing to really share it with. The .NET 2.0 application will have to use the older WSE (Web Service Extensions) API. Documentation on WSE is available here on MSDN and you can download the last version of the WSE API that was made, 3.0 SP3, here.
You should have no problem getting WSE to talk to WCF via a basicHttpBinding. Things would only get complicated if you started using WS-* stuff and, even then, WSE supports a lot of that. It's just hard to find help on it since it's a deprecated API.
I came across with this situation. I have one already developed Application in 2.0, Now in this application i want to use one WCF Service that is developed in 4.0. How can i do this?
I tried the following
1. Regular Method Add the Service Reference and then use that. It didn't work for me.
2. I googled it and i got one more method, using svcutil.exe, but i dont have svcutil.exe with 2.0.
Waiting for the response.
Thanks in advance.
Windows Communication Foundation (WCF) was first introduced to the .NET Framework as part of .NET 3.0. It's not available with .NET 2.0.
If the WCF service exposes a SOAP endpoint then you may be able to use it through the Web Service Extensions (WSE) that were published for old versions of Visual Studio. See here: http://www.microsoft.com/download/en/details.aspx?id=10854 for details.
If you want to use a service written in .Net 4 with a .Net 2.0 project, you should be able to use basic http binding. That should allow it to interop with a client that knows nothing about WCF. It's similar to using an old school .asmx web service.
We currently have a half a dozen of project which originally have been built using .NET Framework 1.1 and WSE 2.0. But Microsoft's support for WSE is lacking and the latest version of it (3.0) only targets .NET Framework 2.0. Our new projects will use .NET Framework 3.5 and instead of hacking our self a WSE-support, we are currently looking for alternative approaches.
Our current projects use WSE to digitally sign the SOAP-messages with a X.509 certificate. This is what we require also for our future projects.
It seems that going with the WCF-route seems to be the smart choice but is there any alternatives? WCF seems to support X.509 certifications but we are little worried of its support for other platforms than .NET. Our clients need to be able to use Java-based software to connect to out services. And they've stated that it should be as easy as it has been before (when we were using Web Services). So WCF must be configured to use HTTP and SOAP.
Given the requirements of X.509, cross-platform interoperability and ease of use (HTTP & SOAP), is Windows Communication Foundation the right solution?
Yes WCF is the solution - it is API for building Web services and it is interoperable if you don't use MS/.NET specific features. But you should be aware that sometimes there are some problems with porting WSE services to WCF. I recommend to build very simple service in WSE (like Hello World) and secure it with certificates in the same way as real services. Then create Jave client to consume the service. After that replace WSE service with WCF. It will be your proof of concept. In a case of problems you can easily share this solution here or on MSDN to get some help.
One of our C# ASP.Net projects has some dependencies on the Microsoft WSE 3.0 library, in order to consume a WSE3.0 web service. However, we're migrating the project to Windows Server 2008, which does not support WSE3.0.
So I need to refactor the code to remove the dependency to WSE 3.0 but still maintain its functionality. The code is simply adding a username security token to the SOAP context and then invoking the web service. I'm not sure where to start though. I suspect I switch to WCF, and if so, is there any tutorial available online to help?
I'd start by creating a simple application, maybe a Console application, to be a test consumer of the existing web service. Create client proxy classes for this application by using "Add Service Reference", and pointing it to the existing WSE service. That should take care of most of the problems.
Once the simple console application works, you can do the same for your ASP.NET project.
Needless to say, it's way past time to update that WSE service to WCF, which is supported, and which will continue to be supported for a long time to come.
This article is a pretty good rundown of the differences between WSE 3.0 & WCF and migration recommendations. I'd start by getting the migrated service to run under the basicHttpBinding configuration (without user name/password authentication).
Once the service is running as expected and look at this article to see how to get the migrated service configured for user name/password authentication. The article is written for Silverlight use but there should be enough in it to get you going.