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]]

J.Marsch <jm*****@newsgr oup.nospam> wrote:

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.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[J.Marsch]

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]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

J.Marsch <jm*****@newsgr oup.nospam> wrote:

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.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

J.Marsch <jm*****@newsgr oup.nospam> wrote:

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.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[J.Marsch]

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

-- Jeremy

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

J.Marsch <jm*****@newsgr oup.nospam> wrote:

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.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too