Common Resource for a .NET and a VC++ Application  
Author Message
OmidQRose





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

I couldn't find a better forum for my question. I'm developing a .NET network application using .NET Remoting(call it application A). Application A needs to communicate with another application which isn't developed under .NET platform(VC++, call it B). Application A sends requests for applicatin B in XML format. I need something like a common resource for both applications. Application A should be able to write the requests in the resource while applicatin B accesses the same resource and handles the requests asynchronously. I can't use SQL server as a common resource and I'm not sure whether Access is capable in such situations or not.

Any kind of help; suggestions, articles, source codes, etc. is appreciated.



.NET Development30  
 
 
Sean Hederman





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

I'd say that since it's just the two apps, Access will probably work OK. WHat about SQL Express Alternatively, just write each XML to a file. So application A would be creating XML fles, and application B would be reading them, and deleting them when processed.

 
 
RizwanSharp





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

YOu can't enable remoting to work between .Net and C++ based application because Remoting is .Net based technology... You can try exploring MSMQ Messaging Queue (Windows XP+) and i hope both application will be able to access it.

Also think about Web Services.

The best common resource will be Database, file based solution will introduce errors when file is locked by one application in Write mode, what if 6 clients want to write to that file simultainously. You need to think on all the things before you proceed.

Best regards,

Rizwan aka RizwanSharp



 
 
Sean Hederman





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

Actually, no, since I said that he should write multiple files, e.g. one per message.

But 10 out of 10 for thinking of Web Servcies, I must have been asleep



 
 
RizwanSharp





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

The innovation of the webserices is on the same idea that application from diversed technologies should be communicative. And today every programming language can manipulate XML so remoting will simply not work here but Web services will do.

Best Regards,

Rizwan aka RizwanSharp



 
 
OmidQRose





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

Thanks for replies. I'm not using .NET remoting for communications between app A and B. Actually there is another small .NET app which receives requests from app A and prepares them for app B in XML format. I'm not sure if I can install SQL express on clients so access may be a choice. Each client needs only one shared resource and only two apps consume the resource. Using files might be unstable in some circumstances regarding that app B should frequently access file system to see if there is any new incoming request. And about web services, did you mean that we should have a function(which returns new requests) and clients should repeatedly call it to see if there is a new request What about the performance leak at the server

I don't have any idea about using MSMQ. Do you suggest it as the best solution

TIA


 
 
Sean Hederman





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

Keep in mind, that unlike Access, SQL Express is free. As for App B rather than have it poll the file system, you could use FileSystemWatcher. As for the Web Services, I'd say App B should expose a method that clients call to deliver new requests. Also, what performance leak at the server

MSMQ is a very good option, but it sometimes can be a bit tricky to configure correctly, and you must handle the dead-letter queue correctly.



 
 
OmidQRose





PostPosted: .NET Framework Networking and Communication, Common Resource for a .NET and a VC++ Application Top

I get it now. You meant that every client(every B app) should expose a method that the server will call to send new requests. Sounds good. I need a solution that requires less configuration on the client side so FileSystemWatcher could be another option.