[Mono-list] Application port to .Net, including Mono

[Danny]

FWIW, I have used interop on both MS.NET and Mono on Ubuntu with no
problems.  I think you're more likely to run into interop problems due
to the native library signatures than any platform oddities.  Just leave
off the DLL extension in your DllImport declarations and build one
version of the native code for Windows, the other for *nix and deploy
accordingly.  I think there is some weirdness there WRT to MAC (Apple)
OS's file naming, but I've no direct experience there.

As for #2, I'd make an wrapper assembly that is solely responsible for
interoping your native library.  That leaves the web service code
responsible for ONLY web service necessities, and gives you the ability
to host your component in a non-web-service host, such as a Windows
service (daemon) without copying core code around - or having to
refactor later - and the only real worrisome part being managing object
serialization properly, which is no big deal really.

Use interfaces to define your messages and your client side component
becomes a proxy object to the remoted server, web service or otherwise.
With web services you get proxy generation for free based on the WSDL
and with standard remoting you just use the configuration infrastucture
to get your proxy object instance of your interface.  This is more
nuts-n-bolts than WCF, which I never bothered to really learn, but we
use this approach alot and it works well.  Though you have more
components to manage in the long run, it gives you almost complete
control over how you can deploy the service using a once-and-only-once
and separation-of-concerns paradigm.


On 11/02/2010 02:59 PM, SaulToc wrote:
> 
> Hi Folks,
> 
> I have been tasked with "modernizing" a complex, distributed application.
> Part of that modernization involves discarding a proprietary TCP/IP-based
> messaging protocol and, in its stead, using Web Services.
> 
> As a proof of concept, I am considering taking a very small part of the
> application and writing a WS version thereof. For the sake of discussion I
> would describe the current implementation of this part as follows:
> 
> a. UI on nodeA connects to an inetd-like process on nodeB, asking this
> process to start another process,   
>     let's call it a "filesystem browser."
> b. the inetd-like process launches the filesystem browser and hands off the
> connection to the UI
> c. the UI can now obtain and display the contents of nodeB's filesystem.
> Note that the UI uses a dll that implements the aforementioned proprietary
> messaging.
> 
> Part of this POC is to not completely rewrite the application. The intent is
> to preserve, where possible, the existing application code and to replace
> only the plumbing. My current thinking is to realize this functionality via
> .Net as follows:
> 
> 1. Build the fileystem browser as a .dll (it is presently an .exe)
> 2. Implement the inetd-like process as a Web Service "wrapper" around this
> dll (interop implicated here)
> 3. Replace the client-side messaging dll with a .Net dll that offers the
> same entry points as the original dll.
> 4. This .Net dll would function as a client to the Web Service.
> 
> So the new implementation, at least its steady-state, would look something
> like this:
> 
> i.  UI sends a proprietary message to nodeB by calling into the new client
> dll of step 3. 
> ii.  client dll sends this propriety message via MTOM to the Web Service
> wrapper at nodeB
> iii. Web Service at nodeB makes an interop call to the dll version of the
> .exe file of step 1, passing the proprietary message to the same code that
> has always processed this message.
> iv. data returned by the dll, perhaps including a reply message, is returned
> by the Web Service to the 
>     client, thence to the UI
> 
> That's about as far as I've gotten. Some questions:
> 
> A. Does this seem a reasonable approach to this POC?
> B. Will the use of interop lend itself to Mono? I have read the FAQs and see
> that there seems to be pretty 
>     robust support for interop.
> C. Will the use of WCF lend itself to Mono?
> 
> I try to evangelize for .Net but am routinely and reflexively shot down
> because of a perceived lack of *nix support. This is my first foray into the
> Mono world and alot depends on it.
> 
> At any rate, I would be most grateful if folks who have dealt with similar
> problems, or those who simply can shed some light on such a matter, would
> offer their opinions.
> 
> Thank you.
> 
> -Saul
> company?
>