Tobi + C# = T#

Download the source: blogducktypingreloaded.zip

It's time to do an update on my blog post from the end of 2008, when I did take a first look at the dynamic capabilities in .NET 4.0. From the beta to the final version of 4.0 they did unfortunatelly change the API used for dynamic dispatching and dynamic objects. Instead of MetaObject and IDynamicObject all we need in the updated version of the API is System.Dynamics.DynamicObject. It takes the place of IDynamicObject and MetaObject is gone for good.

This makes it really pleasently easy to implement the same behaviour as I did years ago:

This is a dynamic Duck that can store any value when given via Property and will return the same value as a string when asked for it via the dynamic keyword.

When you download the sample you can see that the code also includes the ability to do a cast from the dynamic Duck to any given interface, in this case an IQuack. So now the totally dynamic property bag is usable via a strongly typed interface!

Download the source: blogducktypingreloaded.zip

The old version of Html.ImageActionLink had a serious flaw - I had to resolve to replacing parts of the generated link after the fact in order to get non html encoded information in there. That obviously creates, though not really probable in this specific case, the problem of unwanted replacement is possible.

So I learnt about UrlHelper and generate the whole MvcHtmlString in one go, without falling back on replacing stuff.

The interface of the method is exactly the same so I can still use this version to create an image that is an actionlink in razor like this:

[UPDATE: There is an improved version of Html.ActionLink: Creating an improved ASP.NET MVC 3 Html.ImageActionLink]

Have I told you that I really enjoy ASP.NET MVC 3 Razor? Damn, that's nice to work with. I am doing a small, fun project for a friend of mine and I stumbled across the situation that I wanted to have an image as an ActionLink. And since the @Html.ActionLink syntax is really sexy, I wanted to write an Extension method that does the same with an image.

The solution is this quick hack:

[UPDATE: There is an improved version without the hacky replace: Creating an improved ASP.NET MVC 3 Html.ImageActionLink]

We return a MvcHtmlString, so we can indicate that this sting is not supposed to be html encoded after we return it to the templating engine. Plus we use the handy AnonymousObjectToHtmlAttributes helper method in order to enable us to pass html attributes to the img tag using anonymous classes, just as we are used to by now.

Unfortunatelly we can not tell the helper.ActionLink call to not html encode what we pass as linkText - therefore we fall back on using a place holder that we replace after the fact.

So now we can do a

right inside Razor. Beautiful!

[UPDATE: There is an improved helper to create an image that has an actionlink url a href: Creating an improved ASP.NET MVC 3 Html.ImageActionLink]

Did you get the dreaded 0x80005000 COMException "Unknown error"? Maybe you should check, if your AD entry contains a forward slash '/' in its DN. Because there is a subtile difference between a correctly escaped distinguished name and a correctly escaped ldap path.

Observe:

Notice how forward slashes need to be escaped in addition to how distinguished names get escaped. This is a very subtile thing that is often overlooked. So when converting between DNs and Paths you have to use the following methods:

The password of a person entry is not a regular property with direct access for reading and writing. Instead it can't be read just indirectly written to via the setPassword method.

The caller must have the User-Force-Change-Password Extended Right to set the password with this method.

Bit properties like User-Account-Control Attribute in the Active Directory are represented by regular integers. Therefore all the usual bit operation may be performed on those fields.

With these helper functions deactivating a user would be accomplished by using

Just for convenience, here is the table form User-Account-Control Attribute converted to C# syntax:

The account never expires checkbox in the MMC is a virtual option. Instead of being a separate property it is set using the accountExpires property. Setting it to the equivalent of 0 will result in an account that never expires.

See Account-Expires Attribute for more details.

Setting a large integer property is just as easy.

Certain properties, like usnChanged or accountExpires, are in an IADsLargeInteger format. One way to read out the long representation of the value of such a property is by reflection.

That value may be converted to a DateTime value using the static DateTime.FromFileTimeUtc method.

Tip #2 already dealt with one of the problems while using multi-value properties.But there is another pitfall that got me once - and usually only happens in production environments and is very hard to debug. I am talking about property range fetch a mechanism introduced to allow the active directory server to use certain optimizations. Unfortunatelly the optimization means a harder to understand API and more work for us programmer.

When dealing with multi-value properties with a huge number of values the active directory server will only return a certain amount of values on the first access (usually 1500 items). On some properties these values don't have an order so that there is a certain randomness to which values are returned - and therefore a certain randomness if your code works as expected or not. Which makes spotting the problem so hard.

So instead of relying on the fact that directoryEntry.Properties["member"] will return all values one must use the range fetch method using DirectorySearcher in order to get all values for said property. In the code sample below I used a cutoff value to determine if simple access should be trusted or if range fetch (slower) must be used.