In most of our latest Sharepoint projects we need a lot of customization. These customization generally mean that we develop webpparts and custom lists so that we use sharepoint as a sort of database. The list itself is rarely visible to end users and only to a extended sharepoint site that is used as a backoffice application.

The development of the webparts go as follows:

• For every webpart we develop we have:
  • The <webpart>.cs control
  • The <webpart>Control.asc User control
  • The <webpart>.wsp XML file that is used to package the webpart
  • A Test<webpart>.aspx file that is used to test the webpart standalone but is never deployed to the sharepoint application.
• The webparts do not rely on sharepoint, but bind to strongly type objects and collection.
• A Provider pattern is used for retrieving and updating of the data objects.

This provider model allows us to test and verify functionality of the webparts without the need to upload/provision these webparts inside a Sharepoint hosted website. We all know this takes a lot of time. The provider is configured in the web.config of the webpart solution file.

Here's a sample of one of these business objects:

The user control uses this class in codebehind like so:

You see this is basic ASP.Net stuff.

I found this a pretty amazing thing; it cuts down on the time used for each development roundtrip, and it allows us to 'outsource' the development of the web parts to ASP.Net specialist who do not (yet) have the required Sharepoint knowledge. The knife cuts on two sides!

This approach did have an enormous disadvantage however. The provider that implemented the mapping from the hard-coded business object to sharepoint needed a lot of custom code. It only paid of once the business object was used in multiple places. Another problem is that the code that provisioned the custom list was always a one-off piece of custom code. That code has NO relation to the business object.

Now, my experiences with entitypool helped me in writing a library that solves all this:

To create the list in Sharepoint, all that is needed is the following statement:

To retrieve all appointmentobjects we have a factory that converts a SPListItemCollection to AppointmentObject objects:

Easy? I think so.

In my previous post I rambled about a bug in the Web Application .targets file. I found an easier solution which does not involve patching any existing files.

The solution is to add the dependency projects to the msbuild target list like so:

msbuild /t:ResolveAssemblyReferences;_CopyWebApplication

     /p:OutDir=..\Drop\bin\ /p:WebProjectOutputDir=..\Drop\

Wow. Life CAN be easy.

Update: Even more so, it is better to use ResolveReferences, which also copies any project assembly references you have in your project.

 Update 2: You actually need to add a 'bin' directory to the OutDir folder. 

In my search for MSBuild tooling and software complexity analysis, I found the following tool: CCM 

It is a very simple and fast commandline tool. More info later on.

Note: Please check out this update for an easier solution.

Today was cool. I managed to get my first continuous build server online at work using CruiseControl.net. I was cool, up to the point when I wanted to deploy the application nice and clean.

After a lot of googling, I found out that Visual Studio internally uses a .targets file to deploy web applications. It is (by default) referenced in your .csproj file of your web application so you don't have to add it to your solution file (which fortunately IS a msbuild .targets file with just another name). The target file is located here in C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications. You don't need to install Visual Studio on your build server, you just need to copy the MSBuild directory to the program files folder of your build server. You will however need to install the 2.0 SDK on the build server. it includes a hidden target named '_CopyWebApplication' which you can call.  Thanks to links here and here.

To deploy your web application, just enter the following commandline with your current directory set to the project directory:

msbuild /t:_CopyWebApplication

Unfortunately, this is not sufficient, because the build file detects if the output directory is the same as the current directory:

<Target Name="_CopyWebApplication" Condition="'$(OutDir)' != '$(OutputPath)'">

This problem is easily solved:

msbuild /t:_CopyWebApplication /property:OutDir=..\Drop\ /property:WebProjectOutputDir=..\Drop\

Which will effectually copy all the files in the directory ..\Drop\ and remove the added _PublishedWebsites path, 

but Alas! There is a 'problem' with this solution because references DLL's are not being copied over. I did a lot of googling again and i managed to solve it.

You need to change the line to:

<Target Name="_CopyWebApplication" Condition="'$(OutDir)' != '$(OutputPath)'" DependsOnTargets="ResolveAssemblyReferences">

By making the _CopyWebApplication dependant on the the ResolveAssemblyReferences target (which is a built-in target), the correct properties @(ReferenceCopyLocalPaths) has been magically filled and all your files will be nicely copied to your drop directory. I guess that this is a nifty bug in the web project build file.

There you have it. All that remains is to add another MSBuild task to your Cruisecontrol.net configuration file that publishes the result. I leave that as an exercise to the interested reader because my dinner is ready.

As promised, the first beta.

Source code and vs2005 solution

SourceMetrics.zip (71,51 kb)

Sample output

codelines.xml (381,00 bytes)

I'm here to tell you about my latest invention: SourceMetrics. It is a commandline tool to scan a source repository (actually just Visual Sourcesafe for now) and report a cool set of statistics about its contents.

Currently, it reports:

• Total number of files
• Total number of bytes
• Total number of lines
• Total number of code lines
• Total number of comment lines

As this tool reports code as Xml, it will be very easy to integrate with build script and tools like CruiseControl. The effect of having some kind of time-related statistics are huge. As first beta, and more info will be posted lated on.

Rant time.

What the hell is wrong with our job as developers? Why do we get into problems at the end of every development project? In 99.9999% cases deadlines are crossed, even though you've tried and tried to change the way we do things because we were so absolutely sure that we "wouldn't do it next time".

Let me get the word out. It is not our fault. It isn't.

Everytime we invent some new stuff to cut development times like compilers, syntax highlighting, object-orientend programming, source control systems, daily builds, test-driven development, automated test scripts, huge component libraries, peer programming, open source communities, review systems, software factories, etc. etc. (just to name a few), some pointy-haired-boss walks in the room and tells us "He wants it yesterday" without even listening to our slightly reasonable remarks like "We talked about it, and we all agree that this is not possible within the given timeframe, whatever quantity of resources you whip up".

Higher management, lower management, planning comitees, end user discussion groups have the last word. At least we developers have invented stuff (and it is a lot of stuff) that actually improves our product life cycle. And the reason this lifecycle improves, is because people of the previously mentioned groups are so horribly good in changing the specs right under our noses, and tell use that they "Need it finished next monday". Don't they know it is freaking friday afternoon (6.30 PM)? Apparently they don't. And if they do, they'll find something else to make it our problem.

So what do we do? We get coding. We get coding quick. Because if we 'save the project' we'll probably be rewarded for it. Maybe even get a bonus for delivering on time. Get an extra personal day. We finally receive those bigger harddrives and those tools we've been asking about for months. So we get coding. And we succeed. And next time? Next time, we won't make that mistake.

I wish it were true.