A solution for a caveat when building on TFS a LightSwitch solution with an internal RIA Service.


My LightSwitch build server setup journey seems not to be finished. Yesterday, I bumped into an annoying problem. All at a sudden, LightSwitch projects deployed via a build server didn’t start up correctly (a 500 error !). They had in common that they contained a RIA service. So, that was the only starting point for finding a solution.

What went wrong?

As you might know, a RIA service needs a file link reference to the Object context of Data service (in a V2 project this is e.g. ApplicationData.cs). The file link will assure that when something changes in the server data structures, the change is immediately propagated to the RIA service class library. The linked source code file is stored in the GeneratedArtifacts folder in the server project and is regenerated on compile time.

So far so good, let’s try to get a bit closer to the problem now. Well, apparently when you make such a file reference, visual studio will check in explicitly the source of the file link. So, the file in the GeneratedArtifacts folder. This will not hinder a local build, but indeed, it will mess up completely a build on a TFS build server.

In order to understand what goes wrong on the TFS Build server, you first need to understand roughly how the build process works.

In a first step the build process template will trigger the sources being fetched from TFS. They are typically copied in a folder called “SRC”.

Since our linked source code file (ApplicationData.cs) is checked in, it will copied also to the SRC folder. But, since it’s coming from source control, the file has the read-only attribute.

In a next step the build server will build the sources and will also try to regenerate the files in the GeneratedArtifacts folder. This will fail since our linked source code file (referenced in our RIA project) can not be overwritten since it’s readonly.  Unfortunately, the build will not (always) fail. So, when our build is doing also the deployment, we are in a very unfortunate situation: we think everything went fine, but the project won’t start. (the 500 error).

The solution

Luckily, the solution is very simple. Adapt the build process template in such a way just before compilation, the read-only attributes of the files (ok, that’s brute-force, we would not to do this only for the files in the GeneratedArtifacts folder) are changed:



In the above extract from the build process template we added a Process invocation block just before “Run MsBuild for Project”.

The Process Invocation block simply has to call the dos command Attrib on the files under the SourcesDirectory:




Setting up a software factory is a tedious job :)