views:

564

answers:

5

After some advice more than anything.

I have the following example.

Appication1.exe - Has object MyList

Application2.exe - Needs to gain access to MyList and interfact with the object as if it was created from Application2.

My question is - should I be using .Net Remoting (ie 2.0) or WCF or another technology stack? What frameworks are available to support this? What are the Advantages \ disadvantages to each?

I should note, that this is more of a 'helper' application and won't be used by anyone outside of the development team...

Any advice on this would be great!

Thanks

Ben

A: 

I think the resonable choice is to use .NET remoting. You would have to spin up a web service on Application1 for Application2 to talk to. The only real disadvantage is that "MyList" needs to be marked with MarshalByRefObject. MSDN says Remoting is now legecy stuff (.NET 3.0) in favor of WCF. But as far as I know, Remoting is the only game in town for cross-appdomin communication.

McAravey
Shouldn't "MyList" also be Serializable? Or the class/object it lives in?
dboarman
+1  A: 

It's hard to say. WCF is certainly a possibility. You have to have control of both apps of course and change App1 to support (either on a push or pull model) the data transfer to App2. If you don't necessarily need an on demand exchange of data, you could consider a database as the method of transferring data esp. if App1 already writes some data to a database. Then you can have App2 go grab the data it needs from there. Or you could even use the file system, if the exchange does not happen to often. Serialize out the list and grab it with App2. (I only suggest that because it sounds like you're trying to hook a dev tool into something that's already existing).

Remoting is an older technology that is fraught with difficult implementation and deployment issues. WCF is much cleaner and easier to implement. So, if it's between the two, I would definitely recommend WCF over remoting.

JP Alioto
+8  A: 

Its hard to say without knowing more details about your applications, but personally I would NOT use WCF for this scenario. WCF has a very heavy-weight pipeline and takes considerable effort to setup and use. Its API is also heavily geared toward web services, which would seem to be overkill in your case. Microsoft claims that WCF replaces remoting because they don't want to support remoting anymore, but having used both, I can say that WCF is not as good as remoting for moving data around inside homogeneous applications.

However, there are dozens of ways to move data from one application to another, all with their own pros and cons. A full discussion of all of these methods is beyond the scope of this comment. Can you add more detail about your usage scenario? What kind of data is in this list, how big is it, where did it come from, what kind of modifications are being made, does App 1 need to see the changes, is App 2 going to send the data somewhere else when it is done, etc...

+3  A: 

I'm assuming Application 1 is a production app, and Application 2 is the development-only helper app. If this is the case, your goal should be to minimize or eliminate any additional overhead in Application 1 related to supporting Application 2. So WCF, which is very heavy, should be eliminated as an option. Remoting also adds overhead.

You could serialize the object - maybe XML would be appropriate for this?

There are too many variables to this question to answer it completely. Can you provide more information on Application 1 and Application 2? Where do they run? Do the objects you are interested in change often? How do they preserve state?

Scott Ewers
I'm voting this up as it seems the most logical way to access the list without any overhead of Remoting or WCF. Have app1 simply serialize the list to either Xml or Binary formatter.
dboarman