Troubleshooting Relative URI’s in Silverlight Projects

My Visual Studio Solution contains a minimum of a project for the Silverlight application and a project for the web page that hosts the Silverlight application. The Silverlight application reads and rights files to the local file system.

The solution is structured similar to this:

mySolution (has a minimum of the following two projects)

• MyApplication.Web - the project that hosts the Silverlight xap file (could be a simple index.html page and Silverlight.js javascript page)
• MyApplication - the Silverlight application project

When debugging in Visual Studio, the files that the Silverlight application is trying to read from are not necessarily available to the application depending on how you structure the application and which project you put the data files into initially.

While under development, intuition may lead you to believe that if it is the Silverlight application that is actually reading the files, the Data folder should be placed in the Silverlight application project root, not the web project. That would be incorrect.

Example 1

new Uri("/Data/ReadThisFile.xml", UriKind.Relative)

UriKind.Relative with a leading slash (/) in front of the Data folder is relative to the page that is hosting the XAP file. In my solution this is the project root of the web application, not the Silverlight project. The data file would be located at f:\mySolution\myApplication.Web\Data\ReadThisFile.xml

Example 2

new Uri("Data/ReadThisFile.xml", UriKind.Relative)

Without the leading slash in front of the Data folder as in this example, the file is expected to be relative to the Silverlight xap file. In my solution the xap file is in the default location, the ClientBin folder, which is a sub folder of the project root of the web application. The data file in this case would be located at f:\mySolution\myApplication.Web\ClientBin\Data\ReadThisFile.xml

Troubleshooting with Process Monitor

If you are getting File not found exceptions, the file isn’t where your application thought it was supposed to be. A relatively easy way to find out where the application is looking for the file is to use SysInternals Process Monitor.

Once you install and run the Process Monitor, you can set the filters to narrow down the captured events to locate the path to the file. The primary filters I used were “Result is not SUCCESS” and “Path contains ReadThisFile.xml”

 

The filtered results would look similar to the following, if the the application throws a File not found type of error. (click to enlarge)