sharing data between 2 applications

[radiax]

Iam trying to find a simple solution for sharing data between windows
applications( apart of using file system or remoting or MMF) . I tried using
class library by making data members "shared" but it seems that data cant
not be passed between applications. what am I doing wrong here? what are
"simple" possible solutions?
thanks

 

[Peter Rilling]

There really are few options for passing data. You really covered the main
ways. In short, there are no "simple" ways because the data has to be
marshaled across the process boundaries and the reason you cannot make a
static field visible in both is because static fields only live within the
process space for the app and each will have its own copy.

 

[radiax]

Among all the other ways which one would you suggest? The scenario is one
application will be producing data and another application will consume it
(it is one way relationship). Iam not sure if i should go with remoting or
using sockets. Any suggestions ?

 

[Leon Lambert]

There is really only 2 ways.
1) Some sort of remoting and marshalling of data. IE .Net remoting or
custom serialization and use sockets.
2) Shared data store like a shared memory database. This is the route I
have taken with our corporate applications. This is a pretty complicated
way to go but does result in the most flexible and highest performance
that i found. It also is flexible in that all different types of
enviroments can use it and not just .Net. Be prepared for a major task
though to go this route.

Hope this helps.
Leon Lambert

 

[Guest]

Another option would be to use WSE to achieve this (or "Windows Communication
Foundation" previously known as Indigo). This really falls under the hood of
sockets and custom serialization however the benefits are three-fold.

1) You don't have to do anything in terms of handling sockets etc. You can
simply create a SoapListener on a designated IP port and host a SoapService
(or Service(s)) there. Each client would simply need some way to know where
to send their requests.
2) There is built-in support for security and other advanced features.
3) Support for SOAP messaging which requires almost no effort on your part
and is supported industry-wide so you can communicate with clients written in
different languages. This is handled by the .NET serialization engine and
means you don't need to worry about manual serialization/deserialization of
the messages. It also makes any move to centralise these communications via
ASP.NET web services simpler to implement.

Hope this is of some benefit to you.

Also, if this is something you're thinking about looking into, check out
Thinktecture's WSCF (Web Service Contract First) tool for .NET - I've used it
to define my service interfaces that I host using WSE and it works well and
is easy to manage. It also means that your service interface can be reused in
many ways which can open up other options to you.

Hope this is of some assistance,

-Eric