DomainProjectPicker setting UICredentialsProvider

I was playing with the TFS API for a couple of small applications I am working on. I have two different servers that I was testing the apps on. The first is the standard set up under a domain, and the second was a server with no domain configured for SSL.

Things worked great under the first scenario, however the second scenario failed with invalid credentials. So I did a quick google search and came upon several excellent posts about setting the UICredentialsProvider in the constructor of the TeamFoundationServer object. Easy right, except the DomainProjectPicker doesn't have one of those (a constructor or any public Property/Method to set the UICrendentialProvider). Not a problem until you try to get the list of Projects:

new DomainProjectPicker(DomainProjectPickerMode.AllowProjectSelect DomainProjectPickerMode.AllowMultiSelect)

Wham you get hit with credentials error again, so if you don't need to pick the projects initially you're good to use the TeamFoundationServer constructor to handle the login dialog.

So with no visible way to set the ICredentialsProvider on the picker I decided I would try some of my Microsoft connections. Hayer Casey forwarded me an email thread with the same question. The answer requires reflection as the picker does have a property to set the CredentialsProvider, but it is marked 'internal'.

We need to get the list of registered servers, and then add the UICredentialProvider to each one (I chose to use a separate method call to handle the reflection) ...

Enclosing method...

foreach(var registeredServer in RegisteredServers.GetServers())
{
SetCredentialProvider(registeredServer);
}

...Enclosing method

Add the UICredentialsProvider to all registered servers.

private static void SetCredentialProvider(TeamFoundationServer server)
{
var propertyInfo = server.GetType().GetProperty("CredentialsProvider",
BindingFlags.Public BindingFlags.NonPublic BindingFlags.Instance);

propertyInfo.SetValue(server, new UICredentialsProvider(), null);
}

After completing this everything worked beautifully. When asked if this was going to be fixed for 2010

WRT the deprecation of RegisteredServers and DomainProjectPicker, what can we expect? What will the replacements look like?

The replacement API will be similar with added functionality for dev10 servers.

Yeah, this is a little late as it will be replaced with the next release but maybe it might help somebody else who is still playing with the current API.

Xceed DataGrid

"I just registered for the free Xceed DataGrid for WPF, and there’s only 5 days left to do it. http://xceed.com/freegrid"

One of the best and easiest datagrids I have worked with.

Automated ClickOnce issues

After struggling with a ClickOnce issue on an Automated build that I inherited I came across several issues that helped me solve the problem.

Here's a brief recap:

A request was submitted to create a new ClickOnce deployment for a small application used to deploy java via ClickOnce.

I copied the ClickOnce automation scripts from another working project and adjusted the files to include in the process.

We then ran the build and everything ran beautifully until we launched the application. At which time the installation failed with the Error: <entryPoint> is invalid. That started a mad witch hunt that caused me to first look into the scripts which then led to investigating the certs, which finally led back to the Application manifest signing task (Exec -> mage.exe). Unfortunately I could have avoided many of the other issues if I had found the question under Application manifest signing: below sooner.

I have included in this post the issues and resolutions below more as a future reference if I run into them again. Most likely this post will be updated as I find more ClickOnce issues (currently not a big fan).

Certificate creation:

makecert -r -pe -a sha1 -n "CN=yourcompany" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.3 -ss My

The -b and -e option specify the time period when certificate is valid. The -eku option specifies the certificate is intended for code signing. I've also added -a sha1 option to set the same algorithm that VS uses (but I don't think it matters).

It's important to use the -pe option which allows to export the private key from the certificate. To do this use CertMgr (another tool from Framework SDK). The new certificate will be installed in your personal store. Select it and click on the Export button. Click Next on the first page, and on the second select to export the private key. On the next one you can select some additional options; if not sure just leave on default. After that you will be asked to type password for the file; can be left blank. On the last one specify the file name and location. Finish the wizard and you should get a .pfx file that can be used in VS or imported on user machines.

<http://geekswithblogs.net/kobush/archive/2005/05/30/41068.aspx>

Certificate use by ClickOnce application:

Some times it works to just build the application on the machine that needs the certificate (haven't entirely figured out why this only works on some certificates and not all). In this case the project just needs to sign the manifest and use a file stored with the project. The first build will prompt for the certificate password, but the subsequent builds will not.

However, if the project continually asks for a password during the build, then you will need to install the certificate and reference it from the store. Then any machine that will build the project just need have the certificate in the store.

Application manifest:

Error: <entryPoint> is invalid

Check: Validate that the processor attribute of the assemblyIdentity element is the same as the

entryPoint processor attribute.

http://social.msdn.microsoft.com/forums/en-US/winformssetup/thread/e13aee6f-7545-4c0c-9f64-14af94aa2a5c/

Source Control Directory Structure

Here is a directory structure that I use for all of my projects. I figured, if nothing else, it would be a great discussion point.

Directory Structure

The directory
structure for a project should be set up in the suggested manner:




Definitions:

1. Releaseable Project - A project that has its own
   release schedule. All folders
   underneath the project/trunk folder should be on the same release
   schedule. If an item is on a different
   release schedule it should be analyzed for a possible move to its own
   project folder.

This accomplishes
several tasks:

1. When the Trunk is branched not only is the source
   branched, but all items related to the creation of the application will
   be branched as well.
2. Directory clutter that often
   results when there are several groups trying to use the same space will
   be reduced
1. Build files will be placed in the build directory
2. Custom or external tools
   will be placed in the tools directory
3. Documentation can have its
   own space
3. The extra directories (Database, Tools, Documentation,
   etc…) are optional and only needed if the project requires them. Build and Src should be required
   directories.

Build Directory

The build directory
is used by the build manager to keep the source directory from being
cluttered. This will allow build
managers their own 'space'.

Src Directory

The Source
directory (src) contains all items related to the applications source
code. This is relatively loosely
defined as it can contain custom tool code that may not be shipped with the
application, documentation, etc… This
decision is to be made by the development team.