Victor Stodell

Binding an enumeration to a ComboBox can be done in several ways. In most cases you don't want to display the value itself, but a more user friendly description. One common approach is to use the DescriptionAttribute on the Enum values to supply a description for each value.  This is all possible in a very MVVM friendly way. First step is to add the  DescriptionAttribute  to the values of the enumeration. public enum MyValues { [Description("First value")] First, [Description("Second value")] Second } To retrieve the description from the enum we use a simple extension method. This method returns the value of the DescriptionAttribute if it exists, otherwise the string representation of the enum value is returned. public static string GetDescription(this Enum value) { var fieldInfo = value.GetType().GetField(value.ToString()); var attribute = fieldInfo.GetCustomAttributes(typeof(DescriptionAttribute), false).FirstOrDefault() as ...

I have been implementing a scheduler service for several different jobs on several difference schedules, which led me into using Quartz.NET . This is a really nice framework, but since we're using MEF I ran into some issues. Quartz.NET  basically consists of the scheduler engine which runs jobs implementing the IJob interface. The interface simply consists of an Execute method. I export each job with the IJob interface using  MEF . [Export(typeof(IJob))] public class MyJob : IJob { public void Execute(JobExecutionContext context) { ... } } In my scheduler implementation the jobs are imported into an IEnumerable<IJob>. [ImportMany(typeof(IJob))] public IEnumerable<IJob> Jobs { get; set; } The initialization of the scheduled tasks is pretty straight forward. A standard scheduler factory is initialized which in turn gives us a scheduler instance. Each job that was imported by  MEF  is then added to the scheduler, here ...

Sometimes there is a need to display a HTML formatted string in a WPF application. There are a couple of ways to do this, but the most stright forward is to use a WebBrowser control and the NavigateToString method. This approach has one big flaw, you cannot use binding to a string out of the box, but I found a great solution through Stack Overflow which adds a bindable property to the  WebBrowser  control using  NavigateToString . The following class is all that is needed to add that behavior. A new depencency property named Html is introduced to the  WebBrowser  and the proper change action is performed in the OnHtmlChanged method. public class BrowserBehavior { public static readonly DependencyProperty HtmlProperty = DependencyProperty.RegisterAttached( "Html", typeof(string), typeof(BrowserBehavior), new FrameworkPropertyMetadata(OnHtmlChanged)); [AttachedPropertyBrowsableForType(typeof(WebBrowser))] public static string GetHtml(...

Yesterday I did my last working day at my previous employer and the next week I will begin my employment as a Microsoft consultant at  Connecta  in Stockholm. Of course this means that things will change, but only for the better I hope. Leaving a position that you like on a workplace that you like is a tough decision. But in my case there are some amazing possibilities and challenges that I just cannot turn down. The type of work I will be doing differs a bit from my previous position. I will be more focused on development, which also means that I will try to change the direction of this blog to be more development oriented. At the same time, I have come to realize that by blogging in Swedish I do not really contribute to the community as much as I could. Therefore I have chosen to translate my previous posts to English and continue to blog in English from now on. Furthermore I have decided to focus more on my blog. I have some interesting projects ahead, both perso...

Our transition to the  System.DirectoryServices.Protocols  has in the whole gone very smooth, but there have been some issues with one environment that contains subdomains. Most things are working fine, but writing to a subdomain does not work in the same way as it did before. What is generally bad with the  System.DirectoryServices.Protocols is the documentation, which is practically non-existent. But most things can  be figured out anyway since most classes just are wrappers for the wldap32.dll, which in turn is way better documented. I would like to have as little bindings to a specific server as possible but still be able to access the domain. In the  LdapConnection  it is possible to set the identifier to null and use the executing computer as a starting point to find a domain controller. But sometimes I must know that I am using a Global Catalog, and with more and more RODC in the environment I sometimes must know that I am working against...

So far we have managed to exclude  System.DirectoryServices  because of our original issues, and  System.DirectoryServices.AccountManagement  because of performance issues. What is left for us now is  System.DirectoryServices.Protocols , and that is the namespace of our choice. Generally the  System.DirectoryServices.Protocols  is pretty similar to System.DirectoryServices , so it is not a big deal to rebuild our existing classes to a newer version. But there are always some small obsacles that need to be conquered. A very good guide to get started with these classes is written by Ethan Wilansky and published on MSDN, Introduction to System.DirectoryServices.Protocols . An small issue is that you always have to know if an attribute exists before you try to remove it. The same thing applies when an attribute is saved, you must know if it is a new attribute to be created or an existing attribute that should be updated. If an incorrect action is taken...

To work around the memory leaking issues in the .NET classes is in theory quite simple, do not use those classes. That is the starting point we had. Instead what we want to do is, by minimizing the affection on all our projects, rebuild our AD classes to use a beter way to communicate with the Active Directory. In .NET 2.0 the  System.DirectoryServices.Protocols  was introduced, which is a collection of general classes to communicate with practically any directory over LDAP. Unlike  System.DirectoryServices  which builds on  ADSI , the  System.DirectoryServices.Protocols  builds on the newer and better wldap32.dll. Heres an overview of the different namespaces and what teqniques they rely on, taken from  Introduction to System.DirectoryServices.Protocols . In .NET 3.5 yet another namespace arrived, namely  System.DirectoryServices.AccountManagement . This is excactly as it sounds a set of classes for account management. In theory thi...

We have a pretty old class library to communicate with Active Directory, shich is built on  System.DirectoryServices . It has worked very well during all these years, but since the size of the systems and the number of users have increased we have begun to see some performance related issues. The environment that is least stable at the moment consists of a root domain and a subdomain. The problem is the following error that sometimes occur on a search in the subdomain: System.DirectoryServices.DirectoryServicesCOMException (0x8007202B): A referral was returned from the server. This is not an unusual issue, but we have taken some steps for these issues not to occur. What is also interesting is that they seem to occur at random. Once the problem occured once the subdomain is unreachable for the current application until the application or application pool is restarted. Part of the problem is some poor memory management in  SearchResultCollection , which never disposes of...