.Net Development

System.Data.OracleClient vs. Oracle ODP - Not all things .Net

Michael J. Hamilton, Sr. — Tue, 06 Mar 2007 16:10:00 GMT

I recently had the not-so-great-or-fun pleasure of a pure .Net to Oracle application show-down :) And yes, I say that with some pun.

In summary, keeping to proper form, I developed a DataProviderFactory that provided the following:

SQL Server native client API
Oracle
BDC to SQL Server
BDC to Oracle

Now, BDC = Business Data Catalog - a new service provider native to MOSS (Micrsoft Office SharePoint Server) 2007. And trust me - the BDC ROCKS!!!

Back to providers.

My provider factory basically provided classes for base types and class bases - the lowest level. In the solution I coded specific classes for the given provider (Oracle, SQL, etc) and within the Assembly.cs for that class - I'd reference the appropriate base class. All run-of-the-mill best practice stuff. Right? Well, almost.

After several hours of seeing varrying results from the Oracle database, I began to get a little suspicious - and sure enough - the provider with .Net is not all things .Net - at least not for Oracle.

If you are coding for a Oracle specific application - check out this link for specifics on the Oracle Data Provider for .Net - or the ODP. The API is 'similar' - but only SIMILAR - it is not the same. I invariably tore out the .Net System.Data.OracleClient and replaced it with the Oracle .Net provider and all came together - but this was not obvious or intuitive.

HTH's another weary developer struggling to sort out why - for lack of a better way to say it - when dealing with Oracle - it's not all things .Net.

Microsoft Office SharePoint Server (MOSS) 2007 - Configuration / Setup - Login failed for user ''. The user is not associated with a trusted SQL Server configuration.

Michael J. Hamilton, Sr. — Sun, 11 Feb 2007 15:45:00 GMT

After installing MOSS and launching the SharePoint Configuration Wizard (psconfig.exe) - you are ready to begin the last leg of your MOSS installation/setup.

Here you provide the setup with the particualars for your server. Often you are installing MOSS with SQL Server being remote from MOSS, and you will be using a domain-level service account for the installation. The following is an example of the data you might enter during this step:

(if the pic does not show - click here)

Here you have a named instance of SQL Server - HAMPDOCNC running on a machine named HAMDC02.

You have a service account - $ervice_MossSa - that is a domain-level account running on the HAMILTON domain.

You click NEXT and you get the following:

(if the pic doesn't show - click here)

There are a number of reasons you can get this message. In short, if you review the 3rd to last ERR entry in the PCSDiagnostics (latest one) in \Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS - you'll see the above titled error - followed by a slew of other highly technical dump mumbo jumbo.

The gist is - the account is not getting passed to SQL Server. Why?

When you Google and otherwise research this error - it more often is associated with trying to connect to SQL Server from a ASP.Net application - but this is not the case here.

Here are a couple of obvious things to check if you receive this message:

Ensure that the Surface Area Configuration for SQL Server has been run on the host SQL Server - and that remote connections are allowed and that the transport of both TCP/IP and Named Pipes has been set.
Ensure that Enable Network DTC has been configured on both the SQL Server and any/all MOSS host servers.

Finally, be sure you reboot the MOSS host after setting up the Enable Network DTC

HTH's...

Developing with Visual Studio on a Vista Workstation

Michael J. Hamilton, Sr. — Sat, 13 Jan 2007 00:34:00 GMT

As Vista gains momentum, and many of us get our hands on it - we're quickly faced with a question that not many seem able to answer. More disconcerting - there is nothing solid out there to provide direction.

If I am a ASP.Net developer - I want IIS available for my development pleasure.

More important, I will probably be using Visual Studio to crank out my applications.

There is a lot of effort in the launch of Vista and the new Office products - but what about the development community? Especially if we're not one of the few that can afford to travel the globe and partake of the special developer launches sponsored by MSFT?

A good start is here for the latest developments regarding Visual Studio and Vista. Pay special attention to that one line about VS .Net 2002 and 2003 not being supported on Vista! This is very important to many in the development community.

Be sure to get up to speed on the Visual Studio SP1 release. A touted 70+ enhancements, including:

New processor support (e.g., Core Duo) for code generation and profiling

Performance and scale improvements in Team Foundation Server

Team Foundation Server integration with Excel 2007 and Project 2007

Tool support for occasionally connected devices and SQL Server Compact Edition

Additional support for project file based Web applications

Windows Embedded 6.0 platform and tools support

Yes, MSFT announced a SP1 for Vista, covered pretty decent here but you should know that this release is beta. The official release will not appear until RTM Vista is launched in January/February this year.

Planning automated deployments of Visual Studio on Vista workstations? Be sure to review this blog on some issues identified early on. The honeymoon is over!

Be sure to check out the latest pod casts that highlight the latest Visual Studio tools / technologies / direction.

As I ramp up to start doing all of my development on Vista - I'll keep you posted on the pitfalls and niceties - if they're to be found!

The IIS Admin Service service terminated with service-specific error 2149648394 (0x8021080A).

Michael J. Hamilton, Sr. — Wed, 13 Dec 2006 21:16:00 GMT

The IIS Admin Service service terminated with service-specific error 2149648394 (0x8021080A).

IIS Admin Service goes away after restoring a VHD / VPC Server

I recently had the unexpected pleasure of losing my IIS Admin server - altogether!!! Translate - 150% !!!

Now, before this - everything was going great - except. During an upgrade of MOSS (Microsoft Office SharePoint Server) I encounted an issue that forced me to restore a VPC image - essentially bringing over another copy of the VHD and firing the server back up.

Interstingly, during that reboot - which for all intents should have gone fine - I see a hoard of DSKCHK processes running. Invariably, something got out of wack on the NTFS volumn between my shutting the image down and bringing it back up. During the 'fixing' process - a number of files invaribly can become corrupt - and the Metabase.xml - the blood-life of your IIS Admin service - is no exception. SO

Check in C:\Windows\System32\Inetsrv and you'll find a 'History' folder. Within here - hopefully - you'll find fairly recent backups of the Metabase.XML and MBSchema.XML objects. Before doing the following - be sure to backup the existing Metabase.xml and MBSchema.xml from C:\Windows\System32\Inetsrv first.

Now, rename a recent backup from the 'History' folder - renaming a recently Metabase.XML object, and then a recent MBSchema.XML object. Copy / Paste each of these to the C:\Windows\System32\Inetsrv.

Ahh, not quite done.

Now do a IISRESET from a command prompt.

Hopefully this will get you back to where you need to be.

Visual Studio Team System - Visual Studio code-name "Orcas"

Michael J. Hamilton, Sr. — Sat, 04 Nov 2006 21:35:00 GMT

Visual Studio Team System - Visual Studio code-name "Orcas"

If you are heavy into .Net development and Visual Studio (VS) - you are already aware of VS's rich IDE and are probably familiar with some, if not many of the VS extensions, like Tools for Office (VSTO) and integration with other products like BizTalk and the Windows Workflow Foundation (get an intro to WWF and how to use it).

So what is Orcas? In a word, the latest offering for Vista and the 2007 Office System development platform.

Read the roadmap here. You have been hearing about the new features in Vista and .Net 3.0 - the Windows Presentation Foundation, the Windows Communication Foundation, and the Windows Workflow Foundation. Get ready for the tools to help you leverage these new extensions of the .Net Framework - and much more!

Learn more about how you can help create the experience for your customers, and leverage the latest in developer technologies.

IronPython - Microsoft IronPython - The revitalization of a great language - Python

Michael J. Hamilton, Sr. — Sat, 04 Nov 2006 21:02:00 GMT

IronPython, Microsoft's answer to my own and many other developer's request for a serious language for ASP.Net development - is gaining momentum and that's a great thing.

Those familiar with Python are aware of the power the language provides. A true, object oriented programming (OOP) language, Python is an open source initiative that has been widely adopted and it runs on a host of different platforms / operating systems (OS's).

IronPython is a new flavor of Python that runs on .Net providing integration with all .Net libraries and making the language even more attractive - especially to existing ASP.Net developers.

Check out this webcast for an introduction, and be sure to visit the IronPython site for details on how to get started.

If you are familiar with IronPython, you can download the latest bits here.

Microsoft .Net 3.0 Framework - What is .Net 3.0 and what is new?

Michael J. Hamilton, Sr. — Sat, 04 Nov 2006 20:49:00 GMT

Microsoft .Net 3.0 Framework - What is .Net 3.0 and what is new?

As a developer in the field, I am asked periodically about one new technology or another. And these days, I am overwhelmed with questions about MOSS and Vista. Occassionally, I am asked about the new development tools and frameworks - and .Net 3.0 is a hot topic.

So, what's new in .Net 3.0? In a word - a lot!

Is .Net 2.0 being replaced? Are my previous and current development efforts going to require re-work? No, .Net 2.0 is not being replaced, and no you will not have to re-work existing .Net 2.0 applications. The .Net 3.0 is an extension of the current .Net 2.0 Framework - not a re-write or upgrade.

Please review Microsoft's overview of the technology, and get a handle on where we're going.

NewSID - and the Future of SysInternals

Michael J. Hamilton, Sr. — Tue, 12 Sep 2006 13:28:00 GMT

I recenlty had a question about a link I have had for NewSID on my blog regarding re-SIDing a VM or server OS in general.

I sincerely apologize for not keeping up with the times.

This link will convey what is going on - basically, the guys that have been a great help for us at SysInternals - well, they've gone internal!!!

My hat is off to them - many congratulations.

Now, who wants to host an FTP link to NewSID??? :)

I'll see if I can get permission to do that.

Chip Head / Code Junkie / Technical Support / Blogs / News Group Support / Another day in paradise :)

Michael J. Hamilton, Sr. — Sun, 16 Jul 2006 01:47:00 GMT

So who is Michael J. Hamilton, Sr.? Candidly? I still don't know :)

Over a quarter century ago my wife joked that she was going to marry me, we'd have 10 children and live happily ever after.

Today? We have 9 children, 5 grandchildren, and I still can't get enough of coding!!! Yea, I know - I lost it a long time ago :)

I cut my teeth with the Apple II series some 22 years ago. I wound up working for Apple on the design of the UCSD (Unversity of So. Cal/San Diego) Pascal firmware, as well as firmware and OS pieces for the Apple IIGS. It really was a fun time - and certainly, those were the days!!! Alas, larger processors, and Microsoft. (I didn't say that.)

Today I enjoy the mild-mannered 8-10 hour days as a Software Architect and I get to play with most of the latest/greatest toys from MSFT.

At night I turn/burn in a frenzy to get my fix - writing code!!! I still love stemming out web sites, coding custom e-commerce applications, and plain and simple - WRITING CODE!!!

Revisiting my blog - which I've only been doing a little over a year now; visiting both the beta and public newsgroups for one product or another, and still trying to find time to be dad - well - in a word, I do not have a dotfuscator for that yet. But I'm working on it!

To all of those in the community that spend your time doing the same, I want to say thank you - and I mean that sincerely. I would not be where I am today if it were not for the many people just like myself that take the time to post their adventures. I have worked with 1 of the best organizations in the world insofar as teamwork and support goes, and I can also say that a great extension of that teamwork is the network of people I have met here and in many other - blogs.

Please keep up the great work - and know that you really are appreciated.

MikeH... Another Geek In Need... :)

.Net Directory Services Programming - C# - Part 3

Michael J. Hamilton, Sr. — Sat, 15 Jul 2006 19:47:00 GMT

.Net Directory Services Programming – C# - Part 3

Topics

DirectorySearcher – the other critical class in the DirectoryServices namespace.

Review

Because a lot of your Directory Services (DS) development will involve querying DS for data, it makes sense that this is a powerful class offered in the namespace, and below are some of the features:

DirectorySearcher – Performs the initial queries against AD
SearchResult – A single object reference from a search performed by DirectorySearcher
ResultPropertyCollection – A collection of properties of the SearchResult instance
ResultPropertyValueCollection – The values of properties in a SearchResult instance.
SearchResultCollection – Basically a collection of SearchResult instances returned from a query by DirectorySearcher
SortOption – Allows a means to sort a result set.

We have briefly touched on DS by introducing some basic DirectoryEntry information and a couple simple examples, and we have introduced some basic properties and examples on how to interact with those.

I have not taken a lot of time to review a directory structure – basically assuming that you should have some of this understanding already. As I delve into the next lesson, this assumption holds fast. If you have any issues or are dealing with something that I am not elaborating enough on, please feel free to email me directly at (mikeh AT thedataworks.net) and I will respond as quickly as I can. Please forgive the notation there – but we all are familiar with the latest in SPAM bots and whatnot.

Show me the Money!!!

Or at least the code. Lets get started…

Parent – Child Relationships

DirectoryEntry objects (DE’s) can be a root object in AD, or an object within another – hence, a child object of another. We reviewed in Part 1 a few of the common references to object types (CN, OU, DC). These are the most prevalent you will deal with.

DC is the root level context. OU’s can be off the root, or a child of other OU’s and even Containers. CN’s can be off the root, within OU’s and often are found within Containers.

A word about Containers and Security

When planning your DS application, keep this in mind: Containers are non-secure objects! Let me explain. AD security is multi-faceted, yes, but the real security is managed using Group Policy (something we are not going to review here).

Containers are basically folders in your directory tree. AD comes with a couple by default. If you promote a server and check your directory tree, you’ll find a Users, a Built-In, and a couple other folders off the root tree (or context/server name) object. These are not OU’s – they are containers.

Group Policy (GP) cannot be applied to a Container object in AD. You can apply GP to objects within Containers – depending on what those objects are – but not the Container itself. This is important because a lot of administration can be simplified by applying the GP to the entire Container. So if not the Container, then what? Organizational Units – OU’s. Alas, OU’s are going to be your preferred folder or container (for lack of a better way to put it) for object storage.

Basic Searches

In Part 1 we introduced a server name and basic OU’s. To re-cap that:

Server: developer.hamilton.com

OU=Accounts – off the root of developer.hamilton.com

OU=Developers – within the OU=Accounts

CN=Mike Hamilton – within the OU=Developers

Within the OU=Accounts I might also create service accounts – basic user accounts that are used to run services such as IIS Application Pools, SQL Server, or other server / service applications. I might also have OU’s that represent other departments that pertain to development: BA’s for the Business Analyst, QA’s, etc. You can nest OU’s and accounts in just about any way you want to. NOTE: In AD – if you have not already – you will run into one of the inherent limitations of the AD Users & Computers (dsa.msc) snap-in: It can only display the first 2,000 objects within a Container or OU. So if you anticipate a large volume of users for a system you are designing, keep this in mind. You will want to present 1) a more suitable customized user interface piece for administration of this DS, or 2) design your object hierarchy so that users are more spread out within the DS. I will touch base on this topic in a later Part and introduce a couple ideas for addressing this limitation.

DirectorySearcher and the SearchResult

When using the DirectorySearcher class, you have the FindOne() and FindAll() methods that build your result set. As they infer, one finds one occurrence, the other finds all occurrences.

Let’s say I had more than one Mike on my team, and I wanted to find all entries that began with Mike?

DirectoryEntry rootEntry = new DirectoryEntry(); // Binds root context

// Now find every CN that has Mike at the beginning of the name…

DirectorySearcher searcherResults = new DirectorySearcher(rootEntry,”(CN=Mike*)”);

This is a simple example, and the result set will be one or more object references that begin with Mike. Notice that I did a bind on the root of the DS. I could have narrowed the focus of the search to only the developer’s OU by doing the following:

DirectoryEntry developersEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Developers,DC=developer,DC=hamilton,DC=com”);

This would return an entry object where the parent would be the OU=Developers, and not the default root of the DS tree.

Lets say my DS was structured like the following:

developer.hamilton.com à root of the DS

OU=Accounts à First OU of accounts of users.

OU=Developers à Key development personnel

OU=Bas à Business Analyst

OU=QA à Quality Assurance / Test personnel

OU=Users à General users on this server.

Now, we want to find all users that are in the Users OU, not returning the developers or other personnel within the directory. That’s pretty straight forward.

DirectoryEntry developersEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Users,DC=developer,DC=hamilton,DC=com”);

// Now return all users in this OU…

DirectorySearcher searcherResults = new DirectorySearcher(rootEntry,”(CN= *)”);

As you get more familiar with DS programming, you will find there are other ways to accomplish the same result – I am simply trying to open those doors for you.

It is important that you understand how to narrow your search filter in this way because you will find it greatly improves the performance of your application when you know where to search for content and you keep your search filter narrowly defined. For example, if I have 15,000 employees, they would very likely be grouped in AD by their department, and possibly further grouped by sub-departments. I would want to know this information beforehand so I can plan my DS application to be as efficient as possible. I would not want to search the rootDSE each time for a given employee or group of employees, if I know the departments those employees are in.

More on the Search Filter

The filter is a LDAP string that allows you to search for objects based on specific criteria. You will also use relational operators to better refine your search. The following list those operators:

= Equal to

~= Is approximately equal to (or like)

<= Less than or equal to

>= Greater than or equal to

NOTE: You cannot use ‘<’ or ‘>’ individually in LDAP – you must use the notation <= or >=.

The * character works as a wildcard in your search, as in the example above we searched for CN=Mike* or CN=* - in this case, get all Canonical (common) Names beginning with Mike, or get all names period (respectively).

To find all users with a surname of Hamilton you would use

(sn = Hamilton)

To find all users where the email ends in @hamilton.com

(&(objectCategory = person) (objectClass = user) (mail = *@hamilton.com))

Notice the Polish notation used here – the operator comes before the condition. LDAP uses this notation in the Filter. The above example would be more familiar possibly as

(objectCategory = person) AND (objectClass = user) AND (mail = *@hamilton.com)

The following are allowed logical operators:

& AND

| OR

! NOT

You set the filter for a search using the DirectorySearcher.Filter property. The following code will create a binding to the root context, and return everything from the root down:

DirectoryEntry rootEntry = new DirectoryEntry(); // Binds root context

DirectorySearcher rootSearcher = new DirectorySearcher(rootEntry);

Let’s say we have a binding to the rootDSE as above, but only want to return all users with a surname of Hamilton? Change the DirectorySearcher to the following:

DirectorySearcher rootSearcher = new DirectorySearcher(“(sn=Hamilton)”);

You can either pass the DirectoryEntry object, or you can specify a filter in this fashion when creating a DirectorySearcher instance.

Loading Specific Properties

By default, when you create a DirectorySearcher instance, you return all properties for that binding (which can be a lot of data if you have a lot of items in your returned result set).

You can refine your result set by specifying the exact properties to be returned. This is especially important when you could be returning large collections of users.

Following the above example I could create my rootSearcher and then do:

rootSearcher.PropertiesToLoad.Add(“name”);

rootSearcher.PropertiesToLoad.Add(“sn”);

rootSearcher.PropertiesToLoad.Add(“mail”);

rootSearcher.PropertiesToLoad.Add(“telephoneNumber”);

Here I have specifically limited the result set to only include the name, sn (surname), mail and telephoneNumber properties.

Finally, when we define our searcher, we can stipulate the search scope.

Search Scope

The search scope determines the extent of the search in a directory, defaulting to beginning at the root.

In the System.DirectoryServices.SearchScope you will find the following 3 enumerations specified:

Base – Limits the scope to the base, or only 1 object.

OneLevel – Searches 1 level of the immediate child objects, excluding the base object.

Subtree – Searches all child objects under the base object, including the base object.

When creating a DirectorySearcher instance, the following table lists default constructor behaviors:

PROPERTY	DEFAULT VALUE	DESCRIPTION
SearchRoot	Null	Searches the root of the domain controller (rootDSE).
Filter	(objectClass=*)	The search retrieves all objects.
PropertiesToLoad	An empty string array	The search retrieves all properties.
SearchScope	Subtree	The search will be performed on the complete subtree of the base object (or entire domain in this case).

Constructors of the DirectorySearcher Class

The above table displays the default constructor when you create a DirectorySearcher instance like:

DirectoryEntry rootEntry = new DirectoryEntry(); // Binds root context

DirectorySearcher rootSearcher = new DirectorySearcher(rootEntry);

The above specifies the Search Root.

Specifying the Filter Only

We showed this earlier,

DirectorySearcher rootSearcher = new DirectorySearcher(“(sn=Hamilton)”);

Specifying the Search Root and Filter

Create our base / root reference:

DirectoryEntry rootEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Developers,DC=developer.DC=Hamilton,DC=com”);

// Now specify the filter…

DirectorySearch rootSearcher = new DirectorySearcher(rootEntry, “(sn=Hamilton)”);

Specifying the Filter and a List of Properties to load

// Create the set of properties to load…

string [] searchProperties = new string[4];

searchProperties[0] = “name”;

searchProperties[1] = “sn”;

searchProperties[2] = “mail”;

searchProperties[3] = “telephoneNumber”;

// Get all users that have an email ending in hamilton.com…

DirectorySearcher rootSearcher = new DirectorySearcher(“(mail=*hamilton.com)”, searchProperties);

The above example will return all users from the rootDSE with an email ending in hamilton.com. Let’s refine that.

Specifying the Root, Search Filter, and Properties to Load

// Specify the properties to load… Here we get Full Name, Company, Phone…

string [] searchProperties = new string[3];

searchProperties[0] = “name”;

searchProperties[1] = “co”;

searchProperties[2] = “telephoneNumber”;

// Now bind to a more refined root – developers only…

DirectoryEntry rootEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Developers,DC=developer,DC=hamilton,DC=com”);

// No get all users from this root with an email ending in hamilton.com…

DirectorySearcher rootSearcher = new DirectorySearcher(rootEntry, “(mail=*hamilton.com)”, searchProperties);

You should have a better idea now how to use the various constructors of the DirectorySearcher class.

Methods of the DirectorySearcher

When you have created a binding and set filter values, you will use 1 of the 2 DirectorySearcher methods:

FindOne() – Returns the first, and only 1 object of the search criteria.

FindAll() – Returns a SearchResultCollection of all objects that matched the search criteria.

We’ll do a brief sample for each method and wrap up this series with the Sorter class.

Return using FindOne()

// The following demonstrates that FindOne() returns only the first entry that matches the search critieria…

DirectoryEntry rootEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Developers,DC=developer,DC=hamilton,DC=com”);

DirectorySearcher rootSearcher = new DirectorySearcher(rootEntry);

// What to search for…

rootSearcher.Filter = “(CN=*)”;

// Specific properties to load…

rootSearcher.PropertiesToLoad.Add(“name”); // Full name…

rootSearcher.PropertiesToLoad.Add(“mail”); // Primary email addy…

rootSearcher.PropertiesToLoad.Add(“telephoneNumber”); // Phone #...

SearchResult searchResults = rootSearcher.FindOne();

// Extract out the properties returned and display in a console…

ResultPropertyCollection propertiesCollection;

propertiesCollection = searchResults.Properties;

// Cycle through and display (or add to a listbox, etc)…

Foreach (string currentProperty in propertiesCollection.PropertyNames)

{

foreach (Object thisCollection in propertiesCollection[currentProperty])

{

Console.WriteLine(currentProperty + “ = “ + thisCollection);

}

Return using FindAll()

Unlike above, the ResultPropertyCollection being returned with FindOne(), FindAll() comes back in a SearchResultCollection object.

We would process the result set similar to the following:

// Get all objects returned…

foreach (SearchResult searchResults in rootSearcher.FindAll())

{ // Process…

foreach (string propertName in searchResults.Properties.PropertyNames)

{

foreach (Object retEntry in searchResults.Properties[propertyName])

{

Console.WriteLine(propertyName + “ = “ + retEntry);

}

Console.WriteLine(“”);

}

If the root of the search is not properly set, a InvalidOperationException exception will be thrown. Also, if the provider you are trying this against is not supported, a NotSupportedException exception is thrown.

Sorting the Result Sets

Finally, the SortOption class specifies how to sort the result set of a search. The class also allows you to specify either ascending or descending sort order.

Let’s do a search on all users that have an email ending in @hamilton.com and that exist in the Developers OU. Further, restrict the properties returned, sort the list, and using the code snippet above, list the results in a console window.

DirectoryEntry rootEntry = new DirectoryEntry(“LDAP://developer.hamilton.com/OU=Accounts,OU=Developers,DC=developer,DC=hamilton,DC=com”);

DirectorySearcher rootSearcher = new DirectorySearcher(rootEntry);

// Set our search filter and properties to load…

rootSearcher.Filter = “(mail=*hamilton.com)”;

rootSearcher.PropertiesToLoad.Add(“name”); // Full name…

rootSearcher.PropertiesToLoad.Add(“mail”); // Primary email addy…

rootSearcher.PropertiesToLoad.Add(“telephoneNumber”); // Phone #...

// Now sort the result set…

SortOption sortedResults = new SortOption();

sortedResults.PropertyName = “name”; // Sort by full name…

sortedResults.Direction.SortDirection.Ascending;

// Perform the search and output the results..

rootSearcher.Sort = sortedResults;

foreach (SearchResult searchResults in rootSearcher.FindAll())

{ // Process…

foreach (string propertName in searchResults.Properties.PropertyNames)

{

foreach (Object retEntry in searchResults.Properties[propertyName])

{

Console.WriteLine(propertyName + “ = “ + retEntry);

}

Console.WriteLine(“”);

}

Final notes on the following classes: SearchResult, SearchResultCollection, ResultPropertyCollection, and ResultPropertyValueCollection.

The SearchResult class consist of the first entry returned during a search. It retrieves the data from the SearchResultCollection, and the FindOne() method of the DirectorySearcher class returns an instance of the SearchResult class.

The SearchResultCollection class is actually a collection of SearchResult instances and these are returned using the FindAll() method of the DirectorySearcher class. You use the Count property to get the number of items returned in the collection. Use the Item property to index through the SearchResultCollection to enumerate each property. Finally, the PropertiesLoaded property returns a string array containing the names of the properties loaded for the original search criteria.

The ResultPropertyCollection class is accessed as a Properties property of the SearchResult class. It has an Item property you use to index the collection, which is a string value. This index retrieves the values of the property matching the specified index name as a ResultPropertyValueCollection. The following snippet will demonstrate getting all returned properties and outputting the result to a console window:

DirectoryEntry rootEntry = new DirectoryEntry(); // Entire domain…

DireectorySearcher rootSearcher = new DirectorySearcher(rootEntry, “(sn=Hamilton)”);

SearchResult searchResults = rootSearcher.FindOne();

// Get the properties returned…

ResultPropertyCollection propertyCollection = searchResults.Properties;

// Output…

foreach (string thisProperty in propertyCollection.PropertyNames)

{

foreach (Object propertyValue in propertyCollection[thisProperty])

{

Console.WriteLine(thisProperty + “ = “ + propertyValue);

}

In the future I will introduce ADSI API and application code and we will see about developing a small application that will take some of what we have reviewed in these three parts and create a directory browser sample application.

I want to note that for the sample code so far, if you are not executing this on an actual AD domain controller, you will need to change the new DirectoryEntry() code to include the root, username and password of the context you are trying to connect as (we have reviewed this in previous lessons).

Finally, please forgive any typo’s – I try hard to make sure there are none.

I have received a great deal of feedback over the little I have posted so far, and I hope this posting is helpful for some. I apologize again for taking so long to get this series posted.