A variety of things can go wrong while deploying resources. It's often a good idea, especially during initial development of a deployment console app, to run the app through Visual Studio in debug mode. This will make error messages easy to see and allow you to investigate further context when necessary.
Two common errors during initial setup of deployment are assemblies missing from
SyncSettings.ExtensionAssemblies or assemblies listed there that aren't referenced by the project. These can also occur if new module types are added to synced DataFlows that weren't previously referenced.
If an assembly is listed in
SyncSettings.ExtensionAssemblies but not referenced in the project you'll see an error like this:
System.IO.FileNotFoundException: 'Could not load file or assembly 'CompAnalytics.Execution.Modules' or one of its dependencies. The system cannot find the file specified.'
To solve this problem, add a reference to the requested DLL.
If an assembly isn't listed in
SyncSettings.ExtensionAssemblies you'll receive a an exception like this:
System.ServiceModel.Dispatcher.NetDispatcherFaultException: 'The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter :GetApplicationResult. The InnerException message was 'Element ':item' contains data from a type that maps to the name 'http://schemas.datacontract.org/2004/07/CompAnalytics.Contracts:ModuleInputCollectionOfTableColumnTypeBWskODFT'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver if you are using DataContractSerializer or add the type corresponding to 'ModuleInputCollectionOfTableColumnTypeBWskODFT' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to the serializer.'. Please see InnerException for more details.'
Because this error occurs during deserialization of the DataFlow contract, there's no direct way to see the DataFlow name or the module that caused the issue, but if running in debug mode in Visual Studio you can look for the
appId variable to retrieve the id of the dataflow that failed and search on the source Composable instance with
id:12345 to find the offending DataFlow. The inner exception message will provide some hints for what module is causing the issue. In this case, note the reference to "'ModuleInputCollectionOfTableColumnTypeBWskODFT'"; if we go to the DataFlow we find the Xlsx Reader module has a
ColumnTypes input of type
List<TableColumnType> (hover over an input to see its type).
Thus we need to add
SyncSettings.ExtensionAssemblies and an reference to the DLL.
Missing DataFlows or QueryViews
Another common issue that can cause a deployment failure is a DataFlow or QueryView that references another DataFlow or QueryView that is not in the set of synced folders. Because such references need to be updated to continue working correctly on the target instance, all referenced DataFlows or QueryViews must be a part of the sync. References can cross between folders, but all folders must be included as the
FolderMapping.Source for some folder mapping.
If a synced DataFlow references another DataFlow that's not a part of the sync, you'll get an
InvalidOperationException with the ID of the missing DataFlow. You can search on the source Composable instance with
id:12345 to find the referenced DataFlow. If this DataFlow is one that should be synced, either add it to a folder that is being synced or add the folder that it's already in to the sync. Be sure that this is safe to do with regard to folder permissions and/or other resources in the same folder. If the referenced DataFlow should not be synced, you can find which other DataFlows reference it on the right hand side of the DataFlow page by clicking "Referrers":
The DataFlow that was failing during sync will be one of these, so you can edit it to remove the incorrect reference.
The error message and troubleshooting steps are similar for references to QueryViews from either DataFlows or other QueryViews.
Also note that the missing source behavior can be modified by the Optional Settings.
Old References in Unsynced DataFlows
To allow for cases where some DataFlow may be necessary only on a target instance that requires a reference to a synced DataFlow, by default the deployment API will scan the target instance for references to synced DataFlows and attempt to update them so they continue working as they did before the sync, but with the new version of the referenced DataFlow. If this upgrade step has been disabled via the settings (see Optional Settings) or the upgrade is compatible with the target DataFlow it may be necessary to manually delete the reference and re-add it after deployment.
Most matching of resources between source and target instances is done by name. This is scoped down to the folder level (and by resource type), with the exception of special logic intended to handle the case of moving a resource between synced folders.
If a resource cannot be found in its target folder, another search will be made for a resource of that name and type in any target folder. If such a resource is found (and has not already been identified as another synced resource), it will be treated as a folder change. Thus, while it is generally safe to have multiple resources of the same name and type in different synced folders, some issues may arise if one of these resources is added or removed. Any folder change will be accompanied by a printed warning message, so be sure to double check that these changes are correct and manually fix any incorrect changes.