Getting rid of the Formview templates

Having a readonly-mode and an edit-mode in a webform to manipulate data is a pretty common situation.

Microsoft promotes using the FormView control. This might be a good idea when there's not a lot of data to edit, and when the readonly-mode is very different from the edit-mode. But what I mostly see is that the readonly-mode is a copy of the edit-mode with some controls disabled, which is a pain in the ass to maintain.

That's why I got rid of the FormView!

I made a method which can be called from any page/usercontrol and which recusively searches the ControlCollection and sets the Enable-property for some controls.

Take a look at this codesnippet.



This method iterates through the ControlCollection and checks the type of every control. When this control is a TextBox, DropDownList, Button or an ImageButton the control gets casted to a WebControl and the Enabled property gets set.

FormView does not render

I came across this one today. And it took me a few minutes to see it.

I wanted to use the Item-, Edit- and InsertTemplate from the FormView but I didn't want to use the out-of-the box DataBinding.

As it turns out, the FormView needs a DataSource. The MSDN documentation makes this very clear.

A FormView displays the values of a single record from a data source using user-defined templates. The FormView control allows you to edit, delete, and insert records.

And yes, it's pretty logical, but what if you want to use a FormView without DataBinding? You can simply create a fake DataSource.

I did something like this.



I created a list of Objects containing one Object and binded that to the FormView and it works like a charm.

Curt Christianson released Asp.Net 3.5 CMS Development

Curt Christianson released the book ASP.NET 3.5 CMS Development.

Find more about the book on his blog.
In January I had a talk with him, you can find that interview here.

Active Directory in .NET: Recursively find all groups for a user

I had to write a function which returns all the groups (even if they are nested) for a user.
A good thing I discovered the System.DirectoryServices.AccountManagement namespace.

Take a look at the code snippet. I think it's pretty readable.. What do you think?



The GetListOfGroupsRecursively() function tries to find a Principal object by the Username of the ADUser parameter. If the Principal object is found, we call the GetGroups() function and store it's return value in a PrincipalSearchResult. If there are searchresults, we try to get the members for each group by calling the GetMembersForGroup() method. This method recursively searches through all the members of the group looking for Principal objects where the StructuralObjectClass equals "group".

Active Directory in .NET: Getting started (A better version - Using the AccountManagement namespace)

A few days ago I blogged on Active Directory in .NET: Getting Started.

In that post I stated that everything you need to query the Active Directory in .NET lives in the System.DirectoryServices, well that was a lie. .NET Framework 3.5 introduced the System.DirectoryServices.AccountManagement namespace.

I learned about this namespace today, and wow, it really is much better. I have rewritten our own Active Directory wrapper in less then a few hours.

All you need to know in general is that everything you do using the AccountManagement namespace needs to run under a PrincipalContext.



Let me show you two basic methods..

I commented out the original method which uses the DirectoryServices namespace. Can you see the difference?

Authenticate a user



Get the DisplayName of a user



The code hardly needs any explanation. Hope it helps!

Active Directory in .NET: Getting started

Note: If you are using .NET Framework 3.5 or better, check out this post for querying the Active Directory!

Working with the Active Directory is one of the things that every .NET or ASP.NET will face in his career. Most of the time you need information from the Active Directory. Editing, inserting or removing objects from a .NET (web)application is very rare, mostly because a System Administrator is managing the Active Directory.

Let me show you how to get started on getting information out of the Active Directory.

The basics

Everything you need to work with the Active Directory lives in the System.DirectoryServices namespace.

The most important classes you will need are:
Directory Searcher
Directory Entry
Search Result

So I advice you reading through the documentation of these classes.

Getting familiar with LDAP queries

I strongly advice you to try LDP.EXE

Ldp.exe is a Windows 2000 Support Tools utility you can use to perform Lightweight Directory Access Protocol (LDAP) searches against the Active Directory for specific information given search criteria. This also allows administrators to query data that would otherwise not be visible through the Administrative tools included in the product. All data that is returned in LDP queries, however, is subject to security permissions.

This tool will help you understand LDAP queries. Go through this article in the Microsoft Knowledge Base to get started.