Janis, Mike's right in that you have two different interfaces. Your solution is to declare the interface in a single place and use that interface from both the service assembly and the plugin assembly. The question is where you define the interface. I figure you have two options: 1) Define the interface in your service assembly have the plugin assembly reference your service assembly. 2) Define the interface in a third assembly that is referenced by both your service assembly and by the plugin assembly.
In both cases, the interface you are using in both places will be the same interface type. Larry McCoy -----Original Message----- From: Mike Woodring (DevelopMentor) [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 9:52 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Using shared Interfaces when calling methods via Reflections? > In order for plugin to compile, it declares IMaster interface in it's > source, jsut like the Windows 2000 service does in it's > source. Namespaces > are identical. That doesn't matter. You're bumping into the fact that types are scoped by the assembly they're defined in. So two types that might otherwise be "identical" to one another in terms of name/structure are considered different if they are defined in two separate assemblies. So if abc.dll and xyz.dll both have the idential declaration: namespace Foo { interface IBar {} } Then you have two different types: "Foo.IBar, abc" and "Foo.IBar, xyz". Note that the name of the assembly is part of the type name. If abc.dll and xyz.dll were strongly named assemblies, the type names would be "Foo.IBar, abc, Version=#.#.#.#, Culture=neutral, PublicKeyToken=####" and "Foo.IBar, xyz, Version=#.#.#.#, Culture=neutral, PublicKeyToken=####". So when you pass a reference to an object that implements IBar as defined in abc.dll to a method that accepts arguments that refer objects that implement IBar as defined in xyz.dll, you'll get an invalid cast exception (or, in your case since you're using reflection, an argument exception due to a faiure to coerce the argument from one type to another). So the behavior you're seeing is expected. -Mike DevelopMentor http://staff.develop.com/woodring
