Henning's Welt

Well, suddenly it just happens – a YSOD. Just happened in my recent SharePoint dev-project.

Typical for SharePoint, this error is not obvious. Instead of the YSOD you’ll get a SharePoint specific page, telling you that something went wrong. No hint what happened or where the error actually occurred.

OK, so let’s head to the web.config and stop this hide-and-seek behaviors. I wanna know what’s happening. So we have to enable to show the actual CallStack and disable the use of CustomErrors.

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
<customeErrors mode="off">

OK, so now we’re talking. I have some sort of Null-Reference-Exception in my code. But this code just worked perfect on my dev-machine, so why is it failing on the test-machine? And why is something null anyway? The StackTrace tells me, that this happened in a property-getter.

private SPGridView _mySpGrid;

public void CreateChildControls()
{
    _mySpGrid = new SPGridView();
}

public bool HasRows
{
    get { return _mySpGrid.Rows.Count > 0; }
}

How can this be null? CreateChildControls is always being called, so the grid always exists. This cannot be the reason why.

OK, let’s try something totally irrational:

public bool HatWerte
{
    get { return _mySpGrid == null ? 0 : _mySpGrid.Rows.Count > 0; }
}

This could should actually not be necessary … except when this modification makes the Null-Reference-Exception to disappear. But just to make room for the next Exception. And now everything is making sense (and I could revert the above modification).

The next exception states:

Could not load file or assembly ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ or one of its dependencies. The system cannot find the file specified.

D’oh!

My application was build against .Net 3.5 and I didn’t install that on my test-machine. Since the test-machine is a Windows 2003 Server running SharePoint 2007 there was no need to install .Net 3.5 – yet!

But .Net could have told me so from the beginning on – I would have understood this. But instead it was hiding behind some Null-Reference-Exception, just like a coward!

… or how to hide certain actions in SharePoint?

There are a couple of things, which can not be configured in SharePoint. For example you cannot configure, that users are not able to edit a list in datasheet view or in Excel or Access. Bummer!

But with a couple of lines of JavaScript this isn’t really a challenge.

<script language="javascript" type="text/javascript" src="/Scripts/jquery-1.4.2.min.js"></script>

<script language="javascript" type="text/javascript">
$(document).ready(function() {
  $("[id$='_EditInGridButton']").remove();
  $("[id$='_ExportToSpreadsheet']").remove();
  $("[id$='_ExportToDatabase']").remove();
});
</script>

Just place this code in a Content-Editor-WebPart on the page and off you go!

I’ve been using NAnt for several years now, and whenever I need to automate something during my build-process this is the first place I got to.

So I’m very excited to see, that the NAnt project is picking up pace. After releasing version 0.90 in may now 0.91 alpha 2 made it’s way to sourceforge.

Keep up the good work!

I’m not really sure, what is disturbing me more – the fact that I am actually searching for a GUID on Google, or the fact that there exists a list of GUIDs.

OK, so I have sharepoint manifest file, which is part of a site-template. This template has a whole lot of features, which have been added by sharepoint to the manifest and actually not needed at all. But all those features are only being described by their GUIDs – so who is who?

Lucky for me Robert Bogue has a blog-post, where he features a list of MOSS 2007 GUIDs. This was perfect to identify the features und to remove all the unwanted features from the manifest.

Just recently I stumbled across a code sample, which showed how to use the Registry-class of StructureMap to register classes to the container. Basically this looks like this:

public class RepositoryRegistry : Registry
{
    public RepositoryRegistry ()
    {
        For(typeof (IRepository<>)).Use(typeof (DummyRepository<>));
    }
}

container = new StructureMap.Container(x =>
{
    x.AddRegistry(new RepositoryRegistry());
});

So I though, this must also be possible in Castle Windsor – and indeed! So the equivalent in Castle Windsor would look like this:

using System;
using System.Reflection;
using Castle.MicroKernel;
using Castle.MicroKernel.Registration;
using Castle.Windsor;

public class RepositoryInstaller:IWindsorInstaller
{

    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(AllTypes
                               .Pick()
                               .FromAssembly(Assembly.GetExecutingAssembly())
                               .If(s => s.Name.EndsWith("Repository"))
                               .Configure(c => c.LifeStyle.Singleton));
    }
}

container = new WindsorContainer().Install(
    new NHibernateInstaller(sessionSource),
    new RepositoryInstaller(),
    new PresenterInstaller()
);

This is really cool, too bad I didn’t discover that before

In a previous post I described the necessary steps, to enable integrated windows authentication when working with Mantis on a linux box. These modifications where targeted against the 1.1.0a2 release of Mantis. In the meantime a lot of development has been done on Mantis, so that my original post isn’t quite accurate anymore. This post will enable you to use integrated security with the current 1.2.1 release of Mantis.

While the basic setup is somewhat unchanged, only the file core/authentication_api.php needs to be changed. The login.php doesn’t need to be changed anymore, since the functionallity moved to the authentication_api.php.

I added an updated patchfile to apply the necessary changes to the file.

You have to watch out, when choosing your column-names in SharePoint lists. A column can have any name and can easily been changed.

Good to know is the fact, that a column has actually two names. An internal name and a display name. When a new column is being created the choosen name is being used for both names, the internal as well as the display name. If you change the column name later on, you actually only change the display name, not the internal name.

So far, so good. If you create a new column called “Employee Name” then the internal name will be actually “Employee_x0020_Name”. This doesn’t look good and doesn’t feeld good when working with CAML queries or XSLT in SharePoint Designer.

A better approach would be to chose “EmployeeName” as the column name and then change the display name to “Employee Name” later on. This way you will get a nice and clean internal column name.

The Story

If you’ve been working with SharePoint you might have been working with calendar lists already. This is an easy to use way to add events to a web-based calendar. Like Outlook this features a checkbox to mark an event as a full-day event and thus omitting the start and end time (actually that’s not correct, behind the scenes the event starts ad 00:00 and ends at 23:59).

Recently someone asked on how to add a functionality like the full-day feature, but for half-day events. So you could just select wether an event should take place in the morning or in the afternoon.

That sound fairly simple to do.

How it’s done

OK, so I start by creating a new calendar from scratch. Next move to add an new item – and this is where we want to make our modifications to the form to allow selecting half-day events.

Because this view can not be edited directly in the browser you have to tweak SharePoint a little bit by altering the URL by adding toolpaneview=2 to the querystring.

Next you drag a content-editor-webpart below the editform and switch to the HTML source view.

I usually keep a copy of jQuery around, so I just add

<script language="javascript" src="/_layouts/jQuery/jquery-1.4.2.min.js" type="text/javascript"></script>

in the source-view. You might have to adjust the URL pointing to jQuery at this point. If you have no access to the file-system on your SharePoint server you could also just create a document library and place the jQuery library there and put the path in the above reference.

Next we add two buttons (this might not be the most pretty solution, but this is mostly about showing how this could be done!).

<input type=button value="morning" id="btnMorning">
<input type=button value="afternooen" id="btnAfternoon">

So the final step would be to hook to the click-events of the two buttons. Whenever one of the buttons are pressed, we just change the hour-selection for the start end end time of the event.

So the complete source looks like this:

<script language="javascript" src="/_layouts/jQuery/jquery-1.4.2.min.js" type="text/javascript"></script>

<input type=button value="morning" id="btnMorning">
<input type=button value="afternoon" id="btnAfternoon">

<script language="javascript">
  var startTime = $("#" + g_strDateTimeControlIDs["SPEventDate"] + "Hours");
  var endTime = $("#" + g_strDateTimeControlIDs["SPEndDate"] + "Hours");

$("#btnMorning").click(function() {
  startTime.val("08:");
  endTime.val("12:");
});

$("#btnAfternoon").click(function() {
  startTime.val("12:");
  endTime.val("18:");
});

</script>

Neat, if I may say so myself!

A while ago I wrote a post, describing how to setup a continues build system using CruiseControl.Net. In that post I showed how to get your project ready be continuously being build.

It’s all about improvement

That was a big step towards continues improvement in the software developing lifecycle. The next big thing is to be always up-to-date with the quality of your software and to make sure that all those bugs get fixed real soon.

To accomplish this, I created a unit-test project for my application. This can be used to do test-driven development or just to test the code you just wrote. However – you basically want to run this code whenever you change something and keep an close eye on the red-green status-icons. Whenever I make some modifications this should not affect existing features.

This means, we have to run the rest on a regular basis. This is especially important when we want to deliver some bits. We definitely want to make sure, that all test pass before we ship something.

This is where our continues integration server comes back into the game. We already have this setup to make a new build of the project whenever something changes – so now all we need to do is to make sure all our unit-tests are being run as well.

Updating the project

First of, we need to extend our NAnt build-file. We add a new target, which will run the unit-tests. I prefer to use Gallio to run my unit-tests, because this allows me to use a big variety of unit-testing-frameworks without changing the execution runtime.

<target name="run-tests" description="Run Unit tests">

    <loadtasks assembly="C:\Program Files\Gallio\bin\Gallio.NAntTasks.dll"/>
    <trycatch>
      <try>
        <gallio report-types="Xml-Inline;Html"
                report-directory="testresults"
                report-name-format="Pizza.Testing.dll-results"
                runner-type="NCover"
                failonerror="true">
          <runner-property value="NCoverCoverageFile='testresults\coverage.xml'" />
          <runner-property value="NCoverArguments='//a Pizza.Testing'"/>
          <files refid="fileset_test_assemblies">
            <include name="Pizza.Testing.dll" />
          </files>
        </gallio>
      </try>
      <catch property="failure">
        <echo message="At least one test failed: ${failure}"/>
      </catch>
    </trycatch>

    <loadtasks assembly="C:\Program Files\NCoverExplorer\NCoverExplorer.NAntTasks.dll"/>
    <echo message="Running NCoverExplorer report generation ..."/>
    <ncoverexplorer program="C:\Program Files\NCoverExplorer\NCoverExplorer.console.exe"
                    reportType="3"
                    xmlReportName="testresults\coveragereport.xml"
                    satisfactoryCoverage="80">
      <fileset>
        <include name="testresults\coverage.xml"/>
      </fileset>
    </ncoverexplorer>

</target>

This target will run all tests in the Pizza.Testing assembly of the project. Furthermore all test-results are being written to a file called Pizza.Testing.dll-results.xml.

Finally I also run the NCoverExplorer to get a nice summary of my code coverage. You might notice the runner-type=NCover, which causes Gallio to run all unit-tests within the NCover context. This way we get also some nice numbers of which code is actually covered by unit-tests.

Doing it on the server

After getting the build-file up and running we can make some adjustments to the project-configuration within CCNet (ccnet.config). Obviously we need to make sure, that the newly created target is being called during the build-process. So that’s fairly simple.

<nant description="main build">
    <executable>d:\nant\bin\NAnt.exe</executable>
    <buildFile>d:\ccnet\repositories\Pizza\Source\default.build</buildFile>
    <targetList>
      <target>Compile run-tests</target>
    </targetList>
 </nant>

But we also need to make sure, we collect all data, that is being recorded during the tests (like the test results). Since this is being recorded in a separate xml file, we need to merge this file into the main build-log, which is being maintained by CCNet.

<publishers>
    <merge>
        <files>
            <file>.\source\build\release\test-results\coverage*.xml</file>
            <file>.\source\build\release\test-results\*-results.xml</file>
        </files>
    </merge>
  <xmllogger />
  <statistics />
  <modificationHistory />
</publishers>

Showing what was done

So now we have the tests automated, and setup to run with each build. The final step is to show the test-results in the project dashboard.

For the results to show up, we have to modify the dashboard configuration in that respect, that the results are being rendered into HTML. So far they have only been merged into the build-file log.

This is being done by adding new XSL-transformations to the configuration (dashboard.config). These are part of the Gallio-package.

<xslReportBuildPlugin description="Gallio Test Report"
  actionName="GallioTestReport"
  xslFileName="gallio\xsl\Gallio-Report.ccnet-details.xsl" />
<xslReportBuildPlugin description="Gallio Test Report (Condensed)"
  actionName="GallioTestReportCondensed"
  xslFileName="gallio\xsl\Gallio-Report.ccnet-details-condensed.xsl" />
<xslReportBuildPlugin description="NCoverExplorer Report"
  actionName="NCoverExplorerBuildReport"
  xslFileName="xsl\NCoverExplorer.xsl" />
<gallioAttachmentBuildPlugin />

After that we can have a look on how many tests succeed and how many failed. The display looks just like the Gallio Runner.

If the vanilla look of Visual Studio doesn’t do it for you, check out studiostyles.net. Here you’ll find a huge amount of visual styles for Visual Studio 2008 and 2010.

BTW: my current favorite theme is Desert Nights Reloaded – even though I doesn’t make use of my beloved Envy Code R font …