We Keep Coding

Create hash of a class signature for caching

Edit: all answers below (as at 19th Dec '16) are useful in making a decision. I accepted the most thorough answer to my question; but in the end chose to simply hash the file.
I am caching objects and using the assembly version as part of the key to invalidate the cached objects every time the build changes. This is inefficient because the actual class of the cached objects rarely change and are valid across builds.
How can I instead use a hash of the specific class signature (basically all properties) for the key, such that it only changes when the class itself changes?
I can think of a somewhat complicated way using reflection, but I wonder if there is a simple trick I'm missing or any compile time mechanism.
Thanks!
E.g. Signature of Foo --> #ABCD
public class Foo {
public string Bar {get; set;}
}
New signature of Foo (property type changed) --> #WXYZ
public class Foo {
public char[] Bar {get; set;}
}

As others have pointed out it is dangerous to do something like that because a signature doesn't define the logic behind it. That being sad:
This is an extensible approach:
The method basically uses reflection to crawl through all properties of your type.
It then gets some specific values of those properties and calls ToString() on them.
Those values are appended to a string and GetHashCode() will be used on that string.
private int GetTypeHash<T>()
{
var propertiesToCheck = typeof(T).GetProperties();
if(propertiesToCheck == null || propertiesToCheck.Length == 0)
return 0;
StringBuilder sb = new StringBuilder();
foreach(var propertyToCheck in propertiesToCheck)
{
//Some simple things that could change:
sb.Append((int)propertyToCheck.Attributes);
sb.Append(propertyToCheck.CanRead);
sb.Append(propertyToCheck.CanWrite);
sb.Append(propertyToCheck.IsSpecialName);
sb.Append(propertyToCheck.Name);
sb.Append(propertyToCheck.PropertyType.AssemblyQualifiedName);
//It might be an index property
var indexParams = propertyToCheck.GetIndexParameters();
if(indexParams != null && indexParams.Length != 0)
{
sb.Append(indexParams.Length);
}
//It might have custom attributes
var customAttributes = propertyToCheck.CustomAttributes;
if(customAttributes != null)
{
foreach(var cusAttr in customAttributes)
{
sb.Append(cusAttr.GetType().AssemblyQualifiedName);
}
}
}
return sb.ToString().GetHashCode();
}

You can hash the whole class file and use that as a key. When the file changes, the hash will change and that will meet your need

You can use the public properties of the class and generate an hash based on the name and type of each property:
int ComputeTypeHash<T>()
{
return typeof(T).GetProperties()
.SelectMany(p => new[] { p.Name.GetHashCode(), p.PropertyType.GetHashCode() })
.Aggregate(17, (h, x) => unchecked(h * 23 + x));
}
ComputeTypeHash<Foo_v1>().Dump(); // 1946663838
ComputeTypeHash<Foo_v2>().Dump(); // 1946663838
ComputeTypeHash<Foo_v3>().Dump(); // 1985957629
public class Foo_v1
{
public string Bar { get; set; }
}
public class Foo_v2
{
public string Bar { get; set; }
}
public class Foo_v3
{
public char[] Bar { get; set; }
}

Doing something like this is dangerous as you (or someone else) could be introducing logic into the properties themselves at some point. It's also possible that the properties make internal calls to other methods that do change (among other things). You won't be detecting changes that go beyond the signature so you are leaving the door open to disaster.
If these group of classes you refer to rarely change, consider moving them out of the main assembly and into their own one or even break it down into more than one assembly if it makes sense. That way their assembly(ies) will not change versions and there will be no cache refresh.

Setting the propery, when not knowing which one

Say I have this class with a few members, for example (this is a contrived example, I'd rather no have a discussion about the intricacies of the real-life design. I really just want to convey the general idea here.):
public class Address
{
public Guid Id { get; set; }
public Guid? HouseId { get; set; }
public Guid? FlatId { get; set; }
public Guid? SomeOtherBuildingTypeId { get; set;
}
Now as it happens there exist 3 methods to create an Address:
public void CreateAddressForHouse();
public void CreateAddressForFlat();
public void CreateAddressForSomeOtherBuildingType();
Under the surface this group of methods does the exact same thing, bar setting a different Id property in the Address class. This is causing quite some code duplication in the real life application and I want to rewrite this to something more general.
In my mind I can pass the name of the required property and its value to a CreateAddress function, in something like a Func. But I'm seriously lacking in this respect, where to start? What .NET stuff can I use out of the box? Or what specific keywords should I look for?

You can use a MemberExpression:
public void CreateAddress(Expression<Func<Address, Guid?>> member)
{
// Get the property from the expression
var propertyInfo = GetPropertyInfo(this, member);
// Create a new address
var guid = Guid.NewGuid();
// Assign it to the property of this instance
propertyInfo.SetValue(this, guid);
}
Then you call the method like this, using a lambda a => a.PropertyName:
var address = new Address();
address.CreateAddress(a => a.HouseId);
Console.WriteLine(address.HouseId);
See Retrieving Property name from lambda expression for the implementation of GetPropertyInfo. It gets the PropertyInfo of the member specified in the lambda expression (and checks that it is indeed a property), which you can use to set the property in the CreateAddress method.
Apart from that, #Corak's suggestion is a valid one. Maybe you shouldn't use a property per address type, but use a Dictionary<AddressType, Guid?> property. That may or may not be viable depending on the class design and its intended usage.

You can use expression trees to simplify your problem:
public class AddressService
{
public Address CreateAddress(Expression<Func<Address, Guid?>> idPropertySelector)
{
// So you get the property info to later set it using reflection
MemberExpression propertyExpr = (MemberExpression)idPropertySelector.Body;
PropertyInfo property = (PropertyInfo)propertyExpr.Member;
// Then you create an instance of address...
Address address = new Address();
// and you set the property using reflection:
property.SetValue(address, (Guid?)Guid.NewGuid());
return address;
}
}
Now, who knows where in your code, this will work:
AddressService service = new AddressService();
Address address = service.CreateAddress(a => a.FlatId);
Guid? flatId = address.FlatId; // This will be already assigned!

You can add a property BuildingType BuildingType being a value of the enum BuildingType { House, Flat, SomeOtherBuildingType, YetAnotherThing } as suggested by Corak.
To make it simpler, you can create a parameterized constructor in Address class:
public Address(Guid? id,BuildingType type)
{
switch(type)
{
case BuildingType.House:
HouseId=id;
break;
case BuildingType.Flat:
FlatId=id;
break;
case BuildingType.SomeOtherBuildingType:
SomeOtherBuildingTypeId =id;
break;
default:
break;
}
}
This way it will be easier to extend.
Also, you need not to have so many methods. Only one CreateAddress() can be used to generate address of multiple types.

Encapsulation C# newbie

New to C#, and I understand that encapsulation is just a way of "protecting data". But I am still unclear. I thought that the point of get and set accessors were to add tests within those methods to check to see if parameters meet certain criteria, before allowing an external function to get and set anything, like this:
private string myName;
public string MyName;// this is a property, speical to c#, which sets the backing field.
private string myName = "mary";// the backing field.
public string MyName // this is a property, which sets/gets the backing field.
{
get
{
return myName;
}
set
{
if (value != "Silly Woman"){
myName = value;
}
}
}
But I've been seeing code in c# which just looks like this:
public string MyName { get; set; }
Why would you just have a get and set with nothing in there, - isn't that the same as just declaring your private backing field public? If you can just get and set it from outside, why wouldn't you just do it directly?

Indeed, creating an auto-property as follows:
public string Name { get; set; }
is identical to building a property backed by a field:
private string _name;
public string Name {
get { return _name; }
set { _name = value; }
}
The point of these properties is not to hide data. As you observed, they don't do this. Instead, these properties can do other stuff instead of just working with a field:
public string Name {
get { return _name; }
set { if (value == null) throw new Exception("GTFO!"); _name = value; }
}
Another thing is, you can make properties virtual:
public virtual string Name { get; set; }
which, if overridden, can provide different results and behaviours in a derived class.

By using public string MyName { get; set; }, you leave an ability to change its logic later without the need to recompile/change other code that uses your property.
For example, if you are making a library and v1 uses a field and v2 uses a property, applications that work with v1 will not work with v2 without recompilation (and, potentially, code changes if they are written in some .NET language that has different syntax for accessing fields).
Another important difference is in serialization scenarios -- a lot of them do not support fields. Also any interface that requires a property can not be implemented without using one, but depending on interface it may not be required to do any additional checks/logic in it.

It makes it easier to add logic later. If you have a class that has a public field that you want to change to a property, you have to recompile everything that uses your class. That's a key point that I didn't understand initially.
If you have a class:
public class MyClass
{
public string MyString;
}
You could access the value like this:
var myClass = new MyClass();
string s = myClass.MyString;
Now change that to a property:
public class MyClass
{
public string MyString { get; set; }
}
How is it accessed? The exact same way:
var myClass = new MyClass();
string s = myClass.MyString;
So no big deal, right? Well, actually....
Properties are actually compiled into getter and setter methods:
get_MyString() and set_MyString(string value)
So the two methods do produce different compiled code. Now if all your code that uses this class is in the same project, is not as big a deal, because it will all be compiled together. But if you have an API library that you've distributed, it can be a much bigger deal to update.

Because it is easier to change the Code if you want to add the checks/tests later on.
Especially if you have many inheritance and many classes in your code it is very hard to change the implementation from a public variable to a public Property.
Moreover you can add to the get and set within the property different attributes, e.g. if you are using reflection. The get and set of the property are internally different methods. If you have just a public variable /field it is not possible to added different properties to the different access ways.

Yeah, but you can easily change it to:
public string MyName { get; private set; }
Plus, properties are used in other scenarios, like DataContracts and Serialization... so, this is a nice feature... (Mostly, syntactic sugar. I think) EDIT: I take that back.. you can apply virtual to it, so it's not the same

Using strings to select Object Properties

I'm having a bit of trouble with a C# program I'm writing and it'd be great if someone could help.
The background is this, not terribly important, but it's why I need to figure out how to do it:
I'm using a database's Web Services to retrieve information about an entry in the database. Each access to the database returns an Object with many many properties. Using the ID of the database entry, you tell it what information you want filled in about the object it returns by filling an array of which properties to be retrieved. Any property not in the array is left as it's default value (usually null)
The Problem:
I want the user to be able to select a property of an Object (not get the value, just select which property) as below:
projectFields[0] = Primavera.Ws.P6.Project.ProjectFieldType.(project_properties.Text);
Where project_properties.Text is a string of the name of the Property I want to set projectFields[0] to.
Can anyone help? Thanks in Advance :)
Edit: Thanks for the answer guys. While they do let me get the value out of Objects Dynamically, that isn't quite what I was looking for... I'm not looking to retrieve a value, I'm only looking to set which Property projectFields[0] is equal too. for example, suppose the user selects Id as the information they want returned about the project. To do that, I'd set:
projectFields[0]=Primavera.Ws.P6.Project.ProjectFieldType.Id;
then I'd make a call to the Database, and I'd get the project Object back, with Id having been filled out for the project while all other properties would be left to their defaults. Basically, if I were to do it the way these examples suggest, I'd have to retrieve every property in the Object first, then access the member the user is interested in which would be slow/inefficent if I can make the way I'm trying to do it work.
I know it's strange how the database is accessed, but I'm using web Services so I don't have the option to change anything about the calls to the database.

You can probably achieve what you want through Reflection (example), but I get a distinct feeling that there may be an issue with the design of your system.

C# is a statically typed language. The compiler wants to know you property you mean at compile time.
However, you can do this with reflection if you want to. Alternatively, if you know the type of the data in advance, you could use a switch statement. (Example of both approaches coming.)
using System;
using System.Reflection;
public class Demo
{
public string Foo { get; set; }
public string Bar { get; set; }
public string Baz { get; set; }
}
public class Test
{
static void Main()
{
Demo demo = new Demo {
Foo = "foo value",
Bar = "bar value",
Baz = "surprise!"
};
ShowProperty(demo, "Foo");
ShowProperty(demo, "Bar");
ShowProperty(demo, "Baz");
ShowDemoProperty(demo, "Foo");
ShowDemoProperty(demo, "Bar");
ShowDemoProperty(demo, "Baz");
}
// Here we don't know the type involved, so we have to use reflection
static void ShowProperty(object x, string propName)
{
PropertyInfo property = x.GetType().GetProperty(propName);
if (property == null)
{
Console.WriteLine("No such property: {0}", propName);
}
else
{
Console.WriteLine("{0}: {1}", propName,
property.GetValue(x, null));
}
}
// Here we *know* it's a Demo
static void ShowDemoProperty(Demo demo, string propName)
{
string value;
// Note that this is very refactoring-unfriendly. Generally icky!
switch (propName)
{
case "Foo": value = demo.Foo; break;
case "Bar": value = demo.Bar; break;
case "Baz": value = demo.Baz; break;
default:
Console.WriteLine("No such property: {0}", propName);
return;
}
Console.WriteLine("{0}: {1}", propName, value);
}
}
I agree with the other answers which suggest this probably shows a slightly scary design...

You can use reflection - See property info class.

C# Extension methods on "members"

I have some extension methods which could be used like this:
MyType myObject;
string displayName = myObject.GetDisplayName(x => x.Property);
The problem here is that it needs an instance, even if the extension method only needs the type MyType. So if there is no instance, it needs to be called like this:
string displayName = BlahBlahUtility.GetDisplayName((MyTpe x) => x.Property);
Which is not so nice anymore.
Is there a way to write better syntax for such cases?
What I actually want to do is this (pseudo language):
string displayName = MyType.Property.GetDisplayName()
Which of course does not work with C#.
But what about something like this:
string displayName = ((MyType x) => x.Property).GetDisplayName();
This is also not possible (after a lambda, a dot is not accepted).
Any ideas?
Edit:
My "favorite syntax" MyType.Property.GetDisplayName() seems to be misleading. I don't talk about static properties here. I know that this syntax won't be possible. I just tried to show in pseudo language, what information is necessary. This would be ideal, every additional stuff is just syntactical overhead. Any working syntax that is close to this would be great.
I don't want to write a certain extension method. I want an easy, readable and compile time safe syntax, using any language feature.

Have a look at the Express and Reflect classes in the Lokad Shared Libraries. Think they may help out with what you are trying to do. Read more here:
Strongly Typed Reflection in Lokad Shared
How to Find Out Variable or Parameter Name in C#?

From your comment: "I want an easy and compile time safe syntax to get information about members".
This is a very frequently requested feature and has been discussed in the C# team's meetings for about a decade, but has never been prioritised high enough to be included.
This blog post explains why:
http://blogs.msdn.com/ericlippert/archive/2009/05/21/in-foof-we-trust-a-dialogue.aspx
So for now, you're just going to be fighting against a missing feature. Maybe you could post more information about your broader problem and see if people can suggest different approaches.
Update
Without more info about your problem this is just guesswork. But if you have a property that represents a value but also carries additional "meta" information, you could always represent that as a new type and use an "injection" step to set everything up.
Here's a suggested abstract interface to such a "meta property":
public interface IMetaProperty<TValue>
{
TValue Value { get; set; }
string DisplayName { get; }
event Action<TValue, TValue> ValueChanged;
}
The value of the property is just another sub-property, with its type defined by the user.
I've put in the display name, and also as a bonus you've got an event that fires when the value changes (so you get "observability" for free).
To have properties like this in a class, you'd declare it like this:
public class SomeClass
{
public IMetaProperty<string> FirstName { get; private set; }
public IMetaProperty<string> LastName { get; private set; }
public IMetaProperty<int> Age { get; private set; }
public SomeClass() { MetaProperty.Inject(this); }
}
Note how the setters on the properties are private. This stops anyone from accidentally setting the property itself instead of setting the Value sub-property.
So this means the class has to set up those properties so they aren't just null. It does this by calling a magic Inject method, which can work on any class:
public static class MetaProperty
{
// Make it convenient for us to fill in the meta information
private interface IMetaPropertyInit
{
string DisplayName { get; set; }
}
// Implementation of a meta-property
private class MetaPropertyImpl<TValue> : IMetaProperty<TValue>,
IMetaPropertyInit
{
private TValue _value;
public TValue Value
{
get { return _value; }
set
{
var old = _value;
_value = value;
ValueChanged(old, _value);
}
}
public string DisplayName { get; set; }
public event Action<TValue, TValue> ValueChanged = delegate { };
}
public static void Inject(object target)
{
// for each meta property...
foreach (var property in target.GetType().GetProperties()
.Where(p => p.PropertyType.IsGenericType &&
p.PropertyType.GetGenericTypeDefinition()
== typeof(IMetaProperty<>)))
{
// construct an implementation with the correct type
var impl = (IMetaPropertyInit)
typeof (MetaPropertyImpl<>).MakeGenericType(
property.PropertyType.GetGenericArguments()
).GetConstructor(Type.EmptyTypes).Invoke(null);
// initialize any meta info (could examine attributes...)
impl.DisplayName = property.Name;
// set the value
property.SetValue(target, impl, null);
}
}
}
It just uses reflection to find all the IMetaProperty slots hiding in the object, and fills them in with an implementation.
So now a user of SomeClass could say:
var sc = new SomeClass
{
FirstName = { Value = "Homer" },
LastName = { Value = "Simpson" },
Age = { Value = 38 },
};
Console.WriteLine(sc.FirstName.DisplayName + " = " + sc.FirstName.Value);
sc.Age.ValueChanged += (from, to) =>
Console.WriteLine("Age changed from " + from + " to " + to);
sc.Age.Value = 39;
// sc.Age = null; compiler would stop this
If you're already using an IOC container you may be able to achieve some of this without going directly to reflection.

It looks like you're trying to create a static extension method?
DateTime yesterday = DateTime.Yesterday(); // Static extension.
Instead of
DateTime yesterday = DateTime.Now.Yesterday(); // Extension on DateTime instance.
If this is what you're trying to pull off, I do not believe it is possible in the current version of C#.

It sounds like you are integrating layers a little too tightly. Normally in this type of situation I would let the presentation layer decide the implementation of GetDisplayName() instead of making it an extension of the property itself. You could create an interface called MyTypeDisplayer or whatever you fancy, and let there be multiple implementations of it not limiting you to a single display implementation.

The issue here is that one cannot get a reference to non-static methods via instance MyType.[Member]. These can only be seen through a reference to an instance of the type. You also cannot build an extension method on-top of a type declaration, only on an instance of a type - that is the extension method itself has to be defined using an instance of a type (this T x).
One can however define the expression like this to get a reference to static members:
((MyType x) => MyType.Property)
One could do something similar to string displayName = ((MyType x) => x.Property).GetDisplayName();
The first issue is guaranteeing that the compiler treats your (x=> x.Property) as an Expression rather than an action/func etc...
To do this one might need to do this:
string displayName = ((Expression<Func<PropertyType>>)((MyType x) => x.Property).GetDisplayName();
The extension method would then have to be defined like this:
public static string GetDisplayName<T>(this Expression<Func<T>> expression)
You might also have to define an extension method on top of Expression<Action>> and Expression<Action<T>> if your members are also methods.
You can do a dot after an Expression - this is where the Compile method would reside.
Appended:
I think the static call to the extension method in cases that one doesn't have an instance of the type one needs to do "reflection" on to determine a Members name would be the cleanest syntax still - this way you could still use the extension method when using an instance of a type and fall back to the static call definition => MyExtensionClass.GetDisplayName(TypeOfX x => TypeOfX.StaticMember OR x.Property/Member) when one doesn't have an instance

If you interface your properties, you could make the extension on the interface instead:
namespace Linq1
{
class Program
{
static void Main(string[] args)
{
MyType o = new MyType();
o.Property.GetDisplayName();
}
}
public class MyType
{
public IDisplayableProperty Property { get; set; }
}
public interface IDisplayableProperty
{
string GetText();
}
public class MyProperty1 : IDisplayableProperty
{
public string GetText() { return "MyProperty2"; }
}
public class MyProperty2 : IDisplayableProperty
{
public string GetText() { return "MyProperty2"; }
}
public static class Extensions
{
public static string GetDisplayName(this IDisplayableProperty o)
{
return o.GetText();
}
}
}