is operator is falsely failing

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a Class3 that looks like this:
Class1 : BaseClass
Class2 : Class1
Class3 : Class2

where each of these classes are defined in their own projects/assemblies.
They are all built in the same solution with project references. I also have
a peice of code that looks this this:

System.Reflection.Assembly assembly =
System.Reflection.Assembly.LoadFrom("Class3.dll");
Type assemblyType = assembly.GetType("Class3");
object class3 = Activator.CreateInstance(assemblyType);

if (class3 is Class3)
XXXX;

if (class3 is Class2)
YYYYY;

This code has worked for years and just broke after converting all of our
projects from using assembly references to using project references. The
first if statement fails and the XXXX code is not called. However, the
second if statement passes and the YYYY code is called. Why is this?
Looking in the debugger, the class3 object is a type Class3 , which is a
Class2, etc. Any hints on what I can look at to find this problem? Thanks?
 
I believe it's because the Class3 type loaded from the DLL and the Class3
type created using project reference are not the same class even if they
have the same name.

- Shuvro

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.



Bob said:
I have a Class3 that looks like this:
Class1 : BaseClass
Class2 : Class1
Class3 : Class2

where each of these classes are defined in their own projects/assemblies.
They are all built in the same solution with project references. I also have
a peice of code that looks this this:

System.Reflection.Assembly assembly =
System.Reflection.Assembly.LoadFrom("Class3.dll");
Type assemblyType = assembly.GetType("Class3");
object class3 = Activator.CreateInstance(assemblyType);

if (class3 is Class3)
XXXX;

if (class3 is Class2)
YYYYY;

This code has worked for years and just broke after converting all of our
projects from using assembly references to using project references. The
first if statement fails and the XXXX code is not called. However, the
second if statement passes and the YYYY code is called. Why is this?
Looking in the debugger, the class3 object is a type Class3 , which is a
Class2, etc. Any hints on what I can look at to find this problem?
Click to expand...
Thanks?
 
How can I tell if they are not the same? Is there a way to compare a
project's DLL output using ILDASM or something else?

All the DLLs in the solution are copied to a runtime folder and ran from
there. The copy is done on a post build event in the project.
 
Well since my DLL name and the namespaces have not changed, this cannot be
the answer. Any other ideas?
 
I still think that Shuvro may be right. I suspect that Class C in
MyDll.ClassC is
not assignable from MyProject.ClassC.

string typeName="MyDLL.ClassC,MyDLL";
Type myType= Type.GetType(typeName);

if (typeof(ClassC).IsAssignableFrom(myType)) --> false

Regards,
Jeff
 
I just found the solution for the problem.

I falsly reported in an earlier post that "All the DLLs in the solution are
copied to a runtime folder and ran from there. The copy is done on a post
build event in the project." I was not running from the runtime folder. If
I ran the app from the runtime folder by double clicking the exe, it worked.
If I ran from Visual Studio, it did not work. I changed the Debugging -
"Debug Mode" Property from Project to Program and entered in the exe path for
"Start Application". That fixed the problem. With the property set to
Project, the exe was running from the local bin\debug folder and the DLLs
were loaded from the runtime folder.

Could some please explain why this behavior? Is this a security issue?
 
Bob said:
I just found the solution for the problem.

I falsly reported in an earlier post that "All the DLLs in the solution are
copied to a runtime folder and ran from there. The copy is done on a post
build event in the project." I was not running from the runtime folder. If
I ran the app from the runtime folder by double clicking the exe, it worked.
If I ran from Visual Studio, it did not work. I changed the Debugging -
"Debug Mode" Property from Project to Program and entered in the exe path for
"Start Application". That fixed the problem. With the property set to
Project, the exe was running from the local bin\debug folder and the DLLs
were loaded from the runtime folder.

Could some please explain why this behavior? Is this a security issue?
Click to expand...

I suspect that *some* DLLs were being loaded from the runtime folder,
and *some* were being loaded from the local folder. I suspect that the
same DLL (in name) was being loaded from *both* places, one in one
context and one in another - and that's where the problems would have
arisen.
 
Back
Top