Visual Studio 2010, 2012 vs. Inconsolata font, part 3

Earlier, I promised to update the status of the fight "Visual Studio 2010 vs. Inconsolata" as soon as I have a chance to try the font in Visual Studio 2012. However, I noticed that the font has been updated also and the latest version of Inconsolata is available from September, 2012.

So first, I tried it in Visual Studio 2010, silently hoping that the troubles are gone. And yes, the extra boldness of some symbols is no more the case. Here is how it looks:

Inconsolata in Visual Studio 2010

After that I switched to Visual Studio 2012. No surprises, the font is rendered perfectly:

Inconsolata in Visual Studio 2012

So I guess, the confrontation is over. If you love Inconsolata font, just get its latest version from google code repository and enjoy!

Windows 7 VPN connectivity trouble

Sometimes Windows 7 rejects my attempts to open a VPN connection, saying that my computer is not connected to the Internet while it is. I don’t know the reason why this happens, may be someone can explain such a weird behavior when one part of the system doesn’t know what happen in another one. Here is how it looks:

I marked the regions that are important on the screenshot. So, while I’m writing and publishing this post VPN networks are still unavailable. Damn Windows. If anyone knows how to sort this out without logging out, plz, let me know.

System.Configuration & Enum case-insensitivity

Yesterday one of DataObjects.Net 4 customers made a request for the following enhancement: he wrote it would be much more usable if one could write case-insensitive Enum options in DataObjects.Net configuration section. So instead of standard case-sensitive:

<domain … upgradeMode="Recreate"/>

he suggested that we should implement support for case-insensitive values also, e.g.:

<domain … upgradeMode="recreate"/>

As IMO the suggestion was really usable and I thought it was easy to implement, I decided to make it ASAP. I knew that there are two ways of parsing Enum values: case-sensitive and case-insensitive – both of them are provided by static Enum.Parse member. I thought that we were using case-sensitive one. So I went to Xtensive.Storage.Configuration namespace and found the corresponding code. It was the following:

[ConfigurationProperty(UpgradeModeElementName, IsRequired = false, 
DefaultValue = DomainUpgradeMode.Default)]
public DomainUpgradeMode UpgradeMode
{
  get { return (DomainUpgradeMode)this[UpgradeModeElementName]; }
  set { this[UpgradeModeElementName] = value; }
}

As you see, DataObjects.Net 4 doesn’t responsible for Enum value parsing as it expects already parsed Enum value, but not initial string from app.config. But who is responsible for Enum value parsing then? Let’s dig into the System.Configuration assembly.

With .NET Reflector I found that System.Configuration.GenericEnumConverter is the place where string is converted into Enum value. But unfortunately it uses case-sensitive method of parsing strings and there is no way to change this behavior. It is hard-coded by one of microsofties. This means that all developers that use System.Configuration are to write only case-sensitive Enum values in their project configuration files.

 

The alternative way is to convert all Enum-based properties into string-based ones and parse them manually during ConfigurationElement –> Configuration conversion routine. So we should change the above-mentioned property into the following one:

[ConfigurationProperty(UpgradeModeElementName, IsRequired = false, 
DefaultValue = "Default")]
public string UpgradeMode
{
  get { return (string)this[UpgradeModeElementName]; }
  set { this[UpgradeModeElementName] = value; }
}

The second step is to add case-insensitive Enum-parsing logic into DomainConfigurationElement.ToNative() method:

domainConfig.UpgradeMode = (DomainUpgradeMode) Enum.Parse(
  typeof (DomainUpgradeMode), UpgradeMode, true);

That’s it!
Certainly, the same modification is made to all Enum-based configuration properties.

P.S.
Thanks to Ivan Galkin for the bright idea.

CodeProject

Shortcut to TypeInfo

There are two ways how to get the corresponding TypeInfo instance for a persistent Type.

First way is straightforward:

TypeInfo typeInfo = Domain.Model.Types[typeof (Animal)];

The second is much shorter, it is powered by .Net Framework 3.5 extension methods feature:

TypeInfo typeInfo  = typeof (Animal).GetTypeInfo();

or

TypeInfo typeInfo = typeof (Animal).GetTypeInfo(Domain);

Referencing objects finding task

IMO, The feature to find objects that reference a concrete Entity instance is essential for any O/RM. So DataObjects.Net 4 also has the feature but is it really usable for developers? I’m afraid, no.

What DataObjects.Net 4 can offer for now:

public static class ReferentialHelper
{
  public static IEnumerable<Entity> FindReferencingEntities(Entity entity);

  public static IEnumerable<Entity> FindReferencingEntities(Entity entity, AssociationInfo association);
}

This assumes that developer must know that somewhere there is a static class ReferentialHelper that is responsible for this functionality. Without such knowledge developer has zero chances to achieve his goals in finding referencing entities. Too bad both for developer and for our product.
Moreover, this pattern doesn’t cover the scenario when developer wants to receive additional information about concrete property that holds a reference to specified Entity instance.

Luckily, we have a chance to make it more usable. With the help of our community, we are inventing the updated referencing objects finder pattern:

1. Structure, that describes a reference, has been introduced:

public struct ReferenceInfo
{
  public Entity ReferencingEntity { get; private set; }
  public Entity ReferencedEntity { get; private set; }
  public AssociationInfo Association { get; private set; }
}

It contains enough information about concrete reference: the AssociationInfo instance that describes connection between 2 objects, and references to objects at both ends of the connection.

2. ReferentialHelper method’s signature has been changed to the following:

public static IEnumerable<ReferenceInfo> FindReferencingObjects(this Entity target)

public static IEnumerable<ReferenceInfo> FindReferencingObjects(this Entity target, AssociationInfo association)

As you see, these extension methods have been targeted the Entity type. The reason for extension methods instead of regular ones is obvious: finding referencing entities is not the responsibility of Entity class. But in order to make them more usable for developers we should somehow bind them to some type that are well-known in DataObjects.Net 4 domain context and are familiar to developer. This type could be Session, Domain or Entity. So after some discussion we choose Entity type because the first place to search for such kind of methods is the Entity type itself.

3. Another extension method that quickly answers to the question “Is Entity instance referenced at all? “ has been added:

public static bool IsReferenced(this Entity target)

 

So, I think that from time to time we should make a review of existing code base in order to find such kind of issues and refactor them into more usable and understandable code.

P.S.
Special thank to Havasvölgyi Ottó – one of the most valuable DataObjects.Net partner and contributor for his bright ideas and constant willingness to participate in numerous DataObjects.Net-related discussions.

CodeProject