Word 2007 Content Placeholders and the Word 2003 plugin for Office 2007

It's to Microsofts credit that they have provided a plugin for Word 2003 that will allow the reading of a Word 2007 .docx file. And it (mostly) works. If however you need to use some of the new features office 2007 - such as the content placeholders you'll find that the content inside them won't render. I'm hoping they'll fix this soon.

If you haven't checked out content placeholders you can file many articles on it, but here is a reasonable overview on content placeholders in Office 2007. It's a great new feature, but as usual not without it's limitations, such as handling repeating sub groups, and the definate need of a configuration editor that others outside the Office team have had to write.

Forms Authentication in MOSS 2007 / WSS 3.0 - Not all that...

One of the great heralded features of the latest SharePoint release has been the integration of forms authentication Membership/role providers from ASP.NET 2.0, essentially allowing seamless integration of any list of users from any datasource to Authenticate to SharePoint/MOSS - the default one being through aspnetdb. I don't want to cover that, as it's been more than detailed elsewhere. I just thought I'd reveal a few of the important gotchas that you'll experience after getting it working.

• You cannot create lists from excel spreadsheets, or make any use of a DataSheet mode for lists
• You cannot (easily) publish an InfoPath form to a form library. (Our workaround was a second web application set to basic auth)
• Give up hope of seeing any SharePoint plugins in Office documents
• You won't get a "Edit in Word" style option for office documents of the context menus
• As with all forms authentication you won't be able to download files directly using code means like WebClient() in C#
• RSS Readers won't be able to get past forms authentication to subscribe
• I'm sure there are other features similar that won't work

I think all this is a bit of a shame, as all the user creation user controls etc are provided for you, and it's quicker than Account Creation Mode for WSS 3.0, and works in MOSS 2007. It may still be the solution for you in a non-active directory world, but be very sure that the features that you are losing can afford to be lost

Errors Switching to Edit Site Mode in CMS 2002

Apologies for using images to display code snippets. Blogger is not quite there yet, and strangely it conplains when you add a script tag in your blog post ;)

Up until now whenever a colleague or client tells me that they can't switch to "edit site mode" in CMS 2002 I've always immediately answered it with - "you've forgotten to and the CMS sub directory to your web application. And until now I've been 100% right. Today I found a new possibility. So, to recap here are both known solutions to the "switch to edit site mode" error, normally aparrent if the URL looks like the following

http://mysite/page.htm#

it's the trailing # that idicates the problem

Solution 1 - No id attribute on your form

CMS 2002 generates javascript (which I always process out of public view pages - why add 15K unusuable inaccessible overhead to every public view of a page) to handle the switching of its menu mode, one of which usually looks like this:



You'll find it just under the viewstate tag. If you somehow don't have an id attribute on your form however ie:



instead of the expected



Then you'll find that the CMS javascript generated is


..and this will give you an javascript error in the console when you try to switch mode. Incidentally if you use master pages you will find that the javascript generated is different. Having talked through the newsgroups to those that know (ie Stefan Gossner) - it appears that this may be a slightly undocumented "feature" of CMS2002 for VS2005. Worth paying attention to if you like to clean up unecessary scripts like I do.

Solution 2 - Missing CMS virtual directory in IIS

This is by far the most common, and often happens if you deploy your web app manually, mostly AFTER enabling a site for CMS in the SCA

Both your web application and the MCMS application underneath your website should contain a virtual directory called CMS. If you do not and you experience the problem mentioned you can take the steps below. I say only if, because IIS 5 has a habit of hiding the virtual directory in the IIS MMC plugin. To be certain, use IIS metabase Edit to see the real story.

To add the directory:

1. In IIS, underneath your web application, create a new virtual directory called CMS
2. point it at c:\program files\microsoft content management server\server\IIS_CMS
3. ensure that only read access is ticked. Do not tick run scripts
4. complete the wizard
5. go back into the properties of the virtual directory and change the execute permissions to scripts only

refreshing your web page should not allow you to switch between site modes. It's a strange quirk, but enabling the run scripts option during the wizard itself always leads to failure (certainly on IIS 5). I have no idea why, but it to some finding out. Fortunately this is the default selection in IIS 6, so you are less likely to accidently set it.

A Simple Enforced Source Control for SQL using Team Foundation

One of the major issues in rolling product development is ensuring that you can reproduce a client version of software at the office. With a mature source control system such as Team Foundation this is not too much of an issue with code - at worst you go back through the changesets until you find the one that matches. But what about the database that this code relies on? How best to ensure that you have the same ER structure as the version of code? There are many methods, most of which are very hard to enforce (though I hope that the "Database" version of Visual Studio Team may sort this out).

Enter Team Foundation Policies. If you've not looked at this cool feature you should. TF ships with many cool policies - including; "must associate check in with work items", "must pass the following code tests" (using the testing features of VS Developer), "must pass a list of best practice polices", and the invaluable "must build before checkin".

That's not the extent of the power of policies. You can write your own - effectively you can do any action you want on checkin. If made use of this to force a copy of the entire database script to be placed on disk as check in occurs. All it takes is a little bit of .net code, a registry entry or two and use of a handy scripting tool.

More information on the creation of policies can be found at http://blogs.vertigosoftware.com/teamsystem/archive/2006/02/27/2302.aspx

Step 1 - Scripting the database

There is a handy tool shipped with SQL 2000, which sadly absent in SQL 2005 called "scptxfr.exe". It lies in the MSSQL\Upgrade folder under the normal program files root. This tool can quite easily script an entire database, a feature that seems harder to find in SQL 2005. I'm sure you can probably achieve the same affect with SMO, but fortunately the scptxfr tool works across both versions. Using the command like:

scptxfr /s DatabaseServer /d DatabaseName /P SAPassword /f file:////tfs-01/TFSSQLSynchRoot/$TeamProject$/$ChangeSet$.sql

will fire the whole thing out to disk, saved for posterity. You'll notice that my file path includes $ signs. That isn't actually a valid file path, but markers that I replace in the code shown below.

Step 2 - Write your own policy

Create a new library dll , and include
Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.VersionControl.Client
as references to the project

create a new class, inheriting from Microsoft.TeamFoundation.VersionControl.Client.PolicyBase

Most of the methods feedback information used to describe in the visual studio GUI the name and purpose of the policy, the error messages to be returned etc. The crux of the class is the Evaluate() method. My code works by launching another exe, by making use of System.Diagnostics.Process

public override PolicyFailure[] Evaluate()
{
int iLastChangeSet = PendingCheckin.PendingChanges.Workspace.VersionControlServer.GetLatestChangesetId();
System.Diagnostics.Process process1 = new System.Diagnostics.Process();
process1.EnableRaisingEvents = false;
process1.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
process1.StartInfo.FileName = "CMD.exe";

StreamReader oReader = null;
try
{
oReader = new StreamReader(File.Open(@"C:\Program Files\TFS Extended Policies\sqlsynchconfiguration.txt", FileMode.Open));
string sTeamProject = this.PendingCheckin.PendingChanges.AffectedTeamProjectPaths[0].Replace("$/", "");
string sConfig = oReader.ReadLine().Replace("$ChangeSet$", (iLastChangeSet + 1).ToString()).Replace("$TeamProject$",sTeamProject);

MessageBox.Show("Synchronising SQL DB changes using:" + Environment.NewLine + sConfig + "" + Environment.NewLine + "last change set: " + iLastChangeSet + Environment.NewLine + sTeamProject);
oReader.Close();
process1.StartInfo.Arguments = sConfig;
process1.Start();
//process1.WaitForExit();
//process1.Close();
}
catch(Exception err)
{
MessageBox.Show("SQL Synchronisation failed. Check that the configured scripting command exists, and that you have permission to access to the file shares." + Environment.NewLine + err.Message);
}

if (false)
{
return new PolicyFailure[]
{
new PolicyFailure("Please provide sql details", this),
};
}
else
{
return new PolicyFailure[0];
}
}

Note that you could wait for the scptfxr exe to complete by uncommenting

//process1.WaitForExit();
//process1.Close();

but as this operation could delay the checkin by a reasonable amount of time I elected not to. Build your assembly and all your coding is done!

To get this all working on all users machines I found that I needed the new assembly, scptfxr.exe and several of its required dlls in the same folder. The bute force approach...but if you include all the files below it should work with least hassle

Step 3 - Add your policy to a Team Foundation Projct

In order to add your policy to the available list each machine that runs the policy will need to add registry settings

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies]"SQLDatabaseSynchPolicy"="c:\\test\\SqlSynchPolicy.dll"

Then, in team explorer, go to
My Project -> Source Control -> Check-in Policy

and add the new policy from the available list. Note that the name of the policy will depend on the Type property you completed in your class.

Your policy is now among those enforced!