I’ve seen this come up a number of times recently on the MSDN forums–apps that are using what appears to be a valid relative URI in the app package, like images/someImage.png, but that URI fails to work as expected. This happens from within HTML, CSS, and JavaScript.

Most often this error is caused by using such a reference from inside a WinJS page control, where the context for relative URIs is the page HTML file itself, not the default.html page that into which it’s loaded. That is, from a default.html page in the package root (or a CSS file on that level), a relative URI to a folder that’s exists on the same level in the package will work. However, page controls are typically stored in subfolders, like pages/home/home.html (and .css), in which case a relative URI would start at pages/home and look there.

In such cases, you could go up to parent folders, e.g. ../../images/someImage.png where the first two ..’s would go up from pages/home to the package root. This is somewhat fragile, however, and would break if you ever relocated the page control’s html tile in your project.

The best solution in such cases is to be sure to prefix the URI with a /, as in /images/someImage.png. The leading / means “package root” and properly references resources within the app package. This makes the URI an absolute URI in relation to the package root, and is effectively a shortcut for the true absolute URI form: ms-appx:/// or ms-appx://<package_id>/ (which says the package_id is optional). The leading / is thus the same as prefixing URIs with ms-appx:/// (the triple-slash version).

When in doubt, then, if some URI just isn’t working, especially with page controls, try preceding the URIs with a /.

Comments are closed