1

I've seen how to load an image in Silverlight and how to load an image in WPF, but I can't figure out how to load an image using the same XAML for the Silverlight and WPF flavors of a composite Prism app. Ideally I'd like to do something like:

<Image Source="/Resources/Images/foo.png"/>

A relative URI that uses the component notation won't work because the Silverlight and WPF assemblies are named differently (on purpose, for sanity). I'm using Silverlight 4 and .NET 4.0.

Mike Post
  • 6,355
  • 3
  • 38
  • 48
  • 2
    Maybe just a smidge off topic, but we just went through the same naming sanity check, and the way they did it in the Prism samples really struck a chord: The assemblies have the same file name, but the csproj files for silverlight have .Silverlight appended to the end. So in solution explorer, its MyProject.Silverlight, but the assembly file is just MyProject.dll. That gives you your design-time sanity, but same assembly names. (see the stock trader RI sample for an example) – JMarsch Apr 05 '11 at 21:59
  • @JMarsch: I think that is an answer? – Anderson Imes Apr 06 '11 at 11:18
  • @Anderson Imes -- I'll repost, so you can mark an answer! – JMarsch Apr 06 '11 at 13:54

3 Answers3

3

You could do the following. Define URIs for images in a separate resource dictionary. Then WPF and Silverlight projects will define their own dictionaries that will be referenced by the shell project. Here is an example:

<BitmapImage x:Key="Foo">/Resources/Images/foo.png</BitmapImage>

-

<Image Source="{StaticResource Foo}"/>
Pavlo Glazkov
  • 20,498
  • 3
  • 58
  • 71
  • There's no perfect solution, but this one seems to balance tooling support (see my other comment) and solving the problem. Thanks! – Mike Post Apr 06 '11 at 18:08
2

(reposted from my comment as an answer)

We just went through the same naming sanity check, and the way they did it in the Prism samples really struck a chord: The assemblies have the same file name, but the csproj files for silverlight have .Silverlight appended to the end. So in solution explorer, its MyProject.Silverlight, but the assembly file is just MyProject.dll. That gives you your design-time sanity, but same assembly names. (see the stock trader RI sample for an example)

JMarsch
  • 21,484
  • 15
  • 77
  • 125
  • I really really want to use this solution, but it breaks down when you use tools like ReSharper: if you're adding an unreferenced type in XAML and use RS to add the reference, it's too easy to pick the wrong assembly (SL when you want WPF and vice versa). I think preserving the names is important until the supporting tools get better. – Mike Post Apr 06 '11 at 18:07
  • Ah -- I haven't used resharper, and didn't consider the XAML angle. I guess from there, they do it by assembly name and not project name? – JMarsch Apr 06 '11 at 19:24
  • Yes, they go by assembly name and not project name. I'll be filing a bug later today that they allow you to reference a WPF assembly from a Silverlight project. It should be smart enough to know the difference IMO. – Mike Post Apr 07 '11 at 16:31
1

I was thinking something similar to Pavlo. What about a custom MarkupExtension?

Something like

<Image Source="{PathResolver BasePath=/Resource/Images/foo.png}" />

Where Base path is some relative portion of the path that you can use to resolve a full path based on the target environment (WPF or Silverlight)

Pavlo's solution is a little cleaner I think but the custom markup extension might give you more flexibility and they are trivial to create

Brad Cunningham
  • 6,402
  • 1
  • 32
  • 39
  • That won't work for Silverlight 4 and below, custom MarkupExtensions are planned to debut in v5. – dain Apr 06 '11 at 14:04
  • ah, good call, I haven't worked with Silverlight lately forgot it lacks custom markup extensions. Good to know it is coming soon – Brad Cunningham Apr 06 '11 at 16:45