An in-between project: WPF screensaver for communicating our company values + news

A few weeks ago one of the TopForce founders asked me for an idea for communicating company messages to the TopForce employees. He was considering the usage of a screensaver for this. He had several requirements:

1. It must be easily possible for the TopForce management to push new messages on-the-fly to our employees
2. The displayed screensaver is attractive and draws on the attention of both the TopForce employee as coincidental passers-by
3. The screensaver has a professional layout and styling

Being a SharePoint guy and fan, I immediately thought of applying our SharePoint based intranet for the management and distribution of the screensaver messages. Management can be done via a dashboard page containing multiple ListViews for the different categories of messages. Distribution can be done via SharePoint Lists.asmx webservice. So that's for addressing requirement 1. For the second requirement I considered WPF, you can do all kind of screen graphics and (dynamic) behaviour with that - from very simple to most advanced. For the last requirement; well I'm a developer, not a designer. Different roles, and especially different talents. I directly admit that I do not posses enough designer talent. But luckily I've several colleagues that are especially strong on the User eXperience area. Frodo Jansen did a very good job on desinging the screen-layout, addressing the third requirement.

The sketch of the software architecture for this mini application looks like this:

An impression of the end-result:

Workaround for 401 problem with POST and NTLM authentication

Context: Invoke SharePoint Lists.asmx webservice from a WPF client to retrieve listitems. The SharePoint site is hosted by an external provider, and secured via NTLM authentication. To invoke the Lists webservice a WCF proxy is generated. The client WCF binding is set to basicHttpBinding, with security = NTLM.

Issue: When invoking the service from the WPF client, a 401 is returned. Via Fiddler inspected the http-request. The NTLM authentication protocol handling in 3-steps is visible, but despite that no succesfull authentication. A simple GET via WebClient to the Lists.asmx page, with same NTLM credentials applied does succeed.
And strangely, in case this is done before sending the POST webrequest, the latter does also succeed. That is..., when Fiddler is active. Without Fiddler monitoring the http transfer, the HTTP-GET request still succeeds, however the WCF proxy call then again fails.

Although I love Fiddler, it's no option to oblige application end-users to run it just to allow the WCF proxy call to succeed...
Instead I tried to implement the SOAP behaviour explicity self via WebClient, and abandon the WCF framework in this particular case. And this works!

N.B. The probable cause of the POST malfunctioning with HttpWebRequest / WCF proxy and NTLM authentication is described in the post 401 Error on HttpWebRequest with NTLM Authentication.

Tip - HowTo package multiple project-assemblies in a single WPF executable

It's a good practice to structure your Visual Studio solution according to the application layers. You can do that via a folder structure within a single project. But I prefer to structure each application layer within it's own VS project. This approach allows (the build of) each VS project to depend only on the architectural layer direct beneath it.

A consequence of structuring within multiple VS projects, is that each project will build its own assembly file. Often this is also required for deployment and update flexibility. Sometimes however its handier to package it all within a single assembly for deployment. An example is the build of a WPF .exe. Especially for a smaller application, it's a bit overdone to have to deploy one or more .dll assemblies besides the .exe.

Luckily it's easy possible to also package the other project-assemblies within the main .exe executable. The tool to the rescue here is ILMerge. You can modify the project file to automatically merge the dependant .dll assemblies within your main .exe:

<PropertyGroup>
<PostBuildEvent>ILMerge.exe /internalize /ndebug /out:$(TargetFileName) $(TargetFileName) TopForce.Communication.Application.dll TopForce.Communication.Integration.dll</PostBuildEvent>
</PropertyGroup>