We Keep Coding

How to display the value of a Search Result Collection from Active Directory in C#?

My boss sends me a txt file with some id numbers. I need to get some info from users that have those id numbers.
I've never done anything with Active Directory so I'm a little lost. Right now, I'm just trying to make sure that I can access the "muID" property from AD. But when I search AD for the property and try to get the value of the property I get an output of it "System.DirectoryServices.ResultPropertyValueCollection" instead of the value, which should be similar to "111123456."
Here is my code so far:
SearchResultCollection sResults = null;
string path = "LDAP://muad1";
DirectoryEntry dEntry = new DirectoryEntry(path);
DirectorySearcher dSearcher = new DirectorySearcher(dEntry);
dSearcher.Filter = "(&(objectClass=user))";
dSearcher.PropertiesToLoad.Add("muID");
SearchResultCollection results = dSearcher.FindAll();
if (results != null)
{
foreach (SearchResult result in results)
{
Console.WriteLine(result.ToString());
}
}
But that's not working. I've tried searching around but I can't anything that works. I've tried this
Console.WriteLine(result.Properties["muID"].ToString());
Console.WriteLine(dEntry.Properties[result].ToString());
Console.WriteLine(dEntry.Properties[result][0].ToString());
Console.WriteLine(dEntry.Properties["result"].ToString());
but none of them work. They either throw an error or do the same thing that the one on the code block does.
Again, I want to make sure that I'm accessing that property so I can then get the info that I want. I thought displaying the value of the property would be a good way to check. But it is not displaying the right thing.

Oh I feel like you're so close.
A SearchResultCollection contains SearchResult instances: Info on SearchResultCollection
A SearchResult contains a Properties property: Info on SearchResult
SearchResult Properties is a ResultPropertyCollection: Info on ResultPropertyCollection
If you update your code from
Console.WriteLine(result.ToString());
to:
Console.WriteLine(result.Properties["muID"][0].ToString());
then you should find what you're looking for. To be safe I would also make sure before accessing the element at [0], you check to make sure it exists first. You might run into an exception if a user doesn't have that property at all.
Edit:
This might help you to see what property and value pairs are available for you to use. If you don't see "muID" anywhere then that's why you're getting an error.
if (results != null)
{
foreach (SearchResult result in results)
{
foreach(string propName in result.Properties.PropertyNames)
{
foreach(object myCollection in result.Properties[propName])
{
Console.WriteLine(propName + " : " + myCollection.ToString());
}
}
}
}

LDAP search returns less objects than expected

I am attempting to pull every user from Active Directory. I am using this method currently:
DirectorySearcher search = new DirectorySearcher();
search.Filter = "(objectClass=user)";
foreach (SearchResult result in search.FindAll())
{
if(result.Properties["mail"].Count > 0 && result.Properties["displayName"].Count > 0)
{
emailAddresses.Add(new EmailDetails
{
EmailAddress = result.Properties["mail"][0].ToString(),
EmailDisplayName = result.Properties["displayName"][0].ToString()
});
}
}
This is only givnig me around 3/4 of the names I am expecting. It is for one leaving me out.... So I got curious and added a new filter to see if I could pull myself by changing the filter to this:
search.Filter = "(&(objectClass=user)(sn=za*))";
This did in fact pull me in correctly, I basically am forcing it to pull me in by setting the filter to search for every last name that starts with za. But why is the first search filter I am using not pulling all of the users in?

why is the first search filter I am using not pulling all of the users in?
Most likely because SizeLimit kicks in at 1000 records. Set a PageSize to enable result paging.
Doing .FindAll() with no filter to speak of and then filtering the results on the client is silly. Write a proper filter.
var search = new DirectorySearcher();
search.Filter = "(&(objectClass=user)(mail=*)(displayName=*))";
search.PageSize = 1000; // see 1.
using (var results = searcher.FindAll()) { // see 2.
foreach (var result in results)
{
emailAddresses.Add(new EmailDetails
{
EmailAddress = result.Properties["mail"][0].ToString(),
EmailDisplayName = result.Properties["displayName"][0].ToString()
});
}
}
Small page size = faster results but more server round trips, larger page size = slower results but less server round trips. Pick a value that works for you.
You must dispose the SearchResultCollection manually, see "Remarks" in the MSDN documentation of DirectorySearcher.FindAll(). A using block will dispose the object properly.

My method is always returning false, why?

public bool IsUser(string username)
{
bool user = false;
using (var client = new datingEntities())
{
var result = from x in client.Person
select x;
foreach (var item in result)
{
if (item.Username == username)
{
user = true;
}
}
}
return user;
}
This method am I using to get data from a SQL database that I have. It's no problem with the database connection, it's just that it always is returning false even if the parameter username is existing in the database (double checked the data in the database). I tried this method before and then it worked but it don't. I'm using entity framework against my database

This will do:
public bool IsUser(string username)
{
using (var entities = new datingEntities())
{
return entities.Person.Any(p => p.Username == username);
}
}
Now you request all user entities and loop through them to see if the user matches the queried username. You should let Entity Framework or LINQ write the queries, which you do as demonstrated above.
As for the reason your function is not working: set a breakpoint, find out if any users are found at all. We can't debug that for you.

use "ToUpper()"
if (item.Username.ToString().ToUpper() == username.ToUpper())
{
user = true;
}
[EDITED]
OR use "Equal"
item.Equals(username, StringComparison.OrdinalIgnoreCase)

I would convert both item.UserName and username values to the lowercase and compare them this way. This looks more reliable. Also, your linq query can be changed to avoid the loop as follows:
var result = from x in client.Person
where x.UserName.ToLower() == userName.ToLower()
select x;

My answer is less good than others as mentioned in the comments, but I left it here for reference purposes.
I'm not sure why it returns false but what you are trying to achieve is usually done in the following way:
public bool IsUser(string username)
{
using (var client = new datingEntities())
{
User user = client.Persons.SingleOrDefault(u => u.Username == username);
return user != null;
}
}
This way is a lot more efficient than your way because you first pull all User records from the database to then iterate through them to find the one user with the Username equal to the provided string. My way tries to get the one record with the Username equal to the provided string, if no such record exists I return false and otherwise true.

ActiveDirectory with Range not changing results using DirectorySearcher

So I'm basically trying to enumerate results from AD, and for some reason I'm unable to pull down new results, meaning it keeps continuously pulling the first 1500 results even though I tell it I want an additional range.
Can someone point out where I'm making the mistake? The code never breaks out of the loop but more importantly it pulls users 1-1500 even when I say I want users 1500-3000.
uint rangeStep = 1500;
uint rangeLow = 0;
uint rangeHigh = rangeLow + (rangeStep - 1);
bool lastQuery = false;
bool quitLoop = false;
do
{
string attributeWithRange;
if (!lastQuery)
{
attributeWithRange = String.Format("member;Range={0}-{1}", rangeLow, rangeHigh);
}
else
{
attributeWithRange = String.Format("member;Range={0}-*", rangeLow);
}
DirectoryEntry dEntryhighlevel = new DirectoryEntry("LDAP://OU=C,OU=x,DC=h,DC=nt");
DirectorySearcher dSeacher = new DirectorySearcher(dEntryhighlevel,"(&(objectClass=user)(memberof=CN=Users,OU=t,OU=s,OU=x,DC=h,DC=nt))",new string[] {attributeWithRange});
dSeacher.PropertiesToLoad.Add("givenname");
dSeacher.PropertiesToLoad.Add("sn");
dSeacher.PropertiesToLoad.Add("samAccountName");
dSeacher.PropertiesToLoad.Add("mail");
dSeacher.PageSize = 1500;
SearchResultCollection resultCollection = resultCollection = dSeacher.FindAll();
dSeacher.Dispose();
foreach (SearchResult userResults in resultCollection)
{
string Last_Name = userResults.Properties["sn"][0].ToString();
string First_Name = userResults.Properties["givenname"][0].ToString();
string userName = userResults.Properties["samAccountName"][0].ToString();
string Email_Address = userResults.Properties["mail"][0].ToString();
OriginalList.Add(Last_Name + "|" + First_Name + "|" + userName + "|" + Email_Address);
}
if(resultCollection.Count == 1500)
{
lastQuery = true;
rangeLow = rangeHigh + 1;
rangeHigh = rangeLow + (rangeStep - 1);
}
else
{
quitLoop = true;
}
}
while (!quitLoop);

You're mixing up two concepts which is what is causing you trouble. This is a FAQ on the SO forums so I probably should blog on this to try and clear things up.
Let me first just explain the concepts, then correct the code once the concepts are out there.
Concept one is fetching large collections of objects. When you fetch a lot of objects, you need to ask for them in batches. This is typically called "paging" through the results. When you do this you'll get back a paging cookie and can pass back the paged control in subsequent searches to keep getting a "page worth" of results with each pass.
The second concept is fetching large numbers of values from a single attribute. The simple example of this is reading the member attribute from a group (ex: doing a base search for that group). This is called "ranged retrieval." In this search mode you are doing a base search against that object for the large attribute (like member) and asking for "ranges" of values with each passing search.
The code above confuses these concepts. You are doing member range logic like you are doing range retrieval but you are in fact doing a search that is constructed to return a large # of objects like a paged search. This is why you are getting the same results over and over.
To fix this you need to first pick an approach. :) I recommend range retrieval against the group object and asking for the large member attribute in ranges. This will get you all of the members in the group.
If you go down this path, you'll notice you can't ask for attributes for these values. The only vlaue you get is the list of members, and you can then do searches for them. IF you opt to stay with paged searches like you have above, then you end up switching to paged searches.
If you opt to stick with paged searches, then you'll need to:
Get rid of the Range logic, and all mentions of 1500
Set a page size of something like 1000
Instead of ranging, look up how to do paged searches (using the page search control) using your API
If you pick ranging, you'll switch from a memberOf search like this to a search of the form:
a) scope: base
b) filter: (objectclass=)
c) base DN: OU=C,OU=x,DC=h,DC=nt
d) Attributes: member;Range=0-
...then you will increment the 0 up as you fetch ranges of values (ie do this search over and over again for each subsequent range of values, changing only the 0 to subsequent integers)
Other nits you'll notice in my logic:
- I don't set page size...you're not doing a paged search, so it doesn't matter.
- I dont' ever hard code the value 1500 here. It doesn't matter. Ther eis no value in knowing or even computing this. The point is that you asked for 0-* (ie all), you got back 1500, so then you say 1500-, then 3000-, and so on. You don't need to knwo the range size, only what you have been given so far.
I hope this fully answers it...
Here is a code snip of doing a paged search, per my comment below (this is what you would need to do using the System.DirectoryServices.Protocols namespace classes, going down the logical path you started above (paged searches, not ranged retrieval)):
string searchFilter = "(&(objectClass=user)(memberof=CN=Users,OU=t,OU=s,OU=x,DC=h,DC=nt))";
string baseDN = "OU=C,OU=x,DC=h,DC=nt";
var scope = SearchScope.Subtree;
var attributeList = new string[] { "givenname", "sn", "samAccountName", "mail" };
PageResultRequestControl pageSearchControl = new PageResultRequestControl(1000);
do
{
SearchRequest sr = new SearchRequest(baseDN, searchFilter, scope, attributeList);
sr.Controls.Add(pageSearchControl);
var directoryResponse = ldapConnection.SendRequest(sr);
if (directoryResponse.ResultCode != ResultCode.Success)
{
// Handle error
}
var searchResponse = (SearchResponse)directoryResponse;
pageSearchControl = null; // Reset!
foreach (var control in searchResponse.Controls)
{
if (control is PageResultResponseControl)
{
var prrc = (PageResultResponseControl)control;
if (prrc.Cookie.Length > 0)
{
pageSearchControl = new PageResultRequestControl(prrc.Cookie);
}
}
}
foreach (var entry in searchResponse.Entries)
{
// Handle the search result entry
}
} while (pageSearchControl != null);

Your problem is caused by creating new object of directory searcher in loop. Each time there will be new object that will take first 1500 records. Create instance of searher out of the loop and use same instance for all queries.

LINQ to SharePoint 2010 getting error "All new entities within an object graph must be added/attached before changes are submitted."

I've been having a problem for some time, and I've exhausted all means of figuring this out for myself.
I have 2 lists in a MS Sharepoint 2010 environment that are holding personal physician data for a medical group...nothing special just mainly text fields and a few lookup choice fields.
I am trying to write a program that will migrate the data over from List A to List B. I am using LINQ to Sharepoint to accomplish this. Everything compiles just fine, but when it runs and hits the SubmitChanges() method, I get a runtime error that states:
"All new entities within an object graph must be added/attached before changes are submitted."
this issue must be outside of my realm of C# knowledge because I simply cannot find the solution for it. The problem is DEFINITELY stemming from the fact that some of the columns are of type "Lookup", because when I create a new "Physician" entity in my LINQ query, if I comment out the fields that deal with the lookup columns, everything runs perfectly.
With the lookup columns included, if I debug and hit breakpoints before the SubmitChanges() method, I can look at the new "Physician" entities created from the old list and the fields, including data from the lookup columns, looks good, the data is in there the way I want it to be, it just flakes out whenever it tries to actually update the new list with the new entities.
I have tried several methods of working around this error, all to no avail. In particular, I have tried created a brand new EntityList list and calling the Attach() method after each new "Physician" Entity is created, but to no avail, it just sends me around in a bunch of circles, chasing other errors such as "ID cannot be null", "Cannot insert entities that have been deleted" etc.,
I am no farther now than when I first got this error and any help that anyone can offer would certainly be appreciated.
Here is my code:
using (ProviderDataContext ctx = new ProviderDataContext("http://dev"))
{
SPSite sitecollection = new SPSite("http://dev");
SPWeb web = sitecollection.OpenWeb();
SPList theOldList = web.Lists.TryGetList("OldList_Physicians");
//Create new Physician entities.
foreach(SPListItem l in theOldList.Items)
{
PhysiciansItem p = new PhysiciansItem()
{
FirstName = (String)l["First Name"],
Title = (String)l["Last Name"],
MiddleInitial = (String)l["Middle Init"],
ProviderNumber = Convert.ToInt32(l["Provider No"]),
Gender = ConvertGender(l),
UndergraduateSchool =(String)l["UG_School"],
MedicalSchool = (String)l["Med_School"],
Residency = (String)l["Residency"],
Fellowship = (String)l["Fellowship"],
Internship = (String)l["Internship"],
PhysicianType = ConvertToPhysiciantype(l),
Specialty = ConvertSpecialties(l),
InsurancesAccepted = ConvertInsurance(l),
};
ctx.Physicians.InsertOnSubmit(p);
}
ctx.SubmitChanges(); //this is where it flakes out
}
}
//Theses are conversion functions that I wrote to convert the data from the old list to the new lookup columns.
private Gender ConvertGender(SPListItem l)
{
Gender g = new Gender();
if ((String)l["Sex"] == "M")
{
g = Gender.M;
}
else g = Gender.F;
return g;
}
//Process and convert the 'Physician Type', namely the distinction between MD (Medical Doctor) and
//DO (Doctor of Osteopathic Medicine). State Regualtions require this information to be attached
//to a physician's profile.
private ProviderTypesItem ConvertToPhysiciantype(SPListItem l)
{
ProviderTypesItem p = new ProviderTypesItem();
p.Title = (String)l["Provider_Title:Title"];
p.Intials = (String)l["Provider_Title"];
return p;
}
//Process and convert current Specialty and SubSpecialty data into the single multi-choice lookup column
private EntitySet<Item> ConvertSpecialties(SPListItem l)
{
EntitySet<Item> theEntityList = new EntitySet<Item>();
Item i = new Item();
i.Title = (String)l["Provider Specialty"];
theEntityList.Add(i);
if ((String)l["Provider SubSpecialty"] != null)
{
Item theSubSpecialty = new Item();
theSubSpecialty.Title = (String)l["Provider SubSpecialty"];
theEntityList.Add(theSubSpecialty);
}
return theEntityList;
}
//Process and add insurance accepted.
//Note this is a conversion from 3 boolean columns in the SP Environment to a multi-select enabled checkbox
//list.
private EntitySet<Item> ConvertInsurance(SPListItem l)
{
EntitySet<Item> theEntityList = new EntitySet<Item>();
if ((bool)l["TennCare"] == true)
{
Item TenncareItem = new Item();
TenncareItem.Title = "TennCare";
theEntityList.Add(TenncareItem);
}
if ((bool)l["Medicare"] == true)
{
Item MedicareItem = new Item();
MedicareItem.Title = "Medicare";
theEntityList.Add(MedicareItem);
}
if ((bool)l["Commercial"] == true)
{
Item CommercialItem = new Item();
CommercialItem.Title = "Commercial";
theEntityList.Add(CommercialItem);
}
return theEntityList;
}
}

So this may not be the answer you're looking for, but it's what's worked for me in the past. I've found that updating lookup fields using Linq to Sharepoint to be quite frustrating. It frequently doesn't work, or doesn't work efficiently (forcing me to query an item by ID just to set the lookup value).
You can set up the entity so that it has an int property for the lookup id (for each lookup field) and a string property for the lookup value. If, when you generate the entities using SPMetal, you don't generate the list that is being looked up then it will do this on it's own. What I like to do is (using your entity as an example)
Generate the entity for just that one list (Physicians) in some temporary folder
Pull out the properties for lookup id & value (there will also be private backing fields that need to come along for the ride too) for each of the lookups (or the ones that I'm interested in)
Create a partial class file for Physicians in my actual project file, so that regenerating the entire SPMetal file normally (without restricting to just that list) doesn't overwrite changes
Paste the lookup id & value properties in this partial Physicians class.
Now you will have 3 properties for each lookup field. For example, for PhysicianType there will be:
PhysicianType, which is the one that is currently there. This is great when querying data, as you can perform joins and such very easily.
PhysicianTypeId which can be occasionally useful for queries if you only need ID as it makes it a bit simpler, but mostly I use it whenever setting the value. To set a lookup field you only need to set the ID. This is easy, and has a good track record of actually working (correctly) in my experiences.
PhysicianTypeValue which could be useful when performing queries if you just need the lookup value, as a string (meaning it will be the raw value, rather than something which is already parsed if it's a multivalued field, or a user field, etc. Sometimes I'd rather parse it myself, or maybe just see what the underlying value is when doing development. Even if you don't use it and use the first property, I often bring it along for the ride since I'm already doing most of the work to bring the PhysicianTypeId field over.
It seems a bit hacky, and contrary to the general design of linq-to-SharePoint. I agree, but it also has the advantage of actually working, and not actually being all that hard (once you get the rhythm of it down and learn what exactly needs to be copied over to move the properties from one file to another).