Replace The Default SharePoint People Picker With A Custom People Picker

At a recent customer of mine the question came up as to how we could replace the default people picker with a custom one that was tailored to some very particular AD queries to supplement the SharePoint calls. I read a few posts about replacing it across the board, notably this one:

http://www.binarywave.com/blogs/rajesh/Lists/Posts/Post.aspx?ID=4

which for the most part is accurate. But this looked like a lot of work.

Reflecting on how a majority of the security assignment stuff happens, the AvlInc.aspx page out of the Layouts directory is the primary workhorse. While modifying such pages out of the 12 hive isn’t technically the best route in terms of surviving updates and service packs, proper noting of the customization to re-integrate back was fine for my requirement.

That being said, after you get a custom picker working ala using inheritance for requisite SimpleQueryControl, PickerDialog, EntityEditorWithPicker classes to override the abstract inherited members with your own behavior, even if you replace the default picker on the page it will not work since the page is querying for a picker with id userPicker. You won’t be able to simply change your custom control to this id and expect it to work because the base type casting will not be supported, thus will throw a nasty error.

The easiest way around it is to toggle the visibility of the primary, OOB picker on the page to not visible, and then create your own code behind page for the AclInv.aspx. This will allow you to interrogate the accounts in the custom picker, copy them to the OOB picker, and then submit the changes (as a note, I am only concerned with one account being in the picker at a time). Once this is done change the page to look at your custom page for it’s code behind. In order to copy the accounts, you have to override the default Validate logic since you are trying to catch the account changes on the button click. To get the control on the page, you are not going to be able to use the orthodox FindControl method, but rather have to recursively search for the control using the Page root as a starting container.

[csharp]
public class test : Microsoft.SharePoint.ApplicationPages.AclInv
{
public override void Validate()
{
var control = (CustomEditorType) FindControlRecursive(Page, “userPicker1”);
foreach (string account in control.Accounts)
{
userPicker.CommaSeparatedAccounts = account;
userPicker.Validate();
}
}

public static Control FindControlRecursive(Control container, string name)
{
if ((container.ID != null) && (container.ID.Equals(name)))
{
return container;
}
return (container.Controls.Cast().Select(
ctrl => FindControlRecursive(ctrl, name))).FirstOrDefault(
foundCtrl => foundCtrl != null);
}

 [/csharp]

Not saying this is 100% great, but as a proof of concept is accuratish.

Share

Can’t Use Resharper 4.5 With LINQ-To-XSD

EDIT: This also occurs in Resharper 5.0

Resharper 4.5 breaks the type references when using Linq-To-XSD, which is really lame. Really, really lame since I use it all the time. So, this is what it looks like when you first set your .XSD to a LinqToXsdSchema build action and reference the project (note: I am not talking about using the command line switches to externally generate the strongly typed DAO files but rather using the inherent VS.NET hooks).

This sucks obviously since you lose intellisense, however the freaking project will build correctly! The only way I have found around it is to disable Resharper when accessing your generated classes.

Then it automagically goes back to being able to reference the right types again…

Lame :(

Share

Integrating Pex With Team Foundation Server

Oh la la! Combining Pex test with Team Foundation Server is indeed a powerful combination, and boy is it easy as hell to setup. The end state of this type of integration is pretty straightforward, we wanted to repeatedly provision Pex tests when executing build events in TFS.

This is a pretty awesome setup because parameterized units tests can be explicitly created, then the Pex tests can provide all the good stuff on build for the test running. Furthermore, we can even have full coverage by allowing Pex to create some of the tests that we space.

The changes required are minimal since in the build events it simply requires wiring some commands. Assuming that the tests are *already* created, you can use the MSBuild Project AssemblyName property or declaratively provide the assembly wiring the following command into your build event:

[code]
pex.exe .dll
[/code]

This is all fine and good, but what is you want complete coverage to ensure your tests exist? Luckily, Pex provides the /erm:wizard switch to generate the parameterized unit tests, and we can call our explicit tests using the /sa switch. This looks like the following:

[code]
pex.exe /erm:wizard test.dll /sa:test.tests.dll
[/code]

Viola! Getting so easy it’s going to be hard justifying not having Unit Tests!

Share