sfeldman.NET

I had to look into a project that submits large files to WCF service. Implementation is based on data chunking. This is a good approach when your client and server are not both based on WCF, bud different technologies.

The problem with something like this is that chunking (either you wish it or not) complicates the overall solution. Alternative would be streaming. In WCF to WCF scenario, this is a piece of cake. When client is Java, it becomes a bit more challenging (has anyone implemented Java client streaming data to WCF service?).

What I really liked about .NET implementation with WCF, is that sending header info along with stream was dead simple, and from the developer point of view looked like it’s all a part of the DTO passed into the service.

[ServiceContract]
public interface IFileUpload
{
  [OperationContract]
  void UploadFile(SendFileMessage message);
}

Where SendFileMessage is

[MessageContract]
public class SendFileMessage
{
  [MessageBodyMember(Order = 1)]
  public Stream FileData;

  [MessageHeader(MustUnderstand = true)]
  public FileTransferInfo FileTransferInfo;
}

This is something trivial, yet got me to think for a little. I had two checksums, one received from a client invoking a service, another one calculated once data sent into service is received. Checksums are plain arrays of bytes. I wanted to have comparison to be expressed as simple as possible. Quick google search brought me to a post that dealt with the same issue. But linq expression was too chatty and I think the solution was a bit muddy.

So I looked a bit more into linq options presented in the post, and this is what ended up using:

var matching = original_checksum.SequenceEqual(new_checksum);

Sometimes things are so simple, we tend to overcomplicate them.

Robert C. Martin gave a nice presentation on InfoQ, highly recommended.

Yesterday I watched Food Inc. documentary movie. And this morning, hours after watching it, on the radio they announce salads recall – Salmonella bacteria contamination. Wonderful. Another proof of house mass production (and not just food) can go and goes wrong. The movie is highly recommended.

Nice to see BDD spreading quickly around. Reminds me how about two ago I wanted to switch our company from ASP.NET web forms to MVC, to allow better introduction into testability. This video just reminded me how correct that assumption was. And these days, with the tools like MSpec and support out of box by R# and VS.NET – it’s a must. Enjoy the video.

PS: one thing I didn’t like in particular, if you talk about mocking, show it, don’t just leave it in words. Otherwise it’s a bad service for novice that want to see it in action.

Buy vs. Build dilemma is quite common in software development. Based on degree of customization, decisions are made. But is it just degree of customization? As a developer, the urge to build and will to prove that “we can pull it off” is very strong. What I find often is that another dilemma exists, similar to the mentioned one, but rooted in restrictions related to time and will to go above the “regular known” – Learn vs. Build.

As an example, I can take WiX installer and build-server spawned off builds per environment. If you have multiple environments, normally we’d go with configuration-variables-per-environment (NAnt) file, that would get included during the build process and result in MSI installer preconfigured for that specific environment it was build for. Now, if you have 10 different environments, and about 10 different products you build often, it becomes a burden on build server and a very convoluted way of doing things on a large scale. What are the options? Several. Among those build more or learn about things and then make a decision.

Gladly, after learning a bit more about WiX, it is presently nice to know that WiX has the concept of parameters and XML poking baked straight in it. Now, making a single build to accommodate different environments became way simple – single installer with a batch/command file per environment (batch just would invoke MSI installer, passing in environment specific parameters).

To achieve the solution, add a reference to WixUtilExtension.dll and add a namespace for it as a Wix element attribute xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"

From that point, this is very similar to a standard XML poke (such as NAnt).

<util:XmlFile Id="SetKey1"
              Action="setValue"
              ElementPath="//appSettings/add[\[]@key='Location'[\]]/@value"
              Value="[LOCATION]"
              File="[#AppConfig]"
              SelectionLanguage="XPath"
              Sequence="1" />

A few things to explain:

#AppConfig – reference to the WiX included file ID, with # sign in front where XPath is executed

LOCATION – parameter passed into WiX MSI when executed

So if MSI generated by the build is called Product.msi, batch file could contain a line:

Product.msi LOCATION=C:\bla

Then result configuration file identified by “AppConfig” ID would contain:

<appSettings>
    <add key="Location" value="C:\bla" />

Note: if no parameters are supplied, empty string is used clearing any default values

Moral of this post? Invest some time before you rush to build. There’s a high potential that you are re-inventing the wheel. And another one, it is never too late to re-factor, if something just “doesn’t feel right”.

This is an interesting plug-in for VS.NET 2008/2010 to allow remote pair-programming. I’m a big advocate for pair-programming and collaborative work, so this plug-in has its place in the real world. I used to pair-program with a developer that was remote, and we used VNC/RDC, but this one is way better.