tags:

views:

126

answers:

3

I have a Windows WinForms app that communicates with linux's mono remoting. Is it possible that i get the mono's system.data.dll and use it on windows instead of .net's built-in.

I wanted to use remotingformat of binary type, and ensure that both ends can serialize/deserialize it properly.

A: 

If Mono is following the specification, it should be binary compatible with MS's. IIRC it is the case.

If it is indeed a problem, why not just use mono on the client side too?

leppie
Nothing wrong with .net's winforms implementation, i'm thinking to just use a common System.Data on both ends so serialization/deserialization is guaranteed even if the remotingformat is of binary(instead of xml) type.
Hao
+1  A: 

The Mono assemblies work fine on Windows, as well as on Linux and Mac, etc. I have used Mono assemblies this way a few times, for various purposes.

It isn't always desirable to use the full Mono client on Windows, as it does have a different runtime behavior than the .net client. It's not quite at the same level of performance and capability (although it's getting closer all the time) as the Microsoft CLR.

Reed Copsey
+2  A: 

It's very unlikely that you will be able to achieve this without compromising Microsoft's .Net Install. The thing that will get you is that no matter what API you call, whenever the CLR attempts to load a DLL it will always get it from the GAC if a compatible version exists there.

WinForms will implicitly load the System.Data.dll in serveral cases and the CLR will do a GAC check. If you are using the MS version of WinForms this will resolve down to the MS version that is in the GAC. There is no way to break this without modifying the GAC.

Alll MS assemblies are signed with a private key that, AFAIK, mono cannot duplicate. So it seems like there would be no way for you to get your DLL loaded ahead of the built-in GAC DLL and hence no way to replace it.

JaredPar