Quick Tip: Cross Domain Policy Problems With Web Services / Silverlight

More a note to myself more than anything. If you have a Silverlight application that is invoked from a domain and then making calls to a SharePoint web service in a different domain, you may encounter the following error:

An error occurred while trying to make a request to URI ‘http://sharepoint/stuff/morestuff/superservice.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.

The fix is to place copies of the crossdomain.xml and clientaccesspolicy.xml files in the root application folder. Works fine afterwards.


Managing Data Connections and Universal Data Connection V2 (UDC) Files

InfoPath exposes several external data sources that are available for consumption either as a primary or secondary data connection. Most of the consumed data connections can be called from within the Data Connection Wizard that InfoPath provides. When using the Data Connection Wizard, you can choose to create a new data source for fetching or submitting. In relation to SharePoint, it is possible to crawl a Microsoft Office Server instance to harvest available data connections, by only supplying the site that you wish to crawl as an argument, usually the site from which the InfoPath .XSN is going to be made available.

The InfoPath data sources are:

  • Microsoft Office Access database
  • Microsoft SQL Server database (a browser enabled form cannot be submit to a database directly)
  • Email
  • Web service
  • XML file
  • HTTP Post
  • Web service
  • SharePoint Document Library or List

UDC Files

The most manageable way to service users creating InfoPath forms is to provide the data connections by storing UDC files in SharePoint Data Connection Libraries (DCL). UDC’s are a method of black-boxing data connections to hide the piping of the data connection, and call the relevant forms. By doing this, the connection used by the InfoPath form is not held within it, but called when needed at run-time from the DCL, so can be requested from any number of InfoPath forms. This allows the management and consolidation of data connections so if a specific database or web service is frequently used by several enterprise forms, it can be entered once, and called many times, while the actual data connection architecture is black-boxed.

Figure 14-3

Because the UDC files are held within what is basically a specialized SharePoint Document Library, there are granular levels of security that can be applied. Similar to the SharePoint Document Libraries, Contributors on the site can submit content, meaning new UDC files. However, within a DCL only UDC’s that have been approved can be consumed by any number of deployed InfoPath forms.

UDC files, like other InfoPath assets, are composed of well-formed XML. UDCs, like other document blueprints that are stored in Office Server 2007, are stored as content types. Content types, in order to provide the appropriate metadata will push the relevant properties to populate the needed columns using <FieldRefs> element when stored within the SharePoint Data Connection Library. When building custom UDC files, there are two ways for a developer to approach it. The first is using the inherent Conversion functions that are offered through InfoPath. Using the Convert option in the Manage Data Connections section of InfoPath, it is possible to publish a UDC file to a SharePoint Data Connection Library. The other way is to hand craft UDC files since it is composed of just XML elements. Some of the elements that compose a UDC file are optional, while others are required for it to function (see the following table).

General UDC File Elements

Element Name


Element Description




The ContentTypeID element specifies the diagram blueprint that will be used to populate the columns that are used in the Data Connection Library. To gather some of this information, this element couples with the name and description elements.




Defines the UDC namespace and the version.




Optional element that declares name information about the UDC file, used to populate information in the SharePoint Data Connection Library.




Optional element that declares description information about the UDC file, used to populate information in the SharePoint Data Connection Library.




Required element which defines the data type that the UDC is using, such as a web service or database.




Describes the purpose of the connection, whether it is Read/Write/Both, as well as describing how the actual connection is made to the back-end data source.


ConnectionInfo for SharePoint List

The most populated portion of the UDC file is the ConnectionInfo element, which defines where the actual consumed datasource is located. A common UDC file is one that queries a frequently hit SharePoint list to gather values. In order to construct a SharePoint list UDC file, within the ConnectionInfo element, specify the SelectCommand element to grab the relevant values by passing in the ListId and WebUrl child elements.


<udc:ConnectionInfo Purpose=ReadOnly>


Web Service ConnectionInfo

Optionally to collect list items from a SharePoint list the SharePoint lists.asmx web service in the _vti_bin directory can be called and used in the same type of fashion as the above. Since the Lists.asmx WebService allows using the GetListItems operation, it is possible to retrieve list values using this web service by supplying a few parameters. This could be manipulated as well to include other web services outside of SharePoint if there are other external sources that house the desired values.


<udc:ConnectionInfo Purpose=ReadOnly>


One of the most frequently confusing things in terms of web services is the authentication scheme that is used in order to verify the requesting user against the web service. For most web services, it is common that a service account will be used in order to pass the appropriate credentials to the service, however InfoPath 2007 does not contain a native method to implement .NET impersonation such as that provided by the WindowsIdentity class in .NET commonly known as double hop authentication problem . However, this facility is provided through the inherent Web Service Proxy Configuration that is provided by Forms Server 2007 which will allow the users working with the InfoPath form to harvest values out of the web service on behalf of the service account as opposed to passing the requesting users login token. In order to use the Web Service proxy, it is necessary for the <udc:ServiceUrl> parent element to have the UseFormsServiceProxy attribute set to a value of 1.