Tuesday, October 8, 2013

"No exports were found that match the constraint"

Visual Studio doesn't like slackers.  If you don't use it for a while, it may decide to throw fits - in this case it's this indecipherable message:


It either coughed up the message when I tried to create a new project, or plain bombed out if trying to open an existing one.  Turns out it's basically a stale cache of some sort.  Just get rid of the ComponentModelCache folder it'll be back happy again.

Why yank the Component Types table from SFMT Guide?

It seems that in the new Force.com Migration Tool Guide for Winter '14, the big table of component types - what are allowed in the element - has been removed.  In its place now is a link to the Metadata Types in the Metadata API Guide.  That's a major rollback of usability without any apparent gain for a number of reasons.

  • While the FMT tool is based on the Metadata API, its element usage doesn't necessarily translate nicely from what in the API.  The Tool Guide users are definitely looking for ready-to-use information for the ANT plug-in.
  • The Metadata API component page is missing specific information needed for FMT users (folder location, wildcard applicability, etc.)
  • The PDF version is intended for self-contained consumption - offline reference, for instance, but even that version opts for the link instead, making it much less convenient for certain circumstances.
See below for the change comparison.
component table removed

CTI related fields on Task

In Salesforce there are a number of standard fields that usually get set if there's a CTI connector creating task/activity records.  Fields involved include Call Type (CallType), Call Duration (CallDurationinSeconds), and Call Result (CallDisposition).  If you look at the field-level security for those, it's Read-Only for every profile.  That may seem to be a problem if you're testing functions that are based on them - say additional processing for Outbound call types - but you don't have access to a functioning CTI.  Well, it's actually no problem at all.  Those fields can still be set via code/API normally despite being Read-Only for all, which is probably just an UI only overlay to prevent end user editing.