Back on the old Microsoft blog, I wrote about not separating a property schema from its implementation schema. I concluded that this “tip” in the documentation seemed to be more like a guideline vs. a rule.
Today, I realized it’s more like a rule. I had a BizTalk project containing ONLY a property schema, then a BizTalk project ONLY containing the schemas that reference the property schema, and finally a BizTalk project containing an orchestration that used the various schemas. For the life of me, I couldn’t figure out why my promoted fields wouldn’t show up in the Receive shape’s filter expression, or, as part of the message (by doing “myMessage(Namespace.PropSchemaValue) = 1234). Funny enough, the property schema value marked as MessageContextPropertyBase DID show up, but any of the MessageDataPropertyBase were noticeably absent.
So, I added the property schema to my “schemas” project, rebuilt, and sure enough, all the expected promoted values showed up in the orchestration. Now, I’d bet (as in my old example) that the engine can still promote the values with no problem. But, the design time (and maybe the orchestration runtime) has issues with this setup. Either way, seems safe to say that you should keep your property schemas alongside the implementation schemas. This means, ignore the old post and file it under the “Seroter Corollary.” That is, when all else fails, let’s assume I’m an idiot.
Technorati Tags: BizTalk
Richard Seroter's Architecture Musings 
Richard,
I also realised this after a bit of testing, I ended up creating property schemas in each two schema projects in my solution. Thanks for updating the post!