Tobi + C# = T#

During the development of my little Set Power Scheme daemon, I did a dive into the Power Options API of Windows. Basically I needed a way to programmatically set the active power scheme. The power management functions are located in the PowrProf.dll. Unfortunately there is no managed wrapper to said functionality, but it is a pretty easy API to program against. Specifically we will look at PowerEnumerate, PowerReadFriendlyName, PowerGetActiveScheme and PowerSetActiveScheme.

The first thing one notices is that all power schemes have a unique Guid assigned, which is used to identify the available schemes. So, let’s just get all available Guids. For that we will use PowerEnumerate.

Calling the function once will yield back the Guid of the power scheme at the specified schemeIndex. So, in order to get all we simply call the function in a while loop until no more schemes are found (= the return value of the function is not 0).

Of course only reading the Guid is not very nice, so we will translate the Guid into a friendly name using the PowerReadFriendlyName call.

This API is not the easiest to use for us that are not using COM Interop on a daily basis. In order to call this API, we have to allocate memory for the friendly name to be written to and when we are done free said memory.

Notice that the free call is executed in a finally block, therefore guaranteeing that it is even called in any exception case.

Finally we can now use the Guid to either get or set the active power scheme.

All this functionally is wrapped in a nice repository pattern in Set Power Scheme:

PowerSchemeRepository.cs

Happy coding.

I just wrote a little helper program that lets you track your currently set power scheme. And reset it, if any external sources (like Windows group policies) change said power options. I wrote this, because I have sometimes long running tasks that collide head-on with our IT departments wise decision to force a power scheme that puts my laptop to sleep after an hour. A laptop. What's the power consumption of that thing? And most of the time it's not even plugged in on site, spending company money.

Writing the tool was pretty easy, done in about 45 minutes of coding to get a basic sweet little exe that does nothing but parse a command-line argument, and force-set a power scheme. Which was more than fine by me, since I used the task scheduler to run this program every 5 minutes, knew how to correctly pass a guid to the program, was not surprised that it did not give any feedback, ...

I started showing the tool to a couple of friends, who - not surprisingly - had the same problems. How come all IT departments of all major companies have the same stupid ideas? This is when the suggestions and the feedback started rolling in. So, at first I wrote "documentation" on how to use it. Then I added more elaborate command line parsing, because it seems people do not read manuals. Strange.
Then I set up a git repository on github, so I could start saying "is there a pull request for what you are suggesting" and be all hip and stuff. This did not work out so great, because I ended up adding a daemon mode. Some poor individuals apparently do not even have admin rights on their laptop - and could not set up a task in task scheduler.
And finally I added the possibility to copy and paste the power scheme guids from within the program because some people can't be bothered to use powercfg.exe.

And I feel like it is still not done. What are the todos? Write a blog post about the tool and set up a dedicated website for it.

So, going public meant going from a 45 min solution that worked brilliantly, to working more than 10 hours for it. And suddently feel like I am not done.

Is it always that hard to give back to the community? What is your experience?

Unfortunately IIS is really not at all nice during app pool shutdown to threads running in its context. They simply are killed hard when a shutdown is initiated e.g. during an app pool recycle.

Of course this is by no means a desired behavior and can lead to serious data corruption. Phill Haack already did an excellent blog post on this subject, so please go read The Dangers of Implementing Recurring Background Tasks In ASP.NET now. I’ll wait here.

Today I want to talk about an addition to RegisterObject. The IIS does check if an app pool is busy or idle and may initiate a shutdown simply because it wants to save resources by shutting down long idle app pools. So simply put, even though one correctly uses RegisterObject, the app pool still does not know that there is stuff going on, which is relevant and should mark the app pool as busy.

Like RegisterObject this is done using the System.Web.Hosting.HostingEnvironment class, specifically IncrementBusyCount() and DecrementBusyCount(). With a busy count larger than zero the app pool is marked as busy.

When running task I would recommend that any given tasks does two things before starting its work: Register an object as managed by the hosting environment using RegisterObject and increment the busy counter.

It goes without saying that it must be guaranteed that a task, even a failed one, does a proper cleanup, unregistering and decrementing the busy count.

Final side-note: Please do realize that the IIS will still initiate app pool shutdowns even on busy app pools. So there is still the need to use RegisterObject.

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: