Site Sections
Posts
49
Comments
83
Trackbacks
0
April 2008 Entries
Pack URI Authority - Local Assembly = Executable

I had a post about accessing XAML resources using Pack URI, and actually had the chance to try it out.  The format of the pack URI is "pack://authority/path", and there are only 2 valid authority: application:/// and siteoforigin:///, as described in Microsoft's Pack URI documentation.

The path will just point to the resource you want to get; you can include the folder / subfolder, other assemblies (containing the resource), even versions of the assembly.  The simplest example they had was:

pack://application:,,,/ResourceFile.xaml

that points to ResourceFile.xaml in the local assembly.  What the documentation forget to define however, is what is local assembly; the local assembly is essentially the WPF executable.  If you have other XAML in a different assembly, and you have code in that same assembly to load the XAML using Pack URI, you have to treat it as if you're loading from a different assembly.

As an example, if you have a WPFResource.DLL which has a XAML resource (in this case test.xaml) you'd like to load, the code to load it will be as follows:

private static void InitializeWPFApplicationResources()
{
   Uri uri = new Uri("pack://application:,,,/WPFResource;component/test.xaml");
   Application.Current.Resources.Source = uri;
}

 The Pack URI has to refer to an external assembly - even though test.xaml resides in the same assembly with the executing code.  Anytime the pack URI doesn't refer to a different assembly, it will try to load the XAML resource from the executable file - I'm actually surprised with this, since it forces the Uri to always contain the assembly name which can be erroneous (say the assembly gets renamed).  Granted you can get around this problem by getting the assembly's name in code.

posted @ Wednesday, April 30, 2008 11:02 AM | Feedback (1)
Files downloaded by IE are marked Untrusted (or why the CHM file I downloaded didn't work)

I downloaded a CHM (Windows help) file for SharpZipLib software package to be used in my test app (pretty cool - allows me to do most stuff relating to zip files), and when I open the help file, none of the information shows.

Of course when I tried to open it up, Windows always asks me to verify that I wanted to open the file, with the dialog below:

However, even if I do allow this, the CHM file doesn't show its contents; the IE control that should display the help contents only show that the Program cannot display the webpage.  It turns out that this is a side effect of an IE security update - downloaded files are marked as untrusted and thus will require user's verification before it can be opened.  However, even if you verify for opening the files, the file itself is still marked untrusted, and as such IE will not allow rendering the information on the screen.

To fix this, you'd have to mark the uncheck the 'Always ask before opening this file' checkbox, and you're good to go.  You can also go to the file's properties and click the Unblock button near the bottom.  This situation puzzles me for a few minutes before the light bulbs start switching on.  I'm pretty sure I will get this again in the future and be puzzled the same way .

posted @ Monday, April 28, 2008 4:53 PM | Feedback (0)
Refer to resources in WPF with Pack URI

It's been over 2 months since I last updated my blog.  I have been busy; we got a new VP of IT and he made some changes and there are a bunch of stuff that's getting rejigged and people moved, projects retargeted, etc. etc.  In the end, it's not enough reason for me to not blog at all.

I started this blog so I can record my experiences with learning new stuff.  I have to say that I came back to this blog more than enough times to relook at the stuff I had learnt, to the point where my lapse in adding new stuff actually prevents me from being very productive - I learned some stuff that I should've put in here but I didn't, and in the end have to relearn it again since I didn't record it. D'uh.

Anyway, I need to be more disciplined and will try to be more active.  Relearnt something today about how to access file resources in WPF, instead of using the typical StaticResource or DynamicResource - use Pack URIs, as further detailed here.  The 2 important ones for me to remember are referencing items in the same assembly and in a different assembly (use the following format with the Source attribute in xaml):

pack://application:,,,/ResourceFile.xaml

pack://application:,,,/ReferencedAssembly;component/ResourceFile.xaml

This is actually very relevant to me; sometime last week, we had decided on trying to consolidate all our resources into a single DLL for each team project we have - it helps with internationalization (minimizing the number of DLLs), easier checking for entries that may already exist, can be used by other applications / modules if necessary, and can be swapped with another resource DLL or a newer one.

With our application, we won't actually use the pack URI to point to different XAML (we may, but I see the use to be fairly limited in that regard), but we will use the pack URI to point to proper image / icon / bitmap files - so it's nice if we can consolidate all those files into a single DLL.

posted @ Monday, April 28, 2008 1:41 PM | Feedback (0)
Archives
Post Categories
News