FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks.

We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop, general desktop matters, applications that enhance desktops and web (when related to desktop).

Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2014 schedule might give you some inspiration.

Please include the following information when submitting a proposal:

  • Your name
  • The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects)
  • Short abstract of one or two paragraphs
  • Short bio (with photo)
  • Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request.

The deadline for submissions is December 7th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will take place on Sunday, February 1st 2015. Please use the following website to submit your proposals: (you do not need to create a new Pentabarf account if you already have one from past years).

You can also join the devroom’s mailing list, which is the official communication channel for the DevRoom: (subscription page for the mailing list)

The Desktops DevRoom 2015 Organization Team


Do you use WCF? Do you generate your datacontracts by means of postbuild events? Have you tried msbuild and seen a “cannot build XXXXX.csproj because DataContracts.cs was not found” error? Then keep reading.


MsBuild is the “next generation” nmake for Visual Studio. It’s been available since .NET 2.0 and has been bundled with Visual Studio since MSVC2008.

Same project files…

You don’t need to feed msbuild special project files (such as the Makefiles nmake required), it is smart enough to understand Visual Studio solutions.

… yet slightly different behavior

MsBuild does not behave 100% like Visual Studio (devenv), specifically in regards to:

  1. Dependencies
  2. When events are run
  3. When byproducts and referenced projects are copied

In general, this will affect you whenever you use postbuild events to generate source code or binaries which are required immediately.

In the project I am involved now, this is especially important when generating datacontracts. We use a Visual Studio post-build event.


There are two kinds of ways to express project-to-project dependencies:

  • Project to project references (Add Reference->Project tab) [this mechanism also handles gathering the referenced output file as well]. For .csproj, this is persisted as a <ProjectReference> item in the project file.
  • Explicitly specified dependencies (Solution properties->Project Dependencies) [with this mechanism you would usually also add a File Reference to the referenced output yourself]. This writes the “ProjectSection(ProjectDependencies)” section in the .sln.

There seems to be a long standing bug which makes msbuild not take all the dependencies into account.

As a consequence, a solution may build fine in Visual Studio (devenv) but not build at all with msbuild. I would say this bug is fixed in VS2010SP1, but I cannot tell 100% sure because I have not performed enough testing.

In addition to that, never add a dependency as a reference-to-DLL if that DLL is part of of your solution (.sln). Both MsBuild and DevEnv will choke when you switch from Debug to Release, because you would be setting a reference to a Debug DLL from a Release project, or viceversa (unless you use $(ConfigurationName) in your path, of course, but people rarely remember to do that).

When events are run

MsBuild runs the postbuild event before copying the byproducts to the output path

Visual Studio (devenv) runs the postbuild event after copying the byproducts to the output path

This can be solved by writing an AfterBuild event manually in the .csproj, but it is quite inconvenient because there is no GUI in Visual Studio to add, edit or remove AfterBuild events. You are alone with your text editor.

When byproducts and references are copied

As said above, msbuild runs the postbuild event before copying the byproducts. No only that: msbuild runs the postbuild event before copying the referenced projects (DLLs) to the output path.

Visual Studio (devenv), on the other hand, runs the postbuild event after copying the byproduct and its referenced projects to the output path.

In summary


  1. Compile
  2. Copy byproducts (DLLs, executables, etc)
  3. Copy byproducts’ referenced project output (DLLs, etc)
  4. Run postbuild event


  1. Compile
  2. Run postbuild event
  3. Copy byproducts (DLLs, executables, etc)
  4. Copy byproducts’ referenced project output (DLLs, etc)


If you need the compilation byproducts in the post-build event (as is generally the case when generating datacontracts in the postbuild event), you will need a workaround.

You would think it’d be possible to tell MsBuild to behave like devenv, right? Wrong. It is not possible.

The only possible workaround I have found is to manually copy the result of the compilation to the output path in the postbuild event. Something like this:

call “%VS100COMNTOOLS%\vsvars32.bat”

if exist “$(ProjectDir)Temp” del /s /f /q “$(ProjectDir)Temp”

copy $(ProjectDir)\obj\$(ConfigurationName)\$(TargetName).dll .

svcutil /t:metadata /dataContractOnly /directory:$(ProjectDir)Temp\DataContract $(TargetName).dll

svcutil /t:code /dataContractOnly /r:$(ProjectDir)..\MyProject.Data.DataContract\bin\$(ConfigurationName)\MyProject.Data.dll /directory:$(ProjectDir)..\$(ProjectName).DataContract /out:DataContracts.cs $(ProjectDir)Temp\DataContract\*.xsd

(where “.” is the output path, the solution generally runs from there; usually you will only need to copy & paste this line to your postbuild event).

Not nice, but it works.