Posts Tagged 'XAML'

Dynamically Accessing Large Resource Files in XAML at Runtime

WPF provides ResourceDictionaries as a convenient way of adding resources like Styles to your application to be accessed when needed. However, if a non-executable resource gets very large and/or is used infrequently, resource files are a better choice than ResourceDictionairies.

With WPF applications you can incorporate any non-executable resources (including data files, images, audio, and video) into your application using a variety of schemes. You can even put XAML in a resource file so that you can download parts of your UI at runtime. However, if you’d like to avoid downloading/distributing the file until the user actually needs it, a site of origin resource file is your best choice. Site of origin files aren’t compiled into your application’s EXE or distributed with it (they’re not even copied to the location specified when you publish your application). Instead, they’re picked up at run time when your code accesses them.

Site of origin files are also a good choice in two other scenarios. First, if you have some content that is going to change frequently you can store the file on your website where you can update them as needed and let your applications pick them when they want them. Secondly, if your application is going to load different files depending on settings in the local configuration file, the identity of the local user, or any other basis for customization, you can put multiple versions of the file on your site and download them as needed.

Using site of origin files also avoids requiring your application to be granted full trust. In WPF you can often set properties (usually the Source property) on an element to a URI that points to a resource. For instance, you might use an Image element like this:

<ImageSource= />

However, this option requires that your application be granted full trust. Site of origin files require only partial trust.

Implementing Site of Origin Files

The first step in using a site of origin file is to add it, or smaller stand-in for it, to your project in Visual Studio. After adding the file (or its stand-in) to your application, select the file and set its Build Action to None (this prevents the file from being compiled into your application).

At run time, you can download your file with code when the file is actually needed. The first step is to create an Uri object passing the location of the file with the pack and siteoforigin prefix:

Dim sooUri As New Uri(
"pack://siteoforigin:,,,/MyGrid.xml", UriKind.Absolute)

Once you have created the Uri, you may be able to just set the Source property of the control you want to use your file to the URI. This sets the Source property on a Frame, for instance (and assumes that the xml file downloaded in the previous example contained valid XAML):

Me.Frame1.Source = sooUri

However, this approach forces the framework to do any type casting or conversions for you. If you’re willing to write a little more code, you can take control of the process and ensure that the conversion is done the way you want. The first step is to create a StremResourceInfo object by calling the Application object’s GetRemoteStream method, passing your Uri:

Dim info As StreamResourceInfo = Application.GetRemoteStream(soouri)

Your next step is create a read object object to process the file. You call the reader’s LoadAsync method, passing the stream property of your StreamResourceInfo object. You’ll need to cast the output of this method to the right type. Assuming that that I’m downloading a XAML file containing a Grid, I’d need to create a XamlReader and cast the output as Page, like this:

Dim xrdr AsNewSystem.Windows.Markup.XamlReader() 
Dim grd As Grid = CType(reader.LoadAsync(info.Stream), Page)
Me.Frame1.Content = grd 

After publishing your application, it’s just a matter of dropping the file into the folder with the setup.exe file and your application will download it when your code executes.

Peter Vogel

Understanding Windows 8 Metro-Style Apps and WinRT

I’ve heard some misconceptions surrounding Windows 8 development. The first one is Microsoft is killing Silverlight. The second is Microsoft is favoring HTML 5 and JavaScript for developing Windows 8 applications over XAML and C#. The third is Microsoft is replacing the .NET Framework with a new framework called WinRT.

Understanding Windows 8 Metro Apps

Windows 8 will include a new Start screen similar to Windows Phones. The Start screen will have tiles that represent programs. Clicking on a tile will start the program. The thing that makes a tile different from an icon is a tile can contain live information. For example, the tile for an e-mail program might include the number of messages in the in-box. Tiles are also big. This allows them to not only contain live information, but also makes them optimized for touch screens.

When a tile is selected, a traditional Windows application or a Metro-style application might start. Traditional Windows applications will run on the Windows desktop. Metro-style apps will run in full screen, like an application on a phone or tablet. Metro-style apps will also have their own controls and idioms optimized for touch. Microsoft has claimed that in a couple years nearly all computers will have touch-enabled screens.

Understanding WinRT

WinRT is the framework used to build Windows 8 Metro-style apps. It is a native Windows API that is optimized for Windows 8 Metro-style UIs, and not a part of the .NET Framework. Metro-style apps can be created using WinRT three ways: with XAML and unmanaged C++, with XAML and C# (or VB), or with HTML and JavaScript. For the third option, Microsoft has created a JavaScript API that allows access to WinRT and some custom HTML tags that understand the WinRT controls.

So, let’s clear up the misconceptions

First, Microsoft is not “killing” Silverlight. Silverlight will be used where appropriate. For example, when a program needs to run on both a PC and a Mac.

Second, by allowing Web developers to use languages they are comfortable in (namely HTML and JavaScript), it doesn’t mean Microsoft intends that to be the development platform of choice. The strength of HTML and JavaScript is support for any platform. Once an application uses the WinRT JavaScript library, it’s a Windows app, not a Web app. I suspect most developers will choose XAML and C#, as it will be more productive.

Third, the .NET Framework is not going away. WinRT applications will still need to access services, write to databases, and not all applications will be Metro-style applications.

Getting Ready for Windows 8 Development

Windows 8 and Metro-style apps offer exciting new opportunities for developers. Whether you are a C++, Web or .NET developer, you will be able to leverage your existing skills to create great new applications for you users. If you want to learn more about developing Windows applications using XAML come to Learning Tree course 975: WPF and Silverlight Introduction: Hands-On.

Doug Rehnstrom

Learning Tree International

.NET & Visual Studio Courses

Learning Tree offers over 210 IT training and Management courses, including a full curriculum of .NET training courses.

Free White Papers

Questions on current IT or Management topics? Access our Complete Online Resource Library of over 65 White Papers, Articles and Podcasts

Enter your email address to subscribe to this blog and receive notifications of new posts by e-mail.

Join 29 other followers

Follow Learning Tree on Twitter


Do you need a customized .NET training solution delivered at your facility?

Last year Learning Tree held nearly 2,500 on-site training events worldwide. To find out more about hosting one at your location, click here for a free consultation.
Live, online training

%d bloggers like this: