The build process could not be deserialized due to…


At my current customer we’ve upgraded all our builds from TFS 2008 MSBuild tasks to TFS 2010 WorkFlow Activities. I must say that we’ve gone from several common target-files and per-build specific rsp-files to ONE build process template! That says enough about the power of the new build process in TFS 2010.

Following Microsoft’s recommendation here we’re using one Build Controller for our Default Collection and we’ve centralized our custom activities to one Team Project; lets call it Central.

In the Team Project Central the custom activities we’re using a stored at $/Central/BuildComponents and our Build Controller points out this location as the picture shows below:


In our Custom Activities we have some simple serializble objects that we use as part of our process to store some settings that we need in our build process. An of that would be an XCopyFileWrapper that we use to store 3 string properties:


We then use this wrapper in our Meta Data property in our DefaultTemplate.xaml file like the picture shown below:


Then we added the ParamWrapper as an array of XCopyFileWrapper and add it as an argument to DefaultTemplate.xaml like so:


This way we can have the same DefaultTemplate XCopy files depending on the input we add for each unique build definition in this rather nice centralized GUI for your build definitions:



And then in our DefaultTemplate.xaml we have an foreach loop that loops over our array of XCopyFileWrappers and invokes XCopy! This makes our build definitions really sweet, dynamic and expandable right!

The challenge

So the next Team Project comes along we can call it Project B and they want to use our Build Process. So they branch our build process template into their project and they create a new build definition and then KAPOW!


What happen here! Well my initial thoughts was another lesson I learned previously and blogged about here but specifying the assembly in the DefaultTepmplate.xaml didn’t solve this issue.

The solution

The very simple solution to this problem is that you need to give users READ permissions to your BuildComponents folder in our case the $/Central/BuildComponents folder (another way is to solve this is to give other users READ permissions to the Central Team Project).

That’s it!


  • So if I want to centralize my custom build components then I have to give all users that will use these custom build components READ permission to the folder where the components are stored.
  • Or you could have some sort of deployment mechanism that deploys the build components to every Team Project in the Team Project Collection but then you’ll have to have one Build Controller per Team Project.



3 Replies to “The build process could not be deserialized due to…”

  1. Hello there i’m also facing similar problem,
    The build process could not be deserialized due to the following error: Implementation property has already been set to Dynamic activity.

    How to solve this problem. Any idea??


    1. Hi,

      try editing the Build Definition that is creating this error and saving. Somehow your local build definition cache isn’t synced with the server, this usually happens when you delete a property from your build process template and then try to run a build that uses that same build process template.
      I would try the following:
      1. Open the Build Definition that is causing this issue.
      2. Go to the Process tab(area)
      3. Refresh the process template
      4. Hit the Save button (very important)


      1. Hi Hugo,
        Thanks for the reply, actually after refreshing faced the same problem.
        But finally it is solved, actually i think its a compatibility problem. I’m using TFS 2010 and used Visual studio 2010 for this earlier.
        Later tried this in visual studio 2012, and it showed me the correct changes that i wanted. So i think it was compatibility problem, by using same template settings.


Leave a Reply to Hugo Häggmark Cancel reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.