MissingFieldExc eption in inherited class

[Roger Miller]

I'll try to keep my explanation as simple as I can but leave in the relevant
details.

We're developing in c#.

Our main application can dynamically load assemblies ( plugins) that
support a certain interface (to do "extra" functions). Our intent is that
these assemblies won't be updated once fielded, and should be ok, as long as
the interface they're built upon doesn't change. Actually it can change, you
just only add things, not modify/deleted previous ones.

In addition to the interface, we've developed a base class that does a lot
of boiler plate things that all of our plugins will need to do. Our plugins
are built on our base class.

This was going well until some of our plugins (compiled a couple of versions
back) started failing. Both our interface and base have been recompiled, and
version number updated - but not actually changed.

We've narrowed the failure to those that access a protected property in the
base class. It is indicated as the "field not found". But it hasn't
changed, does exist, and is populated. If the derived class uses a base
class function (also protected) that uses the property, it works fine. But
if the derived class accesses the property, it gives the error.

A couple of other factors.
1) If the plugin is recompiled against the latest version of the
base/interface dlls, it works fine. (even tho no change).
2) The error occurs when the derived FUNCTION that uses the protected field
fails..not on its actual use. I verified this a couple of different ways.

I'm confused because I build a simple test case to try it out and it doesn't
fail (unless I really do alter the base class or interface so the protected
property isn't there or its type is changed).

I also disassembled both version of the base class and interface and can't
find any substantial differences. A couple of sizes changed.

So I'm looking for any clues or things to try. I plan on eliminating all
base member access (no more protected member variables) and I think that
will solve it, but I'd feel better if I could more definatively say why it
failed, duplicate it in my test cases, etc.

***
Restating more simply
A is an interface.
B is base class implementing A.
B has a protected member q. B has a protected function p.
C is a class dereived from B.

C (dynamically loaded into my app)is build against version 1.0 of A and B
and can use p and q fine.

If the app is updated (along with A and B) to version 2.0, and C isn't..any
function of c using q fails with "field not found: q" error. Functions using
p work fine.
A and B didn't change source, other than to update version #.
***
Any thoughts at all are welcome,

Thanks
Roger

[Roger Miller]

I have finally returned from my great journey of discovery and solved my
problem.

First bread crumb was that the MissingFieldExc eption was due to the fact my
protected field was of a type defined in my interface. Through some testing
this boiled down to a type mismatch error. My derived plugin thought the
base class was talking about a different type.

This was confusing because the types appeared to be..and were
logically..exac tly the same. Looking at AssemblyQualifi edName property name
I could see they referenced different versions. If I recompiled against
another version #, it worked. However, that's not the end of the story. I
ran another test, where both referenced the same version number and it still
mismatched types.

Finally, I discovered that I was loading the same interface definition DLL
twice. Even if both versions were exactly the same (I copied them to make
sure), I would get the type mismatch.

What I gather from this is that
- Two interface DLL were loaded (v49 and V60) accidentally. My plugin was
built against another version (58). Since neither matched, it bound to V49
which was considered not compatible with my base class (which was compiled
against and bound to V60).

-In another scenario, I loaded the interface DLL twice, but the same
versions ( both
60). My plugin was build against (58). It happened that my base class
bound against one instance, and the plugin bound against the other. These
were considered incompatible.

I'm still reading and figuring out how the plugin figures out which one to
bind to, but in my case, having multiple interface's loaded was the mistake.

But if you have similar issues, I hope this is helpful.

Roger