Loading Image Resources

[J.Marsch]

Building a large app where we want to be able to ship updated icons like
patches/assign different "skins", etc.

So, I'm looking at storing sets of related icons in assemblies that will be
loaded dynamically.

Some questions:

What's the "best practices" way to load an assembly where its only purpose
is to provide resources?

In my simplistic view, I would just do something like this:
{
Assembly theAssembly = Assembly.LoadFi le(theFileName) ;
Image theImage =
Image.FromStrea m(theAssembly.G etManifestResou rceStream(resou rceID));
}

Now, I'm not looking for the "quick fix" here, this needs to be durable and
enterprise-grade. Is there somewhere else that I should be looking?

I thought about the resource manager, but it seems to be all about
internationaliz ation, and that's not really what I'm trying to solve here.

[Jon Skeet [C# MVP]]

Re: Loading Image Resources

J.Marsch <jmarsch@newsgr oup.nospam> wrote:[color=blue]
> Building a large app where we want to be able to ship updated icons like
> patches/assign different "skins", etc.
>
> So, I'm looking at storing sets of related icons in assemblies that will be
> loaded dynamically.
>
> Some questions:
>
> What's the "best practices" way to load an assembly where its only purpose
> is to provide resources?
>
> In my simplistic view, I would just do something like this:
> {
> Assembly theAssembly = Assembly.LoadFi le(theFileName) ;
> Image theImage =
> Image.FromStrea m(theAssembly.G etManifestResou rceStream(resou rceID));
> }
>
> Now, I'm not looking for the "quick fix" here, this needs to be durable and
> enterprise-grade. Is there somewhere else that I should be looking?
>
> I thought about the resource manager, but it seems to be all about
> internationaliz ation, and that's not really what I'm trying to solve here.[/color]

One way to make things simpler might be to include a single type in the
resource assembly - that way you can make sure the assembly is loaded
(and get a reference to the Assembly object) just by using
typeof(TypeInRe sourceAssembly) (etc).

Now, if you've already got a type within the assembly, you could make
that some kind of ImageManager type which is able to load the resources
requested and return images directly.

Does that help at all?

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[J.Marsch]

Re: Loading Image Resources

Actually, yes that does help. I still think that I am going to have to load
the assembly dynamically, but it might be handy to have a manager sitting in
there to help with pulling out the resources -- I'll have to noodle on that
a bit.

Oh, and here's why I _think_ I need to do dynamic loads (I'm not dead-set on
that idea yet):

These icons might change as a result of a user preference. For example:
today maybe the set of icons in the assembly supports the "blue" XP look.
Maybe next week, we ship a download that supports the "silver" XP theme, and
maybe next year we toss one out that is more appropriate to Longhorn.

Even that is a simplification. There is a specific type of partition (think
of it as a business entity) in this system, and the user can associate
different color schemes with different entities. As they move from entity
to entity, the application will change in obvious ways (different large
icons and headings), and subtly (different accent colors and tree icons,
etc).

So these resource assemblies are sort of like extensions, or plug-ins but
they do not offer code, just alternate resources. In some ways, that is
kind of like internationaliz ation; it's just that the selection of the
resource set is not tied to culture.


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1d1bf6 93425c9b8998c32 3@msnews.micros oft.com...[color=blue]
> J.Marsch <jmarsch@newsgr oup.nospam> wrote:[color=green]
>> Building a large app where we want to be able to ship updated icons like
>> patches/assign different "skins", etc.
>>
>> So, I'm looking at storing sets of related icons in assemblies that will
>> be
>> loaded dynamically.
>>
>> Some questions:
>>
>> What's the "best practices" way to load an assembly where its only
>> purpose
>> is to provide resources?
>>
>> In my simplistic view, I would just do something like this:
>> {
>> Assembly theAssembly = Assembly.LoadFi le(theFileName) ;
>> Image theImage =
>> Image.FromStrea m(theAssembly.G etManifestResou rceStream(resou rceID));
>> }
>>
>> Now, I'm not looking for the "quick fix" here, this needs to be durable
>> and
>> enterprise-grade. Is there somewhere else that I should be looking?
>>
>> I thought about the resource manager, but it seems to be all about
>> internationaliz ation, and that's not really what I'm trying to solve
>> here.[/color]
>
> One way to make things simpler might be to include a single type in the
> resource assembly - that way you can make sure the assembly is loaded
> (and get a reference to the Assembly object) just by using
> typeof(TypeInRe sourceAssembly) (etc).
>
> Now, if you've already got a type within the assembly, you could make
> that some kind of ImageManager type which is able to load the resources
> requested and return images directly.
>
> Does that help at all?
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: Loading Image Resources

J.Marsch <jmarsch@newsgr oup.nospam> wrote:[color=blue]
> Actually, yes that does help. I still think that I am going to have to load
> the assembly dynamically, but it might be handy to have a manager sitting in
> there to help with pulling out the resources -- I'll have to noodle on that
> a bit.
>
> Oh, and here's why I _think_ I need to do dynamic loads (I'm not dead-set on
> that idea yet):
>
> These icons might change as a result of a user preference. For example:
> today maybe the set of icons in the assembly supports the "blue" XP look.
> Maybe next week, we ship a download that supports the "silver" XP theme, and
> maybe next year we toss one out that is more appropriate to Longhorn.
>
> Even that is a simplification. There is a specific type of partition (think
> of it as a business entity) in this system, and the user can associate
> different color schemes with different entities. As they move from entity
> to entity, the application will change in obvious ways (different large
> icons and headings), and subtly (different accent colors and tree icons,
> etc).
>
> So these resource assemblies are sort of like extensions, or plug-ins but
> they do not offer code, just alternate resources. In some ways, that is
> kind of like internationaliz ation; it's just that the selection of the
> resource set is not tied to culture.[/color]

Right. That seems pretty reasonable, yes. You may want to think about
organising your resources in the same way as for cultures, with a
hierarchy (which in your case may be arbitrarily deep). So, for
instance, you might have:

MyResources
MyResources-Windows
MyResources-Windows-XP
MyResources-Windows-XP-Silver
MyResources-Windows-XP-Blue
MyResources-Windows-Longhorn
MyResources-Linux
MyResources-Linux-Gnome
MyResources-Linux-KDE

with each deferring requests for any unfound resources to its "parent".

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[J.Marsch]

Re: Loading Image Resources

Yes, that makes sense. Thank you for the commentary, Jon.

-- Jeremy



"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1d1c00 a7e112240a98c32 7@msnews.micros oft.com...[color=blue]
> J.Marsch <jmarsch@newsgr oup.nospam> wrote:[color=green]
>> Actually, yes that does help. I still think that I am going to have to
>> load
>> the assembly dynamically, but it might be handy to have a manager sitting
>> in
>> there to help with pulling out the resources -- I'll have to noodle on
>> that
>> a bit.
>>
>> Oh, and here's why I _think_ I need to do dynamic loads (I'm not dead-set
>> on
>> that idea yet):
>>
>> These icons might change as a result of a user preference. For example:
>> today maybe the set of icons in the assembly supports the "blue" XP look.
>> Maybe next week, we ship a download that supports the "silver" XP theme,
>> and
>> maybe next year we toss one out that is more appropriate to Longhorn.
>>
>> Even that is a simplification. There is a specific type of partition
>> (think
>> of it as a business entity) in this system, and the user can associate
>> different color schemes with different entities. As they move from
>> entity
>> to entity, the application will change in obvious ways (different large
>> icons and headings), and subtly (different accent colors and tree icons,
>> etc).
>>
>> So these resource assemblies are sort of like extensions, or plug-ins but
>> they do not offer code, just alternate resources. In some ways, that is
>> kind of like internationaliz ation; it's just that the selection of the
>> resource set is not tied to culture.[/color]
>
> Right. That seems pretty reasonable, yes. You may want to think about
> organising your resources in the same way as for cultures, with a
> hierarchy (which in your case may be arbitrarily deep). So, for
> instance, you might have:
>
> MyResources
> MyResources-Windows
> MyResources-Windows-XP
> MyResources-Windows-XP-Silver
> MyResources-Windows-XP-Blue
> MyResources-Windows-Longhorn
> MyResources-Linux
> MyResources-Linux-Gnome
> MyResources-Linux-KDE
>
> with each deferring requests for any unfound resources to its "parent".
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]