I was working with a customer today who had an interesting deployment error:

Error 1 Deploy smartobjects: Task error: SmartObjectServer Exception: Dependancy could not be created: System.Exception: Dependancy could not be created. Parent does not exist in this environment. Check Data property of exception.   at SourceCode.Hosting.Services.DependancyService.VerifyObjects(List`1 parents)   at SourceCode.Hosting.Services.DependancyService.CreateDepenancyBatch(Dictionary`2 depenancyBatch). SmartObject: 'ApplicationIssueObject' Parent ID = '9b17ec8c-177f-4191-98c5-9b908a342e8f'

Many of you may have seen this error when you attempt to deploy a SmartObject based on a dynamic service instance to anther environment.  This has been posted numerous times on this site, but to recap:  SmartObjects bind to the GUID of the underlying service instance, not the name.  When you move between environments and a SmartObject is bound to a dynamic service instance the name might match but the deployment will fail because the GUID is different.  The solution is to change the GUID of the service instance in the target environment to match the GUID of the instance in the environment where the SmartObject was developed.  Or better yet, register the instance with the BrokerManagement utility (in the \ServiceBroker directory) with the same GUID in the first place.

But this customer knew this already and had made sure the GUIDs matched.  After some digging, here is what we found:  the deployed solution contained a SmartObject and a process with a circular dependency.  The workflow was to be started when a row was inserted into the SmartObject from a web page.  The SmartObject had a composite Create method so when a row was inserted, it also invoked the Start method on the workflow SmartObject.  The workflow process had an association to this same SmartObject.  Because of this circular dependency the SmartObject couldn’t be deployed until after the workflow was deployed, and the workflow couldn’t be deployed until after the SmartObject was deployed.

Here’s what we did to get everything deployed:

1. Make a backup copy of the SmartObject SODX file 
2. Remove the process.Start from the composite SmartObject Create (and any other methods that refer to the Workflow SmartObject) 
3. Deploy the SmartObject only, excluding the process 
4. Deploy the Process only, excluding the SmartObject 
5. Restore the backup SODX file with the composite methods that depend on the workflow SmartObject 
6. Deploy the SmartObject again, this time including the composite methods

This only needs to be done the first time you deploy to a new environment.  After it has been deployed once, the dependencies will be met and you can deploy the solution.