Does anyone tell me if it's possible to use WCF without .NET 3.0?
Our company develops a 3-tier client-server end-user solution based on .Remoting. One of the limitation of our project is using .NET 2.0. Unfortunately .NET 3.0 framework is too large to be included in our installation package and I don't know if MS license allows this.
But WCF might helps us to drastically reduce our efforts in some tasks.
Does anyone have a chance to use WCF from Mono?
Thanks in advance
--
Murat
Unfortunately this is not possible. System.ServiceModel and System.Runtime.Serialization assemblies are required and they are part of .NET 3.0.
Another important note is that WCF depends on HTTP.SYS (kernel level HTTP stack) which is available on Win2003, WinXP SP2 or higher, while you can still have .NET 2.0 installed on Win2000.
On the client side you could still have .NET 2.0 consuming the WCF service. You need to expose a basicHttpBinding endpoint for this purpose.
Could you use WCF and .Net 3.0 just on the servers at least? You could write your clients to consume simple ASMX style web service calls, and keep their install footprint small, while still getting the architectrual benefits of WCF in the server software.
That is part of the point of n-tier software... you can more easily upgrade critical peices of the application because they are on a few servers instead of on thousands of clients. I would re-examine .Net 2.0 requirement at least on your top tiers. You should see an easy cost-benefit improvement using the flexibility of the WCF platform even if you have heavy server install.
Well, there is WCF on Mono (http://www.mono-project.com/WCF) but I can't tell you how compatible it is. The whole thing would impose other restrictions as well, namely availability of Mono.
Apart from that WCF services can be exposed as web services with which you can talk to with mechanisms available on .NET 2.0
You can invoke WCF services (if they are configured to use SOAP over HTTP) from any client, using regular SOAP bindings/syntax. The service itself, however, needs to be running on .NET 3.0. If you have the ability to create just the service layer on .NET 3.x and leave the rest of your stack on 2.0, that might be a good way to go.
A lot of the features of WCF were piloted (using ASMX web services) in WSE 3.0, which runs on .NET 2.0, but you will need to look at WSE to figure out if it will actually save you time; it adds a lot of nice features for security/etc., but is not as easy to pick up and use as WCF.
Related
We have a net48 WCF client that wraps the API for this very hard to consume service (made in Java I believe, SOAP and WSDL) and that works great.
Problem is, we're in the process of porting our platform to net5 and I can't port this WCF code since WCF was largely left behind and CoreWCF is moving at a snails pace.
From an architecture standpoint, how do we integrate this into something that can be utilized? Previously we had a Windows Service that would fire off client processes to do the actual communicating. In the new architecture, we'd like to move to something like Hangfire.
Although you can call WCF services in .net core, it is subject to some restrictions. The WCF client in .net core only supports four bindings: BasicHttpBinding, CustomBinding, NetHttpBinding, NetTcpBinding, and there are not many security features in .net Core. My suggestion is to use WCF in the .net framework.
About core's support for WCF, you can refer to this link.
If you want to use WCF, I suggest you use .net framework instead of .net core. The alternative to WCF in .net core is gRPC.
I'm new to ASP.Net and I have the following scenario:
I have a .Net Framework project folder with several projects. All of them are configured .Net Framework 4.7.2 and I have a dependency I can not change at the moment. So migrating to .Net Core is not an option at the moment.
My question is the following:
What is the correct approach to add the functionality of a RESTful server with ASP.Net?
I don't want to implement a frontend. I just want to add a server to my projects.
In
https://learn.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server
it says, "In most cases, you don't need to migrate your existing applications to .NET 5. Instead, a recommended approach is to use .NET 5 as you extend an existing application, such as writing a new web service in ASP.NET Core."
How should I do that?
I'm really confused. Please help me.
Maybe some hints or links to other pages are enough to lead me into the right direction :)
Kind regards
Chris
It basically depends on your future preference and time, If the organisation is pretty much aligned with .netcore what you can do is you can easily migrate .net framework project to .Net standard and create a new .Net core project with API endpoints defined and you can easily refer the .Net standard libraries directly to it.
https://learn.microsoft.com/en-us/dotnet/core/porting/
But if you want to stick to .Net framework libraries, you can create basic Asp.Net core web API with DotNetframework, It is not a legacy framework, it has the latest release within 3 months and it is also battle-tested, But you can only host in windows machines unlike .Net core which you can host in windows/linux
https://developer.okta.com/blog/2018/07/27/build-crud-app-in-aspnet-framework-webapi-and-angular
any .net project that running on a web server supports REST calls. In fact if you make a webmethod?
Say this code:
<WebMethod()>
Public Function HelloWorld() As String
If keyid <> 123 Then Exit Function
Return "Hello World from server"
End Function
Then right out of the box with ONLY the above code?
The above supports SOAP 1.1, 1.2, and post (REST) calls.
So there is no "concept" in asp.net that you "adopt" SOME kind of RESTful server - the server you use in this case is IIS, and it supports REST calls out of the box, and always did from day one to my knowledge. You MOST certainly have to run a web server, but making REST calls does not require a "special" RESTful server, but just in fact that you running a web server - in this case IIS or so called internet services.
If you already have a project that supports and API just add an additional controller, assuming the functionality is not closely related to existing functionality.
I'm trying to use client-side Blazor to display some data, provided by existing WCF service. I was able to add a connected service reference, the proxy is generated. But when I'm trying to invoke it like this:
var client = new SoftConServiceClient();
await client.PingAsync(new PingRequest());
there is a bunch of errors, related to MonoTouch. By digging into the code of Mono, there is an explicit NotImplementedException in the constructor of the System.ServiceModel.DnsEndpointIdentity.
Am I right to assume that there is no way now to call legacy WCF service from Blazor client-side? If that's not the case, can anyone share a guide about how to properly do it?
Bonus question: if that is not possible, what would be the best option to approach this? Modify WCF to become REST-ish or just drop it and implement .net core api service?
Thanks a lot in advance!
Core does not support WCF very well instead of not at all. Especially in terms of authentication and security, such as the service created by using WS* binding. But for services created by using BasicHttpBinding or Restful styles services. We could invoke them normally on Core-based clients, whether using client proxy class or Channel Factory.
Please refer to below official repository.
https://github.com/dotnet/wcf
I suggest you re-construct your server project with BasicHttpBinding or using Asp.net WebAPI to create the backend service.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
Feel free to let me know if there is anything I can help with.
WCF is not supported in .NET Core out of the box, however there seems like there is a community project that is working on adding support for it in .NET Core
https://github.com/CoreWCF/CoreWCF
See What replaces WCF in .Net Core? for more info.
Am I right to assume that there is no way now to call legacy WCF
service from Blazor client-side?
Yes, you're right... WCF is not supported in Blazor client-side, and it won't be supported in the future. Microsoft has decided to stop supporting it as from .Net 5.0, and suggest to use Web Api instead.
Depending on how much you are invested in WCF, you may shift to Web API, perhaps gRPC, or go on using WCF, hoping that the efforts of the community to port and support WCF might succeed.
I was able to to put WCF 4.7.2 using techniques found with SoftCore in .Net 5.
I can also work SoftCore Hosted Example Blazor Server.
I have an existing website that is currently using .Net 3.5 and must stay that way because of our sharepoint integration. I need to write a web service/web api that the website will interact with (a method to send an email, for example). I also need to write a windows service that is going to do the same thing. The windows service will probably be .Net 4.5.
What framework should I use for the web service/web api so both environments can interact with it the best?
The very nature of web services, soap or rest, is that they are platform agnostic. This also applies to .net versions, you can have whatever version at the server and another version at the client and this surely will work.
I consider using .NET 4.0 Content Based WCF Routing. Currently I have a normal .NET 3.5 WCF Server. All Clients uses the compact framework .NET 3.5. Could there be a problem, if I will port my WCF Server to .NET 4.0?
Thanks for your answer.
Kind regards, pro
What does one have to do with the other? Content-based routing services inspect SOAP messages based on various possible criteria and select the proper endpoint to forward a request to. The routing service itself is just another WCF service with the standard assortment of WCF protocol and binding types. Receive request on an endpoint, process for given criteria, forward request to another endpoint.
But that said, mobile is pretty volatile and uncertain, and you can never be 100% certain until you test it. This is something you should be able to test in under 30 minutes; maybe even under 10.