In a chalktalk yesterday, I demo-ed a modified PhotoStore application (you may have seen this demo at last year’s PDC or played with it in the Hands on Labs). In this version, you can display images bundled with the app as well as those located in your “My Pictures” directory.  This works fine as standalone app because it runs in full trust.  However, the sandboxed XBAP does NOT have FileIOPermission, and so fails with a SecurityException. To make both XBAP & Standalone work with the same code base, I demoed the compile switching, runtime switching, and XAML switching tips I wrote about last week.  You can get code here.  Or …

An interesting overview of Vista Security is now posted on MSDN.

In my previous post, I introduced my FlexibleApplication template. In this posts, I offer a couple tips & tricks. Determing the App Model at Compile Time or Runtime Depending on your application, you may want to do different things in the standalone and XBAP version. The Flexible Application template adds some goo (i.e. compilation constants & static helpers) to make doing this easier for you. Conditional compilation: #if XBAP //  XBAP specific code #else //  Standalone specific code #endif Runtime switching: if (MyApp.IsXBAP) { //  XBAP specific code } else { //  Standalone specific code } XAML switching: <Grid> <Grid.Resources> <BooleanToVisibilityConverter x:Key=”BoolToVis” /> </Grid.Resources> …

In WPF, we support two main app models: standalone and XBAP. Standalone apps are akin to traditional Windows apps. They run in their own window. They tend to be fully trusted (unrestricted access to the computer and its resources). And they are installed (either via an MSI, ClickOnce, or EXE distribution). XBAPs, on the other hand, are browser hosted applications. They’re cached (using ClickOnce) and sandboxed. Users navigate to them (promptlessly) in the browser like they do any other website. (XBAP whitepaper & sandbox whitepaper) What’s great then is, if you’ve written your app in a security & navigation friendly …