These properties are quite important, as they tell us what we need to know to get the correct TermSet for our field.

If you look in the properties you’ll see:

• SspId – The ID of the Managed Metadata Service containing the TermSet for this field. This ID is also sometimes referred to as the TermStore ID.
• TermSetId - The ID of the TermSet for this field.

With this information we can use the GetTermSets method of the TaxonomyClientService. (The code below is based on “Working with the Managed Metadata Service Remotely” by Virtosoft.

string clientTimestamps = string.Format("<timeStamp>{0}</timeStamp>", clientTime);
string clientVersion = "<version>1</version>";
string termStoreIds = string.Format("<termStoreId>{0}</termStoreId>", termStoreId.ToString("D"));
string termSetIds = string.Format("<termSetId>{0}</termSetId>", termSetId.ToString("D"));
string serverTermSetTimestampXml;
string result = _wssTax.GetTermSets(termStoreIds, termSetIds, 1033, clientTimestamps, clientVersion, out serverTermSetTimestampXml);

So, there are a lot of parameters to that call – I’ll deal with them in part 3, which will be about caching. You’ll note that you can retrieve multiple termsets from multiple termstores – I think. I’ve not tried it (I’d rather make several calls and keep things simple).

Let’s look on what we get back from the service:

Nice. So much for XML being human readable. So what’s this about?

First off, notice that there’s no nesting. All Terms are returned in a flat list:

The elements of the terms are:

• TS – Term Set
• T – The Term.
• LS – Label Set
• TL – Term Label. Potentially a Term can have several labels, for different Languages
• TMS – More Term Set Information
• TM – Term Information
• TD – Term Description

The attributes are all numbered, which is really helpful. What do they mean?

• a9 – Term ID or TermSet ID
• a11 – TermSet Description
• a12 – Term Set Name the Term belongs to
• a16 – Submission Policy (Is the termset open or closed)
• a17 – Term is Enabled (can be used for tagging)
• a21 – (boolean) False if the term is not deprecated
• a24 – Term Set ID the Term belongs to
• a25 – Parent Term ID
• a31 – (boolean) Not sure, I think this is true if it’s the default term label?
• a32 – Label Text
• a40 – Parent Term Name
• a45 – A semicolon separated list of the IDs of the Terms to the current term’s location in the taxonomy. (I.e. its path!)
• a61 – (integer) ?
• a67 – ?
• a68 – TermSet contact email

Nice and simple, eh?

Still, using this information you can determine the structure of the termset. In Part 3, we’ll look at caching.

This has proved particularly bloody hard.

To start with, let’s look at what fields I needed to deal with. When you add a Taxonomy column to a list, it actually adds two columns.

The first is your ‘display’ column, and this can actually be one of two types – TaxonomyFieldType or TaxonomyFieldTypeMulti. As the name suggests, these are for single select and multi-select respectively.

The second column is a hidden field of the ‘Notes’ type. This stores your actual data, it appears, though quite why still mystifies me a bit (more on that later).

Anyway, there are two columns. As you can see from the screenshots above, the Taxonomy column contains an array of customisation properties.

So, how are these two fields related? Well, not using the ‘RelatedField’ attribute (too obvious), and when I did a bit of a search I kept finding blog posts saying that I would have one field with the name I gave it, and another field with the same number but ending with an additional “TaxHTField0″ text. This was not the behaviour that I saw; it might have changed in a service pack.

On my system, the second (Notes) field seemed to have a GUID-like name. It looked mostly hexidecimal, but was often prefixed by a couple of non-hex characters. At first I thought that this might be the reference between the two fields.

However, the relationship is in fact one of the array of properties on the field:

The TextField property contains the ID of the Notes Field. Great, that’s nice and simple.

So, in summary, the relationship between the TaxonomyField and Notes field is held in the TextField property in the array of properties of the TaxonomyField. The value is the ID of the Notes field. You can get this information a variety of ways, but I used the GetListContentType method of the Lists web service.

In Part 2 we’ll look at getting and interpreting the TermSet for our field.

They’ve using the Telerik RadEditor web part quite a lot, so we had to keep that working. We’ve put in Assembly Binding Redirects using an SPWebConfigModification (more on that in a later post).

However, we also needed to put in the SafeControl entry for the old assembly. Maurice Prather discusses this here. The short of it is:

What happens to your Web Part when it’s redirected to version Y?

1. On first render of a redirected Web Part instance (this is a KEY thing to remember), if the SafeControl for version X exists, an attempt to load the Web Part is made.
2. The .NET framework kicks in and redirect to version Y is successfully made.
3. SharePoint notices that the Web Part type guid (nothing we the Web Part developers can explicitly control) has changed and saves the new type id back to the database.
4. From that point forward, the next time the Web Part is loaded, the call is made directly for version Y.

Take a look at step #3.  This is key.  The database actually contains a reference to your web part in a form of a guid.  The guid is a calculated value that allows the SafeMode parser to rapidly associate the serialized form with a live class type.  The important thing to remember is that this reference lives on a per-page reference (i.e. page ABC has reference to web part types M, Q, V).

Why is this important?  Until all instances of Web Part version X have been rendered, you cannot remove the SafeControl reference to version X unless you want bindingRedirect to fail.

Okay, fine. That makes sense, and I don’t have a problem marking a web part that we’ve been using for ages as safe, even if it will ultimately be updated in all instances by the redirection.

So, I put a new SafeControl entry into on the SharePoint Project Items of my solution.

(Please note: below I’ve used an assembly called ‘MyAssembly’. I’ve changed the name from the real assembly ‘cos I’m not sure I’m allowed to talk about it. But I’m showing the behaviour I saw).

This was then included in my Manifest:

However, when I went and checked the web.config I saw:

WTF? As best as I can determine, the assembly information in my SafeControls entry in my solution’s manifest has been ignored. The entry in the manifest lives within a particular Assembly element, so presumably SharePoint itself chooses to read the information from the assembly, rather than the manifest! (Why ask for the information then?)

Consequently, I found that the best option I had was to write an SPWebConfigModification to add my Safe Control entry. And that worked nicely.

Conclusion: If your WSP doesn’t contain the assembly you’re trying to create a SafeControl entry for, you’ll probably need to use an SPWebConfigModification. That seems a shame, given that Visual Studio 2010 appears to let you create other Safe Control entries, and puts them into the manifest correctly.

Found the answer on Stack Overflow:

So it turns out that Outlook doesn’t load the CLR on startup (it must be loaded shortly thereafter when it becomes necessary), which apparently confuses the VS debugger and causes it to only debug native code. To force it to load the CLR immediately, create an OUTLOOK.EXE.config file in the same folder with:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/>  </startup></configuration>

which is from this blog post. Then, even when VS starts attached, it will debug CLR code

Yes we can. Richard Fennell has a concise and simple description of how to do it. It’s best to read that, but in case that site goes down, the short of it is – use InvokeProcess to run SPDisposeCheck, and it’ll return a value that is the number of errors/warnings it finds. I find that that’s enough to choose whether to write a warning to the output of the build, and I don’t then parse and write the individual warnings into the build. These should be captured by the build log, and they’re pretty obvious, so it doesn’t seem worth the hassle. You could do it if you really wanted to.

Don’t forget you can use attributes to prevent false positives – though I still have issues with anonymous delegates that are false positives (how do you add the attributes?), and that’s what’s causing the two warnings above.

The Publishing Infrastructure converts the editing experience for the top navigation from this:

Into this:

And allows all sorts of things, like showing links to particular Audiences, showing subsites, etc.. It’s pretty useful.

Unfortunately, the Publishing Infrastructure does a lot more than change the navigation. It will create libraries for styles, and add columns, content types, page layouts, XSL files, and all sorts of stuff. That’s quite a lot of extra weight and complexity just for the navigation.

However, when you turn on the Publishing Infrastructure feature it actually turns on a number of hidden features. Could there be one that just deals with the navigation?

Well, it turns out that yes, there is. It’s called the “Navigation” feature in the FEATURES folder. Looking inside it, you can see that all it does is add and hide some custom actions (related to the link to the Publishing Navigation Administration page), and use some delegate controls to replace the navigation data sources.

So, can we activate just this feature? Not through the user interface – it’s hidden. But through STSADM or powershell, then yes. The Feature’s name is Navigation, and it’s GUID is: 89E0306D-453B-4ec5-8D68-42067CDBF98E

stsadm -o activatefeature -name navigation -url <url to site>

I’ve not tested it extensively, but this seems to work okay from the bit of testing I have done. I couldn’t help but notice that the ‘Pages’ checkboxes on some of the settings were also greyed out:

To me, this suggests that someone actually designed this navigation to work without the rest of the Publishing Infrastructure, so hopefully, it should be okay by itself.

I had been given a build definition that had a build process – a Workflow Foundation workflow – that I wanted to alter. The problem was that while I had the XAML file for that workflow, and the DLL that defined some custom code activities that the process used, I didn’t have a full Visual Studio project for it. No problem, I thought, I’ll just open the XAML up in Visual Studio and edit it.

Wrong.

While I could open the XAML file, it was not displayed such that I could edit it, and the custom code activities showed up as errors. What I really needed to be able to do was make this a proper Visual Studio project to edit. But how? Well…

• Create a new Visual Studio Project. Use the Workflow > Activity Library template.
• Remove the XAML file that is automatically added to the new project. You can delete it.
• Add your existing XAML file.
• Add references to any additional assemblies that your project uses.

Presto – I could now edit my workflow within Visual Studio. I checked this into TFS (to sit alongside the code for my project) and changed my build definition to use my newly edited process.

1. Check that the function exists.
2. Check that the function is named correctly.
3. Make sure that you’re not using “this” in the call to createDelegate, as detailed here.
   • Right: Function.createDelegate(this, onSuccessMethod)
   • Wrong: Function.createDelegate(this, this.onSuccessMethod)

   I don’t know why this difference should cause this error, but I’ve proved it true.

If you know of other causes of this error, let me know, I’ll add it to the list. I love the experience of debugging JavaScript…

It turns out that this is due to the app pool supporting 32 bit applications! Change the setting in IIS (App Pool > Advanced Settings > Enable 32 Bit applications should be false)

Just a reminder to myself…

Well, the solution was to add the app pool account to the ‘Performance Log Users’ group in AD. You find it under BUILTIN. Reset ISS. Voila!

This is a shame, as I like that you can see a description about the time job in Central Admin:

The solution – strange as it seems, override the Description property in your new timer job.

I pointed out to them that there are good reasons to consider having the Search Center separated from the rest of your content. I’d even suggest a separate Site Collection (or even Web App) if using the Enterprise Search Center (which uses the publishing features, and you might not want them turned on in your existing site collection). However, in their instances they didn’t really need all that, and really did just want a simple search center in the Site Collection. For example, a departmental site collection might want its own search center and search experience.

So, I set forth to fix this dire state of affairs for them.Looking at the above page I noted that the page seemed to be using a different master page, and that the horizontal scroll bar was shown – why is unclear, but it doesn’t look good. Looking into the master page side of things in SharePoint Designer, I found that the master page being used was ‘Minimal.master’. I decided to change this to ‘V4.master’, and this is what I got:

Excellent, we’ve got our navigation controls back, and the horizontal scroll has gone. Sadly, so has our search box. I knew that from SharePoint 2007 that the idiot who had designed this page had put the search box into the PlaceHolderTitleBreadcrumb placeholder on the master page (what was wrong with the main content area?). So, I assumed that the same was happening here, which turned out to be true:

So, I started changing the page by putting the search box into the main content area of the page. I also added CSS to all the pages (default, results and advance search) to hide the left navigation. Next, each of these pages was adding it’s own ribbon and site actions controls to the top of the page, so I removed these too. And so I had the following as pages:

Note the top navigation tabs, and the “up a level” control with breadcrumbs. And here is the results page:

You can download the site template for this (for free!) and use it yourself.

EDIT: I gather that it isn’t actually available for download yet. Apparently Sales want to release it and a number of other items simultaneously. It should be available in a week or so.

Alternatively, I did a video about it, too.

To install:

• Upload the solution to the solution gallery of your site
• Activate the solution
• Create a site using it.
• Go into the Site Settings > Top link bar and click “Use links from Parent”
• On both the Search Page and Search Results pages, edit the page and modify the Search Box web parts. In the Miscellanous section, fill in the correct Advanced Search Page URL
• On the Advanced Search Page, edit the page and modify the Advanced Search Web Part. In the Miscellaneous section, fill in the correct Results URL

(Sorry about the last steps – for some reason this is determined to create the site breaking inheritance of navigation, and it’s too much effort to try to figure out why. And changing the URLs in those web parts seemed like too much effort, too. You’re not going to be creating hundreds of these, right?)

• Constants do not get obfuscated. Use static readonly variables in their place if the constant contains sensitive information.
• Run Reflector (or reflection tool of your choice) against your assembly after obfuscation, to check what is visible. Then go back and make the bits you accidentally left public internal or private.
• Make as many classes and methods as you can Internal
• Do read the instructions on the attributes you can apply to control obfuscation.
• Do use Pruning if you want to remove parameter names for methods. That can leak a lot of information about what a class is doing.

Obfuscation prevents analysis of code using reflection. Code analysis uses reflection to analyse code. There is, therefore, a bit of a problem if you try to use both during your build process, either within Visual Studio, or on a build server. Code analysis would often crash:

… and if you looked in the Code Analysis logs, you’d see it was FXCop failing:

Typically, the errors are things like “Index was outside the bounds of the array”.

Therefore, if you have a check-in policy that demands that code analysis has been run, you can’t run obfuscation within your Visual Studio builds. There is a risk that the obfuscated assembly will cause Code Analysis to crash, and if Code Analysis doesn’t complete, you won’t be able to check-in your code. The example code in my previous post shows how to set up a condition so that you don’t obfuscate locally built assembly. That way, you can at least check your code in, and during development I’m not too concerned about the assembly being obfuscated. In fact, I’d rather it wasn’t, so that I could debug it more easily.

However, you’ve still got the problem of builds on the build server trying to run code analysis on an obfuscated assembly. They will still generate the same error, and you really do have to obfuscate at the point. There are two solutions that I found:

1. Turn off code analysis within the build process. Edit your build definition, go to the Process tab, and set Code Analysis to “Never”
   
   You will not then see code analysis warnings/errors within TFS. However, developers will still have to run code analysis before check-in, so they should still see any warnings/errors at that time.
2. Modify the .csproj file. You could duplicate the ProjectGroup for Release in the .csproj file, add conditions to them so one runs inside Visual Studio and the other outside (i.e. on build server), and finally set the Code Analysis to not run on the build server:
   
   This works – I tried it – but I don’t like modifying the .csproj file if I can avoid it.

That second option feels a bit complicated to me, so I prefer the first option. To us, I think it’s more important to know that the Code Analysis warnings were presented to the developer than particularly worrying about them being captured in TFS too.

SmartAssembly’s manual describes how to include the SmartAssembly project file (.saproj) into your build process. This is basically simple:

1. Add the .saproj file to your Visual Studio Project
2.  Right click on your project within Solution Explorer and select ‘Unload Project’
3. Right click on your project within Solution Explorer and select ‘Edit projectname.csproj’
4.  Scroll down to the bottom of the file – we now need to add some additional lines to the file to tigger obfuscation during the build process.
   Add the following lines to the bottom of the file, just before </Project>.  You will need to modify the .saproj filename accordingly:

<UsingTask TaskName="SmartAssembly.MSBuild.Tasks.Build" AssemblyName="SmartAssembly.MSBuild.Tasks, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7f465a1c156d4d57" />
 <Target Name="AfterCompile" Condition="'$(Configuration)' == 'Release'">
 <SmartAssembly.MSBuild.Tasks.Build ProjectFile="$(ProjectDir)HelloWorld.saproj" OverwriteAssembly="True" />
 </Target>

This is what worked for my colleagues – but not for my projects. I kept receiving an error:

SmartAssembly build failed: The system cannot find the file specified (Exception from HRESULT: 0×80070002)

There wasn’t much clue what that meant. Looking on the Redgate forums, it seems like I wasn’t the first person with this issue. The suggestion seemed to be to run from the command line, rather than using Redgate’s MSBuild task. That seems a shame, but I tried it:

<Target Name="AfterCompile" Condition="'$(Configuration)' == 'Release' AND '$(BuildingInsideVisualStudio)' != 'true'">
<Exec Command="&quot;C:\Program Files\Red Gate\SmartAssembly 6\SmartAssembly.com&quot; &quot;$(ProjectDir)HelloWorld.saproj&quot; /output=$self" />
</Target>

This seemed to work nicely. I know that the command has a fixed path in it, but this command should only be run on the build server (hence the bit about $(BuildingInsideVisualStudio) ). More on why I did that in my next post.

Well, SharePoint 2010 and Visual Studio 2010 followed later, and Microsoft introduced much better tooling of their own. However, we’ve still got a lot of code being packaged by WSPBuilder, and we didn’t want to have to refactor all those projects just to package them for 2010.

Fortunately, Carsten Keutmann wrote a 2010 version (still in ‘BETA’, but it works fine). It offers many of the same extensions to Visual Studio as the previous version did.

However, I recently had to automate (in Team Foundation Server 2010) the build of one of our WSPBuilder based solutions, and that’s where things got more interesting…

First off, let’s be clear, there are a couple of different issues here:

• What are the differences between a 2007 and a 2010 solution package?
• Can we integrate WSPBuilder into our build process in TFS?

I started by looking at the first question. I knew that my project – a little web part to display search results from Twitter – should work in 2010 without modification. So, on a SP2007 server, I packaged it using the WSPBuilder for 2007. I then installed the WSPBuilder Extensions for 2010 – these should still work for SP2007/VS2008 – and repackaged it. I compared the WSPs – and found that the manifests were different.

Ok, no problems there – a few bits in a different order, and the manifest shows compatibility to be 2007 and 2010. That’s cool.

Then on a SP2010 server, I took the same code and packaged it, and I then compared the two WSPs. There were different. The manifests were different:

Okay – so the solution tag is different (it has an extra attribute), and the line showing compatibility now shows SharePoint 2010 only as being compatible. I hadn’t changed my code at all, so the difference must be down to the server that it’s running on. I’d a hunch that if WSPBuilder was being run on a SP2010 server it would default to packaging for SharePoint 2010 only. However, WSPBuilder is pretty well thought out in the options you can feed in, so I figured that there must be an argument that I could feed in to tell it to package for 2007 or 2010 when being run on SharePoint 2010 server.

I was wrong. Eventually, I came across a series about “Porting a SharePoint 2007 WSPBuilder solution to SharePoint 2010” by Muhimbi where they said:

Note that if you want to use WSPBuilder to build a hybrid SharePoint 2007 / 2010 solution or a solution that just targets SharePoint 2007 then you must perform the build on a machine that runs SharePoint 2007. The latest version of WSPBuilder checks which version of SharePoint is installed on the build machine and adds SharePoint 2010 specific elements to the generated WSP file, causing deployments to fail in SharePoint 2007 environments.

Well, that’s what I was seeing. Just in case I checked the source on Codeplex. In the Keutmann.SharePoint.WSPBuilder.Library.ManifestConfig class, the choice between a SP2007 or SP2010 manifest seems to come from the registry – specifically, from checking the subkeys of SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\ . A “12″ means SP2007, and a “14″ means SP2010. There doesn’t seem to be an argument to pass in, and this means that if your build server has SP2010 installed on it – even if it isn’t configured – then all WSPs built on it will only be SP2010 compatible. Yuck.

It then occurred to me, could I install both the 2007 and 2010 versions of WSPBuilder? In short, no, the installer wouldn’t let me.

Okay, so, another thought – what if you don’t have SharePoint on the build server at all? Well, you’d have to put any assemblies you want to reference (like Microsoft.SharePoint.dll) into your TFS project, and reference them rather than the ones in 12 or 14 hive, but that’s not a problem. However, what would WSPBuilder do? Well, a quick test shows that it might well build it for SP2007 – and so be compatible with 2010 – but I’ve not really looked into it that far. It could be worth investigation; I gave up as I was unlikely to be allowed to remove SharePoint 2010 from our build server. For now, if I want automated builds to work for SharePoint 2007, we’ll need a second build server.

Phew! All of which led me around to the second question – how to integrate the packaging with the build server. I found some good posts about this by Brian Farnhill, but they were for Team Foundation Server 2008. His approach was to use a post-build event to run a little script, and in that script he a) copies the DLL to the correct location, and b) runs WSPBuilder. “Excellent”, I thought. It didn’t work.

It seems that the problem lies in the script itself; $(IsDesktopBuild) wasn’t returned what one would expect for Visual Studio 2010. So, instead, I came up with the following script:

if '$(BuildingInsideVisualStudio)' == 'true' GOTO LocalBuild
:TfsBuild
MD "$(ProjectDir)bin\$(ConfigurationName)"
COPY "$(TargetDir)*.dll" "$(ProjectDir)bin\$(ConfigurationName)"
CD $(ProjectDir)
"C:\Program Files (x86)\WSPTools\WSPBuilderExtensions\WSPBuilder.exe"
MD "$(TargetDir)WSPs"
MOVE "$(ProjectDir)\*.wsp" "$(TargetDir)\WSPs"
GOTO Finish
:LocalBuild
"C:\Program Files (x86)\WSPTools\WSPBuilderExtensions\WSPBuilder.exe" -DeploymentTarget GAC
:Finish

Excellent. $(BuildingInsideVisualStudio) does behave properly. I did find one quirk with this now, though – my solution was being packaged on a local build as if the assembly was being deployed to the BIN. Sadly, I needed it in the GAC (and this is how TFS was packaging it), and hence the argument to set the DeploymentTarget that you can see above.

Conclusions

Well, I now had my build working. However, the packaged solution was only compatible with SharePoint 2010. As it turned out, this was acceptable (there were other changes that we had to make for SP2010). If we wanted to package the 2007 version for 2007 deployment, though, we would need another build server as there doesn’t seem to be a way of telling WSPBuilder to ignore the fact that it’s on a SharePoint 2010 server.

First, though, let’s look at the limitations of the SPDiagnosticsServiceBase.

The first limitation is that although you can log with a call to SPDiagnosticsService.Local.WriteTrace(), you kind of run into an immediate problem – what’s the bloody SPDiagnosticsCategory that you want to use?

Well, like most people, I guess I tried creating a new SPDiagnosticsCategory object, and handing that into the function. Sadly, though, the logs come through empty, as Jurgen Baurle mentions.

The problem is that the logging categories are used to control the levels of logging you set in the Central Administration > Monitoring pages. In fact, there are two bits to this – a diagnostics service offers a number of SPDiagnosticsAreas, and those areas have a number of SPDiagnosticsCategories.

Worse, compared to 2007, at least, is that you can no longer ‘register’ and ‘unregister’ diagnostics categories from this central administration section. Essentially, your categories are build in – they’re either there … or they aren’t. This is an annoyance, as it means that I can’t write a single Logging class and use it in all my projects. Instead, you have to create an entire diagnostics service, based on the SPDiagnosticsServiceBase class.

Whatever solution I produced, I wanted it to be easy to modify and reuse for other projects that might demand a different diagnostics area or classes. You might notice, I used the singular – “area” there. That was deliberate. I figure, if I need more that one area, it should be simple to provide another entire diagnostics service.

Now, quite a lot of people have produced examples (see below), with discussion of their code, so I won’t go into that so much. What I’ve not seem much of, though, it the use of an enumeration for the call to the logging class. Often, people seem to pass strings to define the logging category. What if it’s invalid? What if there is a typo? Basically, I hate magic strings, so I used an enumeration to define my logging categories for my service:

public enum MyLoggerCategory
 {
 TimerJob = 1,
 FeatureReceiver = 10,
 EventHandler = 20,
 Webpart = 30,
 General = 40
 }

And the method that returns my Diagnostics Area and Categories uses this enumeration to define the categories:

protected override IEnumerable<SPDiagnosticsArea> ProvideAreas()
 {
 List<SPDiagnosticsArea> areas = new List<SPDiagnosticsArea>();
 List<SPDiagnosticsCategory> categories = new List<SPDiagnosticsCategory>();

 foreach (string catName in Enum.GetNames(typeof(MyLoggerCategory)))
 {
 uint catId = (uint)(int)Enum.Parse(typeof(MyLoggerCategory), catName);
 categories.Add(new SPDiagnosticsCategory(catName, TraceSeverity.Medium, EventSeverity.Error, 0, catId));
 }

areas.Add(new SPDiagnosticsArea(DiagnosticsAreaName, 0, 0, false, categories));
 return areas;
 }

Cool.

The next quirk was that there are two methods one might want to use for logging. There is WriteTrace(), which writes to the trace logs, and WriteEvent(), which writes to the Windows event log, and the trace log. Yup, if you used both, you can end up writing to the ULS logs twice. I also don’t want to have to think about making two calls. I just want one call – “Make a record of this” – and have SharePoint sort out where it is written to.

A third point in this aspect of my design was that I don’t like making method calls with parameters to define the importance. Maybe it’s my Java heritage from a long time ago, but I prefer calls like Logger.Warning() to record a message at a ‘Warning’ level of importance. It’s simpler, and easier to read.

Thus, I decided my service would have calls like Error(), Warning(), High() and Medium(). These would call an internal private method, specifying the appropriate EventSeverity and TraceSeverity settings. Methods like Error() would call my internal method with a TraceSeverity of ‘None’, and the call to WriteEvent() will also, as mentioned, write to the tracelogs anyway. Lower importance calls, like Medium() wouldn’t write to the Windows Event Log, so they have an EventSeverity of ‘none’, but an appropriate Traceseverity, so we log things correctly.

Great – but there is another problem. Writing to the Windows Event Log relies on there being an Event Source to write to. If there isn’t, WriteEvent() will try to create it. However, in some configuartion of SharePoint, the account making the logging call won’t have the privileges needed to create this Event Source.

The Event Source itself is really just a key in the Registry of the, so one could try to make sure that a highly privileged account is used to create it. However, you’ve then got the question – which server? Answer – all of them. Fun and games.

Jurgen Baurle’s example shows how, when the Feature for registering the diagnostics service is run, he also tries to create the Registry key for each server in the farm. Kudos, that’s quite neat, but I’m still not sure I like it. What if someone adds a new server? Well, it wouldn’t get that key – and you’re back to square one.

Alternatively, one could use a Timer Job configured to run on each server in the farm. That’s a pretty good approach – but heavyweight. A Timer Service, that’s going to run from time to time forever, just to set that registry key IF a new server is added? (Chris Keyser’s job runs once – but then you’ve got the same problem of adding new servers again).

So, for my little logger, I took the easy option. If there is a problem writing to the Windows Event log, make a note of it in the Trace log, and then output the original message to the Trace log too. It ain’t pretty, but it is simple.

And my final little bonus – I like to know the class and method that output my messages to my logs. It’s useful for debugging. So, the private method WriteLog uses reflection to walk back up the StackFrame to the method that called it, and then uses reflection to get the class and method information, and those get put into the message too. It’s much simpler than, as I’ve seen done (heck, done myself), passing the method name as a parameter to each logging call.

And there you have it. You’ve now got something that you can make a call like:

MyLogger.Error( MyLoggerCategory.General, "My Message" );

… and the rest is dealt with.

You can download MyLogger.cs here. And to register or unregister it, you’ll need a Feature Receiver, something like MyLoggerFeatureReceiver.cs.

References:

• Debugging and Logging Capabilities in SharePoint 2010 on MSDN
• How To Implement A Custom SharePoint 2010 Logging Service For ULS And Windows Event Log by Jurgen Baurle
• Tips for ULS Logging Part 1 & Part 2 by Steve Peschka
• YuleTide ULS by Todd Carter
• Logging to ULS in SharePoint 2010 by Waldek Mastykarz
• Using a SharePoint Timer Job to deploy settings in a farm for registering event sources by Chris Keyser
• Using a Timer Job to ensure diagnostic areas of SPGuidance by Patrick Boom

<View List="Lists/Tasks" BaseViewID="7" WebPartZoneID="Left" WebPartOrder="5" />
<View List="Lists/Tasks" BaseViewID="9" WebPartZoneID="Left" WebPartOrder="6" />

would result in:

How can we set those titles to be different?

With other web parts, it wouldn’t be a problem. When adding them to a page in the ONET.xml file, you specify what the webpart’s assembly, class and properties all are:

<AllUsersWebPart List="301" WebPartZoneID="BlogNavigator" WebPartOrder="2">
 <![CDATA[
 <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
 <Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
 <TypeName>Microsoft.SharePoint.WebPartPages.BlogMonthQuickLaunch</TypeName>
 <Title>My Title Here</Title>
 </WebPart>
 ]]>
</AllUsersWebPart>

Great. But nothing in the CAML documentation says that you can do this with a <View> element, just within <AllUsersWebPart> elements. But what if you can? I did a regex search over 14 Hive, and found the following example:

<View List="303" BaseViewID="0" WebPartZoneID="BlogNavigator" WebPartOrder="1">
 <![CDATA[
 <webParts>
 <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
 <type name="Microsoft.SharePoint.WebPartPages.XsltListViewWebPart,Microsoft.SharePoint,Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" />
 <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
 </metaData>
 <data>
 <properties>
 <property name="AllowConnect" type="bool">True</property>
 <property name="ChromeType" type="chrometype">None</property>
 </properties>
 </data>
 </webPart>
 </webParts>
 ]]>
</View>

Ooo – interesting. This isn’t quite what I need – it’s using the XsltListViewWebPart, and unfortunately I’m dealing with an old SharePoint 2007-type list. I wondered, though – would the same approach work with the ListViewWebPart?

Well, a quick search turned up the answer – a definite yes - and I wish I’d known about this 3 years ago. The following form of web part declaration:

<View List="Lists/Tasks" BaseViewID="7" WebPartZoneID="Left" WebPartOrder="5">
 <![CDATA[
 <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
 <Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c</Assembly>
 <TypeName>Microsoft.SharePoint.WebPartPages.ListViewWebPart</TypeName>
 <Title>Enquiry Tasks</Title>
 </WebPart>
 ]]>
</View>
<View List="Lists/Tasks" BaseViewID="9" WebPartZoneID="Left" WebPartOrder="6">
 <![CDATA[
 <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
 <Assembly>Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c</Assembly>
 <TypeName>Microsoft.SharePoint.WebPartPages.ListViewWebPart</TypeName>
 <Title>Request Specific Tasks</Title>
 </WebPart>
 ]]>
</View>

results in …

Perfect! Problem solved, and now I can control all sorts of other settings (such as Chrome, or allowing close) for these web parts too!

EDIT: I just found another example, this time on MSDN. It’s even more minimal than the one I found in 14 - it doesn’t define an assembly or class. However, it does not work. I tested it, and got the error:

The <Assembly> element is required. Add this element to the Web Part file (.dwp), and then try to import the Web Part.

That’s a pretty clear error. So, do not follow that article, but use the fuller forms shown above.

EDIT 2: I also note that the properties in my old-fashioned 2007 ListViewWebPart aren’t the same as in the 2010 XsltListViewWebPart – Sandeep lists some of the properties available here.

• Andrew Connell has a brief write up
• Mick Breeze dug into it with Reflector
• Michel Barneveld seems to have found it the same way as I did – but looks at how it is calculated. He also describes how to force SharePoint to return a given value, in case you need to test something (like how your client code handles a stressed server)

So how do we test the loadbalancer if we set it up in this fashion? Do we need to DDoS a WFE?  There is a better way There is a registry setting  that will override the Health Score and it will return the value from the registry.

Create a DWORD with the name ServerHealthScore in the following location: HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS and give it the value you want.

So what’s it useful for? Well, the main things that strike me would be:

• Server Monitoring – Pretty obvious, really.
• Client Applications – Can warn or take corrective actions if the server is loaded and may implement throttling.
• Client Side scripts – Similar to above, though I haven’t yet been able to figure out who you’d get this value in the Client Object Model. I’m assuming there is a way to get the response headers in the Client Object Model – otherwise you may have to use normal XMLHttpRequests if you want to see the response headers.

query.Query = "<Where><Eq><FieldRef Name='MyField' /><Value Type='Text'>WhatILookFor</Value></Eq></Where>";

Well, that’s fine, but what about lookup columns? They actually have 2 elements – the text, and an ID.

E.g. You might have a lookup to a ‘Country’ list, and “United Kingdom” might be ID 45.

If I wanted to find items on my list that referenced the “United Kingdom” value, my query would be:

query.Query = "<Where><Eq><FieldRef Name='MyField' /><Value Type='Lookup'>United Kingdom</Value></Eq></Where>";

However, this doesn’t make much sense. The ID is our primary key to the ‘country’ list. Why are we querying by value? I mean, if the United Kingdom had a revolution and suddenly became, say, the ‘United Republic’, all of my CAML queries would break.

(That might  be the least of my worries, but you get my point).

So, we’d like to query by ID. Well, you can - I’ve mentioned it before, and the MSDN documents neglect to mention it themselves. There is a property on the FieldRef of LookupId. Set that to True, and you can query by ID.

query.Query = "<Where><Eq><FieldRef Name='MyField' LookupId='TRUE' /><Value Type='Lookup'>43</Value></Eq></Where>";

Edit: One of my colleagues pointed out that in SharePoint 2010, if you update the text of a referenced item, it is updated within the items that reference it. This is different to SharePoint 2007, where the referencing items retained the original text value. He’s right – but I’d still prefer to query by ID as it’s indexed, unique, and simple.