the app config for the service process has:

<activated type="DAL.Query.Data.Remote, DAL.Query" />

A client application is creating an instance of this
object using either one of the following:

Remote remote = (Remote)Activator.CreateInstance(typeof
(DAL.Query.Data.Remote));

Remote remote = new DAL.Query.Data.Remote();

Both result in 'remote' containing a local Remote instance.

Remote inherits from MBRO. There are 25 other CAOs
registered they all work fine, client init is centralized
and verified to execute and does not except.

Is there any reason i would still get a local object even
though remoting configuration and registration is correct,
and for other types, 100% functional.

TIA for any suggestions, will provide access to source
with NDA as we've been unable to reduce/reproduce the
problem set so far.

Shaun Wilson

tried, but didn't help:

[LoaderOptimization
(LoaderOptimization.DisallowBindings)]
static void Main()

anyone know what LoaderOptimizationAttribute is supposed
to do?

At this point I completely restructede the code to resolve
the problem, which I should really note MUST be a bug.

If you're interested in what I did, read on, it's
otherwise completely unrelated to the problem:

Scenario: I have a typed dataset that facilitates user
buildable/dynamic queries. This dataset mainly acts as a
cache of data. As queries are made they are placed into
this dataset. If anything wanted to know anything about a
given query, everything ever known about it can be
gathered from the dataset. This will improve how
responsive our UI feels for a number of reasons.

Problem: What I need was remoted objects that handled
persistance or any extensive logic (performing a complex
query for us). DataAdapters didn't seem powerful enough to
do what I wanted. I also needed caching, which meant I
needed routines which actually treated this dataset as a
cache of data, thus when the data wasn't available in the
local cache the remote cache was queried.

Final Solution: I had problems getting my service object
to remote, and I think it had to do with my use of
statics, possibly an optimization bug. Ultimately I laid
out the two interfaces I needed (local operations and
remote operations, as they were), then established a type
which combined the methods from both interfaces. I term
this my service object. I have, in this example, a
dataset named QueryData, my service object is named
QueryDataServices. The service object exposes 'static'
members, these members represent our 'local operations'.
There are instance members as well, all the instance
members represent our 'remote operations'. It's modelled
that the QueryDataServices type is only ever instance by
it's own static members, it's not intended to be instanced
by client or middle-tier code, ever.

Hopefully if anyone else is trying to solve a similar
problem, this will give them something to consider that
actually works. I would have preferred a more segregated
approach by this one works for the time being. On a more
complex dataset I might consider public sealed class
QueryDataSet { public sealed Class1() { static Class1()
{} } } such that each 'grouping' of logic is made
available from an appropriately named static object (even
though it will likely still refer to a set of instance
methods on the service object/instance members).