I'm reading a book which says:
Obtaining a TypeInfo object forces the CLR to resolve the type by ensuring that the assembly
that defines the type is loaded. This can be an expensive operation that can be avoided if all you need
are type references (Type objects). However, after you have a TypeInfo object, you can query many
of the type’s properties to learn more about it. Most of the properties, such as IsPublic, IsSealed,
IsAbstract, IsClass, IsValueType, and so on, indicate flags associated with the type.
below is the some source code:
public abstract class Type : ... {
public bool IsPublic { get; }
public bool IsSealed { get; }
public bool IsAbstract { get; }
...
}
public static class IntrospectionExtensions {
public static TypeInfo GetTypeInfo(this Type type);
}
public abstract class TypeInfo : Type {
...
}
My question is:
The author seems to mean that you need to call GetTypeInfo method in a Type object which causes CLR to load the assembly first, then you can query IsPublic, IsSealed, IsAbstract, IsClass, IsValueType.So it seems that you cannot query those properties before calling GetTypeInfo method. But my understanding for assembly metatable is, a referenced type 's basic information such as if the type is a class, abstract etc is stored in the referencing assembly's metatable, so when the code in the referencing assembly wants to query the basic information of a type that's in an external assembly, the CLR just needs to read the metatable in the referencing assembly which is the current executing assembly, CLR doesn't need to load/read the external(referenced) assembly, is my understanding correct?
TypeInfo is part of Reflection. Everything in Reflection tends to be an expensive operation.
TypeInfo is used for late binding - meaning your code doesn't know what type it is working with. IE, you are working with Generics or Plugins.
If you aren't doing late binding (IE, you code knows exactly what 'type' you are working with, you don't need to do anything like TypeInfo.
Edit: I haven't read this, but this article (or maybe some google research) on why reflection is slow can help you understand your question: https://mattwarren.org/2016/12/14/Why-is-Reflection-slow/
Related
The .NET Assembly class contains a method (GetExportedTypes()) and a property (ExportedTypes).
The documentation for these seems identical ("Returns a collection of all public visible types in the assembly"). Is there any difference between these ? or is this something related to historical reasons with the Assembly class's API ?
Looking into .NET sources using ILSpy returns following ExportedTypes implementation:
public virtual IEnumerable<Type> ExportedTypes
{
get
{
return this.GetExportedTypes();
}
}
However, classes that inherits Assembly class can implement the property differently, so you probably shouldn't rely on GetExportedTypes() and ExportedTypes doing exactly the same thing.
I created the Class1.GetChild<T>() where T : DependencyObject extension method in lib1.dll assembly. After that, all assemblies that depends on lib1.dll failed to compile with error:
The type 'System.Windows.DependencyObject' is defined in an assemebly
that is not referenced. You must add a reference to assembly
'WindowsBase' etc...
Why dependent assemblies requires WindowsBase even if they don't use GetChild?
.
To reproduce (vs2010 .net4):
lib1.dll (references WindowsBase)
namespace lib1
{
public static class Class1
{
public static T GetChild<T>(this DependencyObject src) where T : DependencyObject
{
return default(T);
}
}
public static class Class2
{
public static int SomeExtMethod(this string src)
{
return 0;
}
}
}
lib2.dll (references lib1 but not WindowsBase)
using lib1;
class someClass
{
void someFct()
{
"foo".SomeExtMethod(); // error: The type 'System.Windows.DependencyObject'
// is defined in an assemebly that is not referenced.
// You must add a reference to assembly 'WindowsBase' etc..
}
}
.
Update:
I think there's definitly something when mixing generic methods and extension methods. I tried to demonstrate the issue in the following sample:
// lib0.dll
namespace lib0
{
public class Class0 { }
}
// lib1.dll
using lib0;
namespace lib1
{
public static class Class1
{
public static void methodA<T>() where T : Class0 { } // A
public static void methodB(Class0 e) { } // B
public static void methodC(this int src) { } // C
}
public static class Class2
{
public static void methodD(this String s) { }
}
}
// lib2.dll
using lib1;
class someClass
{
void someFct()
{
Class2.methodD(""); // always compile successfully
"".methodD(); // raise the 'must add reference to lib0' error depending on config. see details below.
}
}
A, //B, //C -> compile ok
A, B, //C -> compile ok
//A, B, C -> compile ok
A, //B, C -> raise error
A, B, C -> raise error
//A means methodA is commented. As Damien pointed out, type inference might play some role. Still curious to know the ins and outs.
Your situation has been answered by Microsoft here:
https://connect.microsoft.com/VisualStudio/feedback/details/668498/problem-with-extension-method-in-c-compiler
There are other use-cases as well independent of extension methods which produce this error wrongly.
Consider this:
Define a generic method in a type, say TP1, defined in library say LB1.
Type constrain the generic method on some type defined in some other library LB2.
Define another method in TP1.
Now in your library reference only LB1 and try to call the second method of type TP1
If you don't use TP1 but some other type defined in LB1, you do not get the error.
Also, even if one of the method of type TP1 expects a parameter of the type defined in LB2 (and you do not call this method) it does not produce this error
When one assembly depends on another assembly, the first assembly also depends on all the dependencies of the other--regardless of what is used. Assembly dependencies are effectively decoupled, another version of either assembly can be deployed after compilation, the compiler can't know that under circumstances like this one or more of the dependencies in the second assembly won't be used by the first assembly.
To solve the issue you can simply add a reference to WindowsBase.
Or, as prashanth points out, put the SomeExtMethod into a different assembly so code that uses that doesn't need to take a dependency on WindowsBase.
Update:
If you don't use anything from an assembly, you don't need any of its dependencies. But, as soon as you use one assembly, you need all the dependencies of that assembly as well. This is apparent in the way Visual Studio add references. If you add a reference to an assembly, it will copy all the dependent assemblies (not registered in the GAC) into your debug/release directories along with the assembly you added.
Update:
As to the compile error: that's the way it was written--there may be no other reason. Is it a good idea to get a compile error if you don't reference dependent assemblies? Maybe, you're likely to use something from a reference and that might use something directly from the references references--better a compile error than a deployment error.
Why not a compile error on every non-referenced secondary dependency? Again, it was written that way. Maybe an error here too would be good; but that would be a breaking change and would require really persuasive reasons.
I'm not sure this can be answered by anyone other than someone on the compiler team. I'm now thinking that it's to do with type inference - but whereas §7.6.5.1 Method Invocations talks about inference, §7.6.5.2 Extension method invocations is silent on the matter - despite the fact that inference obviously does take place when searching for applicable extension methods.
I think it's attempting some form of inference before it's performing the comparison on identifiers (which would immediately rule out the extension method since it's got the wrong name). Obviously, it can't perform any form of inference for this type if it's unable to understand the type constraints.
Hence, when you change your type constraint to just class, it now successfully passes over this method - it can infer a type parameter, but it now eliminates this extension method successfully.
When you reference another assembly, I assume the compiler needs to be able to parse any method signatures defined in that assembly, so it knows where to go to find that function if it sees a call to it.
If you replace your GetChild() function with
public static T GetChild<T>(this T src)
{
if (typeof(T) == typeof(DependencyObject)) return default(T);
else return default(T);
}
or something similar to that, it does not require you to include the reference to WindowsBase that you're running into. But if you add where T : DependencyObject to the signature, it does require it.
Effectively, you can use whatever assembly references you want in a project, so long as you don't expose them in any way. Once you expose them, then every other project which uses your library needs to be able to handle them, and thus requires those references themselves.
Maybe ILMerge would solve this problem. The idea is you create 2 dlls and merge them into one. That way you can have a single dll but reference it twice. Then way you can separate the GUI code from other code and only add the reference that you need to the particular project.
The answer is simple. It is because the method is decalre as public. This mean that it is visible to lib2.dll (in your case.) In other word you can call this method.
It also has a constrain that only classes inherited from DependencyObject can call this method. So that is the reason why you need to reference 'WindowsBase'.
I'm looking for all implementations of IHandle<> in my assembly.
public interface IHandle<T> where T : class, IEvent, new()
Those classes looks like
public class IHandleEventX : IHandle<EventX>{...}
public class IHandleAnotherEvent : IHandle<AnotherEvent>{...}
Currently, I got the following code.
aLoader.LoadImplementationOf(typeof(IHandle<>));
// my aLoader class method
public void LoadImplementationOf(Type genericInterface)
{
// theres another foreach here, to iterate over all assemblies
foreach (Type aType in allMyAssemblies.GetTypes())
{
var interfaces = aType.GetInterfaces();
foreach (var currentInterface in interfaces)
{
if (!currentInterface.IsGenericType) { continue; }
// the statement below always return false
if (currentInterface.GetGenericTypeDefinition() == genericInterface)
{}
// those two statement (FullName and AssemblyQualifiedName), works as expected
if (currentInterface.GetGenericTypeDefinition().FullName == genericInterface.FullName)
{}
if (currentInterface.GetGenericTypeDefinition().AssemblyQualifiedName == genericInterface.AssemblyQualifiedName)
{}
// those below also fail
if (currentInterface.GetGenericTypeDefinition().IsAssignableFrom(genericInterface))
{}
if (genericInterface.IsAssignableFrom(currentInterface.GetGenericTypeDefinition()))
{}
// can't do currentInterface.GetGenericTypeDefinition() is genericInterface compiler error
}
}
Why comparing types fail, but comparing types fullname property works ?
Also, whats the best way to do this?
Edit: I rewrote the sample, using only one assembly and IsAssignableFrom worked. I'll investigate and update here later to see why isn't working using more than one assembly - as #HansPassant pointed out
It's working now, but I'm not sure why...
I was working with 3 assemblies.
Asm Loader, there was only de ALoader class there
Asm Domain, with interfaces IHandle<>, IEvent<> and classes IHandleEventX, IHandleAnotherEvent
Asm Test, my test project, I was calling aLoader.LoadImplementationOf(typeof(IHandle<>)); from here.
Projects References.
Loader doesnt references any project.
Domain references Loader (there was another IInterface on Loader, implemented on Domain)
Test references both Loader and Domain.
So I moved my interfaces IHandle<> and IEvent<> from Domain to Loader and removed the reference from Domain to Loader, now, its works.
Its still not clear why the IsAssignableFrom failed when IHandle<> was in the domain. It only worked when my IHandle<> and ALoader are in the same assembly.
Well, in the end, that was my fault, I was loading de assembly in two load contexts.
I think it's about reference comparison, considering that Type is a reference type.
Use:
Type.IsAssignableFrom
Good luck.
That's because Type.FullName doesn't fully describe a type. You only get the namespace name and the type name. But .NET also includes the properties of the assembly in which the type resides into the type identity. Display name, [AssemblyVersion], Culture, PublicKeyToken and (indirectly) ProcessorArchitecture. You want to compare Type.AssemblyQualifiedName instead.
The diagnostic for failure like this is that the source code that contains the interface definition is getting compiled into multiple assemblies. Which in itself is almost always a mistake, you want to make sure that such an interface type only exists in one assembly. And any assembly that uses the interface type has a reference to it so they all use an identical type.
The rules for type identity were loosened somewhat in .NET 4, a type can be identical if it has the same GUID. The underlying core for the Embed Interop Types feature. But that only applies to [ComImport] types, I doubt that's the case here.
The code below works great. If the Get and Use methods are in different assemblies, the code fails with a RuntimeBinderException. This is because the .Net runtime system only guarantees commonality of anonymous types (<string, int> in this case) within assemblies.
Is there any way to fool the runtime system to overcome this? I can inspect the object in the debugger on the Use side, and the debugger can see the relevant properties.
class Program
{
static void Main(string[] args)
{
UsePerson();
Console.ReadLine();
}
public static void UsePerson()
{
var person = GetPerson();
Console.WriteLine(person.Name);
}
public static dynamic GetPerson()
{
return new { Name = "Foo", Age = 30 };
}
}
Use an ExpandoObject instead of an anonymous type. This should allow you to cross assembly boundaries safely:
public static dynamic GetPerson()
{
dynamic person = new ExpandoObject();
person.Name = "Foo";
person.Age = 30;
return person;
}
In general, anonymous types should really only be used within the same method in which they are generated. Returning an anonymous type from a method is, in general, going to cause more problems than it solves.
The cause of the problem is that anonymous types are internal to assemblies. That's why the Dynamic Language Runtime don't allow you to access properties from another assembly.
One solution is explained in this post. You can put an custom attribute in the assembly that defines the anonymous type allowing the other assembly to access its internals.
Another solution is returning an object of a public class (with public properties). That will, of course, kill the advantages of the anonymous type.
A third solution would be using an ExpandoObject as suggested by Reed Copsey.
If you still want to use the anonymous type, you could write a dynamic class that "decorates" any anonymous type and exposes its members. Such a class would have to implement the IDynamicMetaObjectProvider interface and access the decorated object via reflection. Possibly, this stuff was already implemented by someone out there.
Another good solution might be to use tuples, which were introduced in .Net 4: http://msdn.microsoft.com/en-us/library/dd268536.aspx
Here's a poor man's workaround; Newtonsoft.Json to the rescue, as serialization roundtrip generates dynamic type instances visible to your/working assembly.
public static class TypeExt
{
// roundtrip json serialization to enable access to dynamic members and properties originating from another assembly
public static T JClone<T>( this T source ) { return JsonConvert.DeserializeObject<T>( JsonConvert.SerializeObject( source ) ); }
}
impromptu-interface
http://code.google.com/p/impromptu-interface/
Will let you use the the anonymous type instance across boundaries but you have to declare an interface that matches it's signature or at least what you want accessible from it's signature.
I have a set of classes, each one is a different strategy to do the same work.
namespace BigCorp.SuperApp
{
public class BaseClass { }
public class ClassA : BaseClass { }
public class ClassB : BaseClass { }
}
The choice of which strategy to use is configurable. I want to configure only the class name 'ClassB' instead of the full type name 'BigCorp.SuperApp.ClassB' in the app.config file.
<appConfig>
<SuperAppConfig>
<Handler name="ClassB" />
</SuperAppConfig>
</appConfig>
However, the reflection calls fail because they expect the full type name, particularly
Type t = Type.GetType("ClassB"); // results in t == null
BaseClass c = Activator.CreateInstance(t) as BaseClass; // fails
How can I get this to work while configuring only the class name? Concatenate the namespace to the class name for full type name? Is there another reflection call that works?
If you think this is useless and I should expect the configuration to contain the full type name, I am open to that solution! Just provide rationale to convince me.
(I will not be loading a type from outside this assembly/namespace)
Either use the assembly-qualified-name, or get hold of the Assembly and use Assembly.GetType(name). In this case, since you want the types in the config file, assembly-qualified is a valid way to go - but since you know all your types are in the same assembly:
Assembly assembly = typeof(SomeKnownType).Assembly; // in the same assembly!
Type type = assembly.GetType(name); // full name - i.e. with namespace (perhaps concatenate)
object obj = Activator.CreateInstance(type);
The static Type.GetType(string) has probing rules that often cause confusion... it looks at the calling assembly, and a few system assemblies - but not all loaded assemblies.
Since you know all classes will be coming from the same namespace, configure it once and use that:
<appConfig>
<SuperAppConfig handlerNamespace="BigCorp.SuperApp">
<Handler class="ClassB" />
</SuperAppConfig>
</appConfig>
Edit: I changed name to class to better denote the meaning of that attribute.
(I will not be loading a type from outside this assembly/namespace)
because of the above line, it is safe to assume that you know what the namespace is. Couldn't you do something like:
Type t = Type.GetType("Namespace." + className);
BaseClass c = Activator.CreateInstance(t) as BaseClass;
If you expect to possibly be able to add additional strategy classes to be loaded in the future, perhaps via an additional assembly, you would need to fully qualify your class name. This is recommended anyway, since you would be able to provide enhanced extendability for your application.
I'm going with the full type name in the application configuration. Below is a slightly more complete, but still trivial example
<SuperAppConfig>
<ObjectConfig provider="BigCorp.SuperApp.ClassA">
<add name="one" />
<add name="two" />
</ObjectConfig>
</SuperAppConfig>
And the factory class that actually creates this
private static Assembly a = typeof(IFactoryObject).Assembly;
public static IFactoryObject CreateObject(String providerName)
{
Type t = a.GetType(providerName)
IFactoryObject o = Activator.CreateInstance(t) as IFactoryObject;
return o;
}
BaseClass c = Activator.CreateInstance(t) as BaseClass; // fails
Might also result from the fact, that CreateInstance does not return an instance of BaseClass, rather than an instance of BaseClass wrapped into an ObjectHandle.
Cast into your BaseClass after you used the UnWrap method.