Tobi + C# = T#

Introduction

When using specific third party assemblies it is necessary to distinguish between platforms. Best example are e.g. log4net, sqlite, … which come in both x86 and x64 but not in the general Any Cpu flavor. A typical development scenario could be that an ASP.NET application is developed using the IIS Express and deployed on a 64bit IIS in production.
A different development scenario could be that a Silverlight application uses Design Time data in order to create a richer design time experience for the developer. In this situation a best practice is to put the classes containing the design time data into a separate assembly that is only referenced during development and is not deployed in production. Here one needs to distinguish between solution configuration Debug and Release.
In order to support these scenarios the project files allow for conditional references.
Unfortunately Visual Studio does not expose the conditional references feature in its UI. Therefore one has to edit the corresponding .csproj file by hand. This can be simply done using Visual Studio using the following steps:

1. Right click the project one wants to edit
2. Select "Unload Project" from the popup menu
3. Right click the unloaded project
4. Select "Edit "

Basic project file layout (Visual Studio 2010)

A project file (.csproj) is an XML file containing an XML header and a root element Project. The Project can contain multiple elements of different types, most notably the PropertyGroup, ItemGroup, Import and Target elements. In this post I will not describe the specific use of each of the elements, but will concentrate on conditional assemblies. Documentation for these elements can be found on msdn.
Assembly or project references are found in an ItemGroup using either Reference or ProjectReference elements.
A typical .csproj producing either an x86 or x64 executable looks like this:

Conditionals

In the above project one can already spot the mechanism used to distinguish between e.g. configurations and platforms.

An XML node annotated with the Condition attribute is only included when parsing the file if the condition holds true. This mechanism can be applied to any element in the project file's XML structure.

Using conditions for assembly references

If one uses an assembly that is specifically designed for x86 or x64 one can use the conditional attribute to include the correct dll for the specified build platform. One of the best known dll of that type is SQLite:

Without the conditional a dll reference looks like this:

To distinguish between the two states of 32bit and 64bit one simply doubles theReference element and applies mutually exclusive Condition attributes to both:

Note that the HintPath differs depending on the platform.

Using conditions for project references

If you have a project that should not get deployed as part of the final released product, why not use the Condition attribute to only include the project during debugging. One good example for these kinds of projects is Design-time data. Simply distinguish on the Configuration setting.

Hint

Keep in mind that the Visual Studio UI does not reflect conditional references within the "References" folder of a project. Therefore all references are visible in any given configuration or platform selection. The compiler and Intellisense on the other hand are aware of conditional references, honoring the correct settings both with visual feedback and error notification during builds.

Summary

Today we looked at the possibility to customize which assemblies or projects are referenced in each individual configuration or platform selection. The customization cannot be done using the UI, but is accomplished by manually editing the project file.

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.