I've got I admit that I'm probably too dumb to fully learn and understand WCF. :(
On the other hand I had learned and used xmpp pretty well ( using MatriX XMPP library ).
So I wanted to ask, maybe there are some other libraries that help passing data from one computer to another to make life simple?
i.e. a library that would open a port/connection and both listen to incoming commands from other computers, as well as be able to send such commands to other computers that are listening to it.
Thanks!
WCF is not a hard technology... there is a learning curve, but ultimately someone who has taken the time to learn how to do it can easily implement the functionality in a couple of minutes.
i.e. a library that would open a
port/connection and both listen to
incoming commands from other
computers, as well as be able to send
such commands to other computers that
are listening to it.
Not really. Most of WCF involves setting up your app.config files so that they work on both ends. And I doubt there are any libraries that can do that for you.
You simply HAVE to generate and implement a service contract and implement the endpoints/meta data.
MSDN actually has a very decent tutorial. Getting Started Tutorial
Even if you DID find a "helper" you should still take the time to learn the technology so that you are prepared to troubleshoot and fix it when it breaks.
And if:
I've got I admit that I'm probably too
dumb to fully learn and understand
WCF. :(
were true... you wouldn't be a programmer.
My journey to understanding WCF happened right here on Stackoverflow... you can check it out at : Cross Application Communication (C#).
It might help you understand a little bit better.
Two options come to mind.
If you want to use WCF, the check out ECollective from SOA Collective. Uses managed mode Discovery to create a config-free WCF client, abstracting all of the things that makes WCF hard like bindings and behaviors.
If you want to use something other than WCF, check out NServiceBus.
Try the Idesign Website ... they have a WCF library that you can download and use in your projects.
Related
Please forgive the newbie question. I've spent the last three hours researching this, and I can't quite find the right answer, or perhaps I just don't believe it's as simple as it looks.
I need to deploy an application such that an application on the server-side does the heavy lifting, database wise, and the client-side version is fairly lightweight.
I have built a Data Access Layer class library (or at least a dll) that does all the heavy lifting. I have built a Windows Forms application that could serve as the lightweight client. They see each other. They talk to each other. They work happily together.
I'm kind of hoping all I need to do is put the dll on the server, point the reference to it in the client, and all will be well. The dll will run its code on the server, using server resources, and the client will run on the client. It's what the various websites seem to suggest, but it looks too simple.
Do I need to configure something like remoting on the server? Do I need to use System.Runtime.Remoting for something? Or is it really as simple as it looks?
Again, please forgive so basic a question.
what you are trying to do is build Client/Server application,
where you have
Client
client domainDomain
server Domain
Dal
Data
you will need to enstablish http conntection between client domain and server domain .
the common way to do this is using WCF
Explain the different tiers of 2 tier & 3 tier architecture?
http://www.codeproject.com/Tips/642296/Hello-World-Basic-Server-Client-Example-of-WCF
http://www.codeproject.com/Articles/14493/WCF-Basic-Client-Server
oh and welcome to stack overflow!
Well, you could use System.Runtime.Remoting, but that is a deprecated technology, i suggest using WCF for communicating between the client and the server.
I'm writing a web server app for the first time, and I'm not really sure that I know what I'm doing.
Basically I have some server side C# code and a native iOS app. I need to be able to push updates from the server to the app. The method which we have decided to use is Long Polling, and I can see three ways of doing this:
1) Writing my own web server in C# - not neccesarily tempting as it requires re-inventing the wheel
2) Using WCF - I've seen a few articles about how to implement long polling over WCF, but the tutorials that I've seen all seem to use clients which are implemented in .NET WCF which is not applicable for me as I need to use an iOS app.
3) Something else, possibly using IIS - I don't really know where to begin with this option.
Can anyone recommend a good tutorial, or exemplar project which uses standard HTTP to implement long polling with a C# server? So long as it's using standard HTTP, I'm confident with the iOS side of things.
Obviously if there's an even neater way of doing things then I'm all ears as well.
I would highly recommend that you investigate SignalR which allows you to achieve exactly what you are after. There are many iOS tutorials as well as HTML / JavaScript and of course C#.
One of the benefits of SignalR is that it tries to use the best technology available on the various devices and down-grades until it works. So, will start with Web Sockets for example and fail down to long-polling if nothing better is available.
Alright guys, I'm in a little over my head on this one and am hoping someone can point me in the right direction, as I'm not really sure how to implement this.
I've got a piece of hardware that exposes a c#.net API. Great. Works wonderfully. I want to collect data from this hardware using the API (so, a small c# app that does what I need) and then display the results on a web page. Currently, I have the c# app grab data I care about and stick it in an RRD file, then I have the web page load the relevant data and display it to the user.
My question, then, is what do I do when I want to expose some of the API functionality to the user? How do I go about making the 2 projects talk using .NET?
Some clarification: The reason there are two parts is due to modularity. The attached hardware and API can change, but as far as any client request is concerned, nothing's different, everything's just a web request to them.
Very little experience in big .net projects, so if you've got a better idea, let me know.
The easiest way I can think of would be to use something like NServiceBus to post a message to the other component which communicates with the hardware. The hardware piece would pick up the message from the bus, process it and put the response back on the bus.
It's not a perfect solution, but I think it's definitely workable.
You should be able to find everything for it here.
Left it here for a few days to see if anyone else had any ideas. I ended up scrapping the whole idea and consolidating everything into the web app. Not my initial preference, but it works okay. Thanks to Terrance for the brainstorming session under my question.
Easy. Create a class library for the device handler. Add a public class which exposes a nice interface for the web app. Add a reference to the class library. Create your class and use it.
I'll explain breifly my situation and hopefully you will be able to advise if what im wanting to do is possible.
I have an existing java application that I am wanting to split into modules. To handle and control these modules Im going to write a module manager in C#.net. Due to the size of the existing program the bulk of the existing modules are not going to be rewritten in .net yet and remain as java modules.
Is it possible to call a java "module", pass it parameters and have the java module return a value ( other than an int )?
I apologise for not knowing much about this area.
Kind Regards
Ash
Hmm... maybe some kind of MessageQueues like MSMQ, Apache ActiveMQ or IBM WebsphereMQ can solve your problem.
On the queues you can store and receive XML-Messages with all the Information you need.
Some information about this can be found here:
http://msdn.microsoft.com/en-us/library/ms973816.aspx
Another approch can be to work with console output .. but IMHO this is not a good solution.
I would instantiate the Java as a separate service and call it using (say) web services, Hessian etc.
Alternatively, have you looked at jni4net ?
If everything's in Java, then why the effort in moving everything to C#? From what you've said it'd make much more sense to write the module manager in Java and just keep the codebase all in one language (unless of course I'm missing something, in which case ignore!)
If you really need to do this then I'd say a web service is the nicest way to go, there's other hacks and various tools around that you could use, but a web service would completely abstract the language away and makes things much easier to consume.
I haven't tried this either but hopefully reading this thread helps you... :)
Java - C# interop
You can expose your Java module as a soap web-service and consume it from C#.
Here you can read about Axis one of the Java Soap engines and quick tutorial how to create and call it from C#.
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.