Develop Reference

List<dynamic> elements have fields but I cannot access them. Why?

I need to loop over a List<dynamic> objects.
The list's objects all have values, but for some reason, I am not able to access any of the dynamic object fields. Below is a screenshot of my debug window:
There you can see the object contains fields (such Alias, Id, Name, etc).
I tried both casting it to a IDictionary<string, object> and ExpandoObject, to no avail. I did not face such a thing before: failing to access existing fields in a dynamic object when they exist.
What is wrong here?
The code is throwing a Microsoft.CSharp.RuntimeBinder.RuntimeBinderException with a message stating {"'object' does not contain a definition for 'Name'"}.
The list was created adding anonymously-typed objects, like this:
return new List<dynamic>(fields.Select(field => new
{
Id = field.Id,
Alias = field.Alias,
Name = field.Name,
Type = field.Type,
Value = field.Value,
SortOrder = field.SortOrder
}));
where fields is an ICollection<Field>, a strongly-typed collection.

The telling part is the exception:
{"'object' does not contain a definition for 'Name'"}.
This indicates that the runtime binder was not actually capable of accessing the type you're passing in dynamic (since dynamic does actually enforce visibility rules).
The most likely cause of this is that you're creating the anonymous type in a different assembly from the one where you're subsequently reading it - since anonymous types are declared internal, the consuming assembly cannot access it, causing the error message above.
Contrast with the usual case of runtime binder exceptions:
'<>f__AnonymousType0< string >' does not contain a definition for 'Name'
EDIT:
A possible solution to the problem is to use the InternalsVisibleToAttribute on the assembly containing the anonymous type. However, this is code smell - just like any other use of InternalsVisibleToAttribute or internal itself.
A better way would be to make sure you don't actually pass anonymous types over assembly boundaries - after all, they shouldn't even be used outside of the method they originated from; the fact that they are is basically an implementation detail of .NET - they didn't have another way to do the same thing. This could change in future versions, making the InternalsVisibleToAttribute solution doubly unreliable.
The way your code is using dynamic suggests that your team has flawed assumptions about how dynamic works and how it's supposed to be used. Note how the actual runtime type of List<dynamic> is actually List<object>. The same goes for arguments of type dynamic (which are again just object, albeit marked with DynamicAttribute). And in fact, that really is what dynamic is - it's a way to handle runtime dynamic dispatch - it's not a property of the type or anything, it's just the way you actually invoke whatever you're trying to invoke. For C#, dynamic allows you to skip most of the compiler checks when working with those dynamic types, and it generates some code to handle the dispatch for you automatically, but all of that only happens inside the method where you actually use the dynamic keyword - if you used List<object>, the end result would be exactly the same.
In your code, there's no reason not to use simple static types. Dynamic typing doesn't really give you any benefits, apart from the effort to code the types themselves. If your co-workers don't like that, well, they should present a better solution - the problem is quite obvious, and it's something you need to deal with.
Much worse, it explicitly hides all context, all the type information. That's not something you want in an API, internal or not! If you want to hide the concrete types being used, why not - but you should still expose an interface instead. I suspect this is the reason why anonymous types can't implement interfaces - it would encourage you to go entirely the wrong way.

Serialize an object without the object's information

I am in a situation I need to serialize only the values of the members of an object to a file.
for example, if the object contains 3 string members I would want the output of the serialization to be only this 3 strings without the serialization metadata the Binaryformatter adds, like the version, culture, and assembly name of the object.
One option is just to write each members of the object directly, but I want to avoid this because I have lots of classes that need to be serialize like this and I don't want to write a function that handles this differently for each class.
Requirements:
I want to be able to write to any type of file, I want the values of the members to be translated to bytes (into a buffer or directly into the file) and to be able to write those bytes at a specific position in the file.
Is there a way or an API of serializing only the value of the members of an object?

Matan,
Here is some code I put together for an entirely different purpose, but it takes an unknown object and serializes it into an XML file (updated to include better coding practices).
void objectToXMLFile(String fn, object o)
{
XmlTextWriter textWriter = new XmlTextWriter(fn, null);
System.Type type = o.GetType();
PropertyInfo[] piList = type.GetProperties();
textWriter.WriteStartDocument();
textWriter.WriteStartElement("attributeList");
foreach (PropertyInfo pi in piList)
{
textWriter.WriteStartElement("attribute");
textWriter.WriteStartElement("name");
textWriter.WriteString(pi.Name);
textWriter.WriteEndElement();
textWriter.WriteStartElement("value");
textWriter.WriteString(pi.GetValue(o).ToString());
textWriter.WriteEndElement();
textWriter.WriteStartElement("dataType");
textWriter.WriteString(pi.PropertyType.Name);
textWriter.WriteEndElement();
textWriter.WriteEndElement();
}
textWriter.WriteEndElement();
textWriter.WriteEndDocument();
textWriter.Close();
}

If you do end up using Reflection to only write the wanted properties, you may want to consider some performance implications.
Using Reflection is slow. Reflecting the type itself has a high price, and then dynamically invoking the PropertyInfo by calling PropertyInfo.GetValue is very slow.
An alternative is to build an Expression tree that calls the properties and writes their values, and then compile this expression into an Action. You can cache these Action instances in a dictionary keyed by the Type of the object you are serializing, and invoke the right one when you want to serialize the object.
That would be much much faster and will also not create so much load on the GC.
Another alternative you may consider is code generation at build time - you can generate a class to serialize your target type quickly and cheaply. In some scenarios this is a good choice.

Convert object to System.Type in linq

I need to cast an object to a System.Type object.
I've read that C# is statically typed so that would not be possible.
Is this true?
If yes, how can I accomplish this?
Assembly myDll = Assembly.LoadFrom(dllData.Path);
Type manyAttribute = myDll.GetExportedTypes().FirstOrDefault(...);
Type multiplicityAttribute = myDll.GetExportedTypes().FirstOrDefault(..);
//Here is the problem
propertiesOnOtherFile = propertiesOnOtherFile.Where(t =>
t.GetCustomAttributes(false).Any(ca =>
!string.IsNullOrEmpty(((multiplicityAttribute)ca).PropertyName)));
This is the line:
((multiplicityAttribute)ca).PropertyName)
Is there any other way to do this?
EDIT:
Due to many questions, this is my scope:
public class PocoClass
{
[ManyAttribute]
public ObjectX MyProp;
}
ManyAttribute declaration
{
public string PropertyName;
}
ManyAttribute is in the dynamicly loaded DLL.
Then, as in my example above, I need to cast the customAttribute (ManyAttribute) to ManyAttribute so I check PropertyName's value.

I still don't get this... but this should work.
IEnumerable<Type> propertiesOnOtherFile = new List<Type>(); //from somewhere?
//Here is the problem
propertiesOnOtherFile = propertiesOnOtherFile.Where(t =>
t.GetCustomAttributes(false).Any<dynamic>(ca =>
!string.IsNullOrEmpty(ca.PropertyName)));

There are only two ways to access properties/methods of something without knowing its type at compile time. You're certainly in this situation:
reflection – gets fairly cumbersome very quickly, even for basic things, but allows you to do pretty much anything you want.
dynamic – makes C# behave similarly to dynamically typed languages, but does not allow you to do things like accessing a property whose name is also dynamic.
Since in your case the property names are also dynamic, I would say that the answer is no, there is no better way to manipulate objects and properties when they aren't known at compile time.
You would do well to design your architecture in such a way as to avoid accessing objects in quite such a dynamic way, but there is too little context to recommend a specific approach.

What you're attempting to do doesn't make sense.
This line: Type multiplicityAttribute = myDll.GetExportedTypes().FirstOrDefault(..); gets a Type that you're attempting to bind to, dynamically.
Then you're trying to cast against it: (multiplicityAttribute)ca)
What are you going to do once you have it cast?
Are you:
Attempting to get names of properties?
Attempting to get a list of object types that have some property?
Attempting to get the value of some static property?
Attempting to get the value of some instance property, but you don't know the name of the class that is defining the instance?
What it seems like you're trying to do is create a generalizable approach to inspecting for something that in reality is pretty specific. When working with Reflection, it's commonly easier to go the other direction: solve the specific case first, and then refactor to more generalizable approaches.

C#: return stong types from reflection

In the latest version of C#, is it possible to convert a dynamic type to a strong type, if you know the type in advance?
I'm using reflection to call a method on an object, which returns to a var:
var returnVal = context.GetType().InvokeMember(MethodName, BindingFlags.InvokeMethod, null, context, lParams.ToArray());
I can easily get the type being returned to returnVal. Is it possible to cast\convert thins to a more strongly typed version?
EDIT FOR CLARITY:
In this situation, I know the type being returned but only by string. To get the type, I have to do:
diAssemblies[k].GetType(diAssemblies[k].GetName().Name + "." + returnType)
Where returnType is the name of type being returned.
Ideally, I'd like to be able to get the result of the method invocation in to a strongly typed field.
CONTEXT
I'm loading assemblies containing .edmx files from a directory, then invoking methos on those contexts. At run time, the loader won't know what assemblies it's going to be loading. However, the person using the loader will be aware of the assemblies, methods and types.
This is to create a generic wrapper around database calls through entity framework (with stored procedures), that will be reused elsewhere.

If you don't know the Type statically, how could you use a statically typed reference? What you can do is have the returned type implement an interface you do know about statically, then cast to that interface.
So, if MyStrongType implements IMyStrongBehavior, you can cast the return value to IMyStrongBehavior and use that statically. The underlying value is already strongly typed, regardless of whether you cast it.
Alternately, you can store the return value in a dynamic variable (which will allow you to invoke known methods without an actual statically-typed interface.) The disadvantage here is that you don't get any Intellisense and any mistakes you make won't show up until runtime.

No, you can't get the advantages of a concrete type such as compile time checking and intellisense. This is because you are only actually working out what the type is at run time. It is late bound, which means that it's a job for dynamic and the DLR. You can cast it to an object that you know the actual object will inherit from (e.g. object), but you can't cast to the actual type. You might want to look into generics as an alternative if you had for example:
public T GetReturnVal<T>()
{
return (T)context.GetType().InvokeMember(MethodName, BindingFlags.InvokeMethod, null, context, lParams.ToArray());
}
You would at least be returning a concrete type to callers of type T. But this type has to be set at compile time, i.e. known in advance.
I recomend you read An Introduction to C# Generics as it does exactly what, from the context you've added, you need to do.

Getting the type of a "Type" in C# reflection

This is harder to find in the docs than I imagined. Anyway, I have some instances of Type. How can I find out if they represent classes, methods, interfaces, etc?
class Bla { ... }
typeof(Bla).GetKindOrWhatever() // need to get something like "Class"
(I'm using Mono on Linux but that shouldn't affect the question, I'm making portable code)

Type.IsClass might help here. Also Type.IsInterface.
Check out...
http://msdn.microsoft.com/en-us/library/system.type_members.aspx
There are quite a few "IsXxxx" properties on Type. Hopefully these will do what you want.
By the way, you should check out other questions on this subject on SO, including this one...
typeof(System.Enum).IsClass == false
... if the types you're going to be checking are enum types, as there are some strange (but predictable) results.

There are a slew of properties off the Type class.
typeof(Bla).IsClass
typeof(Bla).IsInterface
etc.
http://msdn.microsoft.com/en-us/library/system.type_properties.aspx

The Type class have some properties that are named IsXXX.
For example it has a IsEnum, IsClass, IsInterface.
If I understand correctly your question this is what you need

As others have mentioned, the Type class has various properties that you can use if you just need to know whether your type is a class, interface, delegate, etc.
If you have a Type object and you want to know if it is a specific type, then I recommend using the IsAssignableFrom method found on the Type class:
Type objectType = obj.GetType();
Type interfaceType = typeof(IExample);
if (interfaceType.IsAssignableFrom(objectType))
{
//...
}

Type.IsClass Property?