Passing Types without dll -- dotnet remoting

SEWilson
8/20/2003 6:20:07 PM

Yes, with an exception.

A client only needs an interface-compatible type defined
to reference a remote object. In general, attributes,
names and signatures should be preserved.

An exception to this is if your server has strong-named
objects hosted.

The popularized alternative is to create interface
libraries that the service objects implement interfaces
from. Then the interface lib is yoru shared lib. I dislike
this approach because it requires i make additional steps
toward getting references of remote objects (i like
the "new" syntax over using the Activator type).

I have been working on a tool called RCLGEN, Remoting
Client Library Generator. It basically reflects the
contents of an assembly and produces a single interface-
compatible .cs file you can compile to serve as a client-
side library for service objects. What I really would
rather see is .net compilers like csc.exe supporting "no
implementation" builds, e.g. MBRO classes are compiled
without method bodies, but non-remoted types are compiled
verbatim. The equivalent to creating a new Project config
in your IDE with a custom define of "NOIMPBUILD" and then
using #if !NOIMPBUILD #endif in all your implementation
bodies.

Hope that helps,
Shaun

[quoted text, click to view]

William Stacey
8/21/2003 9:59:02 AM

I thought you could use soapsuds to create a cs file with the type info that
you can compile on the client?
--wjs

[quoted text, click to view]

James Hancock
8/21/2003 1:05:50 PM

More information please! This doesn't seem to be well documented!

James Hancock

[quoted text, click to view]

SEWilson
8/22/2003 2:29:54 AM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[quoted text, click to view]

No. Remoting developes shoudl avoid soapsuds like the plague. The
resulting assembly and code is littered with WSDL bindings. On top of
that the tool fails to properly contruct compatible objects in some
cases (incorrect modifiers for instance, or an exception because it
can't figure out how to enum a remoted IDictionary etc).

Use shared libs until your staff has the time to whittle down the
errors from soapsuds, or write a tool that strips out method bodies
replacing them will dummy returns etc. While waiting, lobby with
Microsoft for a compiler option to produce an assembly that only has
implementation for non-remoted types.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP0XikKZcqAh+utlREQLcUACgqjdRWPgcJD2UMfYgAZbO6vVorIQAoNQK
lfLiYUsSGEiHi06xO6AT+5uA
=Fl/4
-----END PGP SIGNATURE-----

James Hancock
8/22/2003 11:16:14 AM

*sigh* I was afraid of this...

Using a common dll is a problem because the server could get updated before
the clients do (it's the system for updating the clients) thus it would die
if the shared dll gets updated.

I'm liking web services more and more all of the time...

James Hancock

[quoted text, click to view]

William Stacey
8/22/2003 7:05:22 PM

[quoted text, click to view]

Not if you use a shared interface dll. As long as you still implement the
interface at the server, you should be ok. If you need to update the
interface at the server, use another class that implements the new
interface.

--wjs

James Hancock
8/26/2003 1:49:42 PM

gross... but if that's the only resonable way, that's the only reasonable
way.

[quoted text, click to view]

Ice
8/27/2003 9:50:16 AM

use smart client deployment to ensure client/server get updated at the same
time.

ice
[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet remoting

dotnet remoting : Passing Types without dll