“No matching items found in your workspace” error in the TFS build

After creating MS Build Definition for a new branch I’ve got an error
No matching items found in $/MyBranch/subDir  in your workspace, or you do not have permission to access them“.
I was trying to find any permission issue for a build user, but  http://stackoverflow.com/questions/9210485/how-do-i-setup-tfs-build-definition-when-my-localpc-source-build-agent-and-de pointed me, that the error was caused by missing mapping.
To fix it it’s required in Build Definition Edit open Workspace TAB and add folder mapping for a new branch in the table like the following
Source Control Folder | Build Agent Folder 
$/foo/bar | $(SourceDir)somewhere 

Compare Pocket and Instapaper on IPad (again)

Since my last post http://geekswithblogs.net/mnf/archive/2012/06/24/from-pocket-to-instapaper.aspx I use both applications on iPad, trying to use Instapaper more often.  Unfortunately, I wasn’t fully satisfy with it.
I didn’t have any response to couple of emails, that I ‘ve send to  instapaper.support@marco.org, so I even don’t know, have Marco receive it or not.

The major problem is “smart” context removal, which removes comments from blogs and stackoverflow discussions, corrupts tables in pages.
 I’ve recorded a few examples, but not sure, that Marco is interesting to get them.

Now I prefer to use Pocket on iPad again and looking forward, when they will restore “rename titles” function, that was lost 4 month ago.

Using interfaces in DataContracts for WCF service versioning.

We are implementing WCF Service versioning after having problems  with enums in response  (  Do not expose enum in WCF response )
I found that we need rigorously follow the recommendations “Versioning When Schema Validation Is Not Required” from msdn article:
Best Practices: Data Contract Versioning

Initially I’ve ignored the recommendation “Do not attempt to version data contracts by type inheritance” and failed to generate backward compatible XML.

Reading the documentation I’ve noticed in Service Versioning article
an example
public interface IPurchaseOrderV2
{
   DateTime OrderDate { get; set; }
}
which includes only one new field. It is used in

[DataContract(
Name = “PurchaseOrder “,
Namespace = “http://examples.microsoft.com/WCF/2006/02/PurchaseOrder”)]
public class PurchaseOrderV2 : IPurchaseOrderV1, IPurchaseOrderV2
{
   [DataMember(…)]
   public DateTime OrderId {…}
   [DataMember(…)]
   public string CustomerId {…}
   [DataMember(…)]
   public DateTime OrderDate { … }
}

I believe that it would it be more appropriate to have IPurchaseOrderV2 derived from IPurchaseOrderV1.

public interface IPurchaseOrderV2: PurchaseOrderV1
{
   DateTime OrderDate { get; set; }
}

I asked myself,  should I repeat all properties from original in a new interface and would it give any benefits to versioning.

public   interface IPurchaseOrderV2  
{
   public DateTime OrderId { get; set; }
   public string CustomerId { get; set; }
   public DateTime OrderDate { get; set; }
}
but I was on a wrong track.
Interface is not allowed to be marked as DataContract.The reason is explained in  the answer of
http://stackoverflow.com/questions/4720730/wcf-and-interfaces-on-data-contracts

XML schema doesn’t know anything about interfaces – it’s all about concrete, actual types.

Using interfaces for service contracts are recommended, however  interfaces in dataContracts are not exposed externally.
i’ve checked the article again and found that the appendix  in MSDN  actually is quite clear:
write INTERNAL implementation code in terms of the interfaces rather than the data contract classes that implement the interfaces.
I just confused myself by quick browsing instead of proper reading.