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)

Mind your Copy to Output Directory Setting on Writeable Files

I’m used to doing more web development so I sometimes forget that just because an application writeable file (.xml, .csv, .sdf, .txt, etc.) resides in the project root directory structure, doesn’t mean that is the actual file that is getting written to when developing WPF applications. Depending on the “Copy to Output Directory” setting, that actual file may or may not get copied to the bin/Debug folder which is where the executable program resides (when debugging).

The “Copy to Output Directory” setting options are:

• Do not copy – If you use this option, but you make changes to the copy in the project directory, the changes will not get copied to the bin/debug directory which the executable uses at runtime.
• Copy if newer – Be careful with this if you are sloppy about making changes in one location one time, and another the next. What changes are overwritten with each compile can be unpredictable.
• Copy always – Caution: If you use this, understand that if you make manual changes to the copy in the bin/debug directory, your changes will be overwritten by the version in the project directory at the next compile of the project.

Local Database Cache example

I created a WPF application that stores data locally on the client in a SQL CE (.sdf) database which periodically synchronizes with a server based SQL Server database. Since SSMS 2005/SQL Profiler does not have the ability to connect to a SQL CE database to view the data in the .sdf file, I created a quick “diagnostic” Windows Forms client to peek into the local client database to view the data to make sure the WPF program was operating as expected. I pointed the “diagnostic” Windows Form connection string to the .sdf file in the project root directory, then started changing the data using the WPF application. The Windows Form was not showing the data changing, but the remotely synch’ed server side SQL Server was. What’s going on here?

Oh yeah, that’s right… the Windows Form was looking into the original client database that was created with the local database cache Visual Studio project wizard at the project root - not the live copy that was running out of the bin/Debug directory (See the Solution window screenshot). After I figured that out, I changed the connection string on the “diagnostic” Windows Form app to look at the .sdf file in the bin/Debug folder. Then in order to avoid getting confused about the data I was looking at between the remote database and the local client side database I needed to make sure I understood when the .sdf file in the project root directory was going to get copied into the bin/Debug folder upon recompile via the “Copy to Output” settings on the .sdf file.

Create Excel files on the fly with ASP.net

Numerous articles have been written about this topic, but since all projects are different I will summarize my experience based on a recent project. This is not intended to be a tutorial as there is already a wealth of tutorials and instructions for how to accomplish each of the following methods.
Selection of the method can be difficult because you need to balance the versions of Office the users have available with the importance of specific Excel related formatting and features with performance.
Office XP/2003 users only XML/XSLT :
Using XSLT to create Excel spreadsheets (Office XP/2003 only) is a great simple method that provides a high level of formatting ability such as adding Conditional formatting, styling, etc very easily. Be cautioned that when creating spreasheets using XSLT with more than a couple hundred rows, performance degrades quickly and it can take upwards of several minutes to create the file. Sure the performance can be improved by optimizing the XSLT template, but rendering a couple thousand rows of data will still be frustrating to most users.
Office 97-Office 2007 Office XML:
You can use the new native Office XML format of the Office 2007 products to create the file, but since it is still a relatively new technology, there is not as much documentation available to make quick work of the project. Additionally your user's running Office versions earlier than 2007 will need to be able to download and install the Office 2007 compatibility kit.
Office 97-Office 2007 HTML:
You can create HTML files and output to the stream with a response.ContentType of application/vnd.ms-excel and Excel will open the HTML into Excel. This method provides a good balance of speed, and the ability to format the cells and even add formulas to the cells. This method can be a little confusing to the users when they change some data in the spreadsheet and try to save the file. This is even more advantageous if what you want to export is in the form of a datagrid that you can override the rendering method to output the Datagrid HTML directly to the response stream instead of manually building the HTML table.
Office 95-Office 2007 csv or tsv:
This is the most compatible method, but provides the least flexibility with formatting or other Excel specific functionality.