I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.
Related
Using the tip found in this answer, I've been able to include general WCF support while converting my .NET Framework 4.8 assembly to .NET Standard 2.0. However, my code relies heavily on Service Discovery.
In a brute-force approach I tried these packages:
System.ServiceModel.Duplex
System.ServiceModel.Federation
System.ServiceModel.Http
System.ServiceModel.NetTcp
System.ServiceModel.Primitives
System.ServiceModel.Security
System.ServiceModel.Syndication
...but none of them contain the supporting namespaces/classes.
Will it be possible to include Service Discovery support in my .NET Standard 2.0 assembly?
Sadly DiscoveryClient is .Net framework only
so you can't convert everything to .net standard/.net core.
I read some article about NServiceBus and i want use it, but i dont know it fully supported the .NetCore or not, i googled about it (and found some information like This), but it could not help me much, any one can help me?
UPDATE: Starting from NServiceBus 7.0.1 they introduce support on .NET Standard 2.0 and thus can run on .NET Core 2.1+.
Building endpoints with .NET Core 3.1 explains how to configure it on .NET Core 3.1 and generic host.
Original answer:
NServiceBus package has no dependency on any NetStandard so it means it cannot run on Core CLR. You can use it in .NET Core projects only if you target Full .NET Framework, not .NET Core.
As of 24 April 2017 NServiceBus does not support .net core. The most current public status is this https://particular.net/blog/nservicebus-on-net-core-why-not
However I can say that internally to Particular significant effort is being put into getting .net standard support shipped.
I will add this question to the list of follow ups for after we ship
Update: Particular Software announced upcoming support for .NET Core 2.0 on their company blog here: https://particular.net/blog/nservicebus-on-net-core-its-time
I am developing a WCF service (with .NET Framework 4.5), which should simplify the interoperability between clients developed in other languages and my SDK.
The problem is that when using the WSDL Importer providing the WSDL URL from service, it can only bring the Interfaces without any Type.
I tested with others URLs present in tutorials on the internet and the problem does not exist.
For example, when using the WSDL importer to http://www.webservicex.net/WeatherForecast.asmx?WSDL, Interfaces and Types are both brought.
The problem occurs even in a clean project Application WCF, testing with his IService1, and Service1 CompositeType (I'm using Visual Studio 2015).
In tests with Java clients, everything went well. But it was Java 8. Which leads me to suspect that it is a communication protocol version problem or something like this, but I can not know exactly where is the problem.
i'm going to build a instant messager
and now i have to decide how i implement the networking.
So far i only worked with Sockets (TCP or UDP). Now i heared about RMI (in Java) and want this in my C#-Chatapplication too.
There is .NET Remoting and WCF. I think building the instant messager with Sockets is not a good idea, right? But that should i use? .NET Remoting or WCF?
.NET Remoting seems to be the older technologie and is similar to Java RMI. I read that .NET Remoting is faster than WCT (article from 2007).
Which technologie should i use for my instant messager? I want to send formatted text from the richtextbox and inline images.
Furthermore i want to exchange files from chat-client to chat-client.
For .NET Remoting i found a tutorial which uses
ChannelServices.RegisterChannel(myChan);
But this is marked as obsolete. Is .NET Remoting a obsolete technologie?
Is it possible to send images and files with WCF or .NET Remoting or are Sockets the better choice?
I read that WCF is a collection of networking technologies (Web Services, Remoting, ...) but if i search for WCF and remote method invocation i only get examples for Web Services...
BTW: Later, i want to implement a Web-Client for my instant messager with ASP.NET. Are there some limitations respective to Networking (WCF/Remoting)?
Thank you :)
.NET Remoting is maintained for backward compatibility only as of .NET 3.0. Thus, if you are going to be using .NET 3.0 or greater, use WCF.
For your immediate use, I would suggest the NetTcpBinding. You can then select a more appropriate binding using the following chart.
.
Finally, to learn about WCF, refer to this SO question.
For your instant messager solution I would recommend WCF P2P here is an article to get you started Peer-to-Peer Programming with WCF and here it is an example of p2p on codeproject.
I am just curious to know the reason why it's not possible to host an ASP.Net web service other then IIS ? While in WCF it's possible to host a service in IIS, WAS or any console application.
Please clear the doubt..
ASP.NET is actually not specifically bound to IIS. The .NET Framework includes an HttpRuntime which may be used to write a custom hosting platform. You could easily write a console application, like you can for WCF, that will provide the ASP.NET runtime without IIS.
Technically speaking, you could also write an Apache module that hooked into either a separate .NET process hosting the ASP.NET HttpRuntime, or possibly hook directly into a .NET assembly. I don't know much about writing extensions to Apache, however assuming you can bridge the Apache unmanage to .NET managed gap, you would be able to host ASP.NET in Apache (which should be possible, you might need a native & managed C++ library to mediate.)
Microsoft's .NET framework is amazingly extensible. You can pretty much achieve whatever you set your mind to, if you have the will and the time (and perhaps the funds.) However, the .NET platform does encapsulate an immense amount of functionality, and it is up to Microsoft to choose how they spend their money. Naturally, they have their own business to worry about, and I would not expect them to expend tremendous amounts of money giving a leading edge to their competitors (it would be bad business, and quite a disappointing competitive practice, if you ask me.)