Embeeded resources Vs. Content files

[Lonifasiko]

Hi all,

My application contains almost 50-60 images (.jpgs, .bmps, .icos....)
and a few MP3 and WAV files.
I'm including them in the project as embeeded resources and load then
by code with GetManifestResourceStream method from Assembly.

My final .exe is growing up and I now think it's already qiute heavy
(1.5 Mbytes).

Which would be the best way to do this? Continue using them as embeeded
resources or would be better to have the images and sounds in separate
folders inside the target directory, that is, acting as content of the
project instead of embeeded resources? How should I load them into the
application?

Which is the normal approach for this?

Thanks very much.

 

[Mark Arteaga]

I prefer embedded resources and usually put my resources in a seperate assembly
when it starts getting that big. You can also keep them in a folder in your
program runtime directory but then you might run into people modifying the
files etc.
________________________________________
Mark Arteaga
..NET Compact Framework MVP
http://www.neotericsdc.com | http://blog.markarteaga.com

 

[Lonifasiko]

So you mean, for example, building one assembly called
CompanyName.ProjectName.Resources
and using reflection, load resources from this assembly into the main
thread of the application, don't you?

I also like the option of having folders inside program runtime
directory. I think I'm not going to have problems with people modifying

files etc. However, how should I load these resources located in
different folders into my application?

Thanks very much. I would like to hear some more opinion around this
important issue.

Regards.

 

[Mark Arteaga]

You don't have to use reflection. You can have a static method called GetResource(string
resourceName) and it returns a stream. Loading the resources from a folder
depends on what you want to do with the resource. For example if it's an
image you want to display in a picture box just pass the path of the image
to the bitmap contructor and assign the bitmap to the picturebox. If you
need a stream load up a stream.

HTH
________________________________________
Mark Arteaga
..NET Compact Framework MVP
http://www.neotericsdc.com | http://blog.markarteaga.com

 

[Lonifasiko]

Sorry for my lapsus around reflection. I meant loading the
corresponding stream from the current executing assembly with
GetManifestResourceStream method. That is what I'm now doing nowadays.

I've also tried with images as content, loading them giving the path.
No difference at all!

Loading the resources from a folder
depends on what you want to do with the resource. For example if it's an
image you want to display in a picture box just pass the path of the image
to the bitmap contructor and assign the bitmap to the picturebox

For the example you mention above, loading an image to a picturebox,
which is what I do in 99% of the time, would be better to deploy my
images as content in a separate directory or in a separate DLL as you
said?

I want today to make up my mind and decide wether I use embeeded
resources approach or contents approach. It really hurries me so I
would like to hear more opinions please.

Thanks.

 

[Simon Hart]

I don't see the point in placing these resources in a satellite assembly
unless of course you are supporting localization (different locales).

If you are concerned with performance with a 1.5 meg exe, stripping your
resources into a separate resource dll will make no difference because the
minute you load that dll to access a resource, that dll will be loaded into
the AppDomain.

To get true performance gains, you will need to load the resources from disk
(not embed them or link them into a satallite) as and when you need them,
rather than the big performance overhead onload.

Cheers
Simon.

 

[Chris Tacke, MVP]

Having them as embedded resources makes updating images and strings in an
already-running environment simple. For example, many customers like to
have graphics customized for themselves. That's really the only reason,
other than localization, to do it.

-Chris

 

[Lonifasiko]

Simon,
Therefore you suggest to have an "Images" folder inside my program
runtime folder, from where I would load all the images my application
needs.
That would be "disk loading" I understand. Would this approach increase
performance of the application?

Having them as embedded resources makes updating images and strings in an
already-running environment simple.

Chris, my application is localized but all images are the same for all
languages. The update and adding process of images simple? If they are
as content, the process is the same.
It's cristal clear that in both the ways, if I want to reference and
load the new or updated images from my code, the application needs to
be recompiled. A pitty but true.

Thanks.

 

[Simon Hart]

If you are localizing your application, you certainly would not want to
embed your resources into the main UI assembly. You would typically devide
these resources into there dedicated culture specific assemblies.

Cheers
Simon.

 

[Simon Hart]

Yes it would increase performance onload because you won't be JITing a large
assembly during load. Rather loading each resource as and when you need
them.

How are you handling the string localization?

Cheers
Simon.

 

[Lonifasiko]

As I've told you in my previous post, I support localization, but only
for translating strings; no images, no sounds and no files. Perhaps in
the near future.

I'm handling localization using the new way VS.NET 2005 gives me, that
is, under the project, under "Properties" I've got a file named
Resources.resx, which is the default resource file, in Spanish. Then
I've added another file for English support, with the name
Resources.en-GB.resx. That's all.By code, I access like this:

txt1.Text = Properties.Resources.MasterForm_CannotReadFromRegistry;

When deploying the application, it is only created another folder with
the name "en-GB" which contains a satellite DLL with the string
resources in English.

I think I'm going to follow your advice and deploy all images as
content.

If you are localizing your application, you certainly would not want to
embed your resources into the main UI assembly. You would typically devide
these resources into there dedicated culture specific assemblies.

That would be supposing I localize also images, sounds and so
on.....wouldn't be?

Thnaks very much.

 

[Simon Hart]

I think I'm going to follow your advice and deploy all images as

content.

Time your application in both methods, (using ebedded resources and as
content).

How long does it take for your main form to show currently?

That would be supposing I localize also images, sounds and so
on.....wouldn't be?

Yes.

 

[j.edwards]

Isn't the beauty of JIT - that it compiles "just in time" - i.e. only the
objects you require get compiled when they are first needed? For instance,
if you build a big vb.net app but not much happens on the first form then it
loads really fast. Is it true that a whole assembly is compiled in the one
go? I thought it was just the bits and pieces it needed.

Anyhow, what compiling is required for a resource? Are you saying that the
whole dll will be loaded into the app domain including the resources, so if
you have a 1.5MB dll then as soon as you access it you will lose at least
1.5MB of available memory? The doubling of memory implication is a concern
if that's what happens.

 

[Daniel Moth]

Yes it would increase performance onload because you won't be JITing a

large assembly during load. Rather loading each resource as and when you
need

That is wrong. JITing occurs at the method level as and when the method is
called the first time only (and potentially again if the jitted code is
pitched due to a full GC). JITing plays no part in the context of this
discussion.

As for the issue of content vs embedded resources, I haven't looked at it in
detail but I *suspect*, it is a trade-off between memory and speed. I always
go for embedded resources but that is just a personal preference (not a
scientific choice).

Cheers
Daniel

 

[Simon Hart]

If you read the thread correctly, the discussion is not about code
assemblies rather resource assemblies. There is no methods/members to be
JITed only resources.

Packing your exe with loads of embedded resources over loading them when
required as a file stream is bound to be a performance overhead.

 

[Guest]

Why would there be any overhead? The app doesn't load all the resources
when it loads, it demand loads them when you tell it to. Sure, I'd like to
see some hard numbers on it, but I'd be surprised to see any difference
between using embedded resources or separate files. And separate files lead
to unstable deployments because you have to assume users are going to delete
or modify them (I've been deploying apps long enough to know this is true).

-Chris

 

[Simon Hart]

Surely the CLR requires what ever the size of the executable of memory to be
available on load, not nessessarily loading it into RAM at that time, but
making sure that footprint will happily load? I havn't done any numbers on
this however.
With regards to users deleting files this is really a non-issue. Users could
easily just delete a satallite DLL or any other critical file your
application requires. Just take a look in \Windows directory. You will find
hundreds of resources, I admit some exist in ROM but not all.

 

[Daniel Moth]

If you read the thread correctly, the discussion is not about code

assemblies rather resource assemblies. There is no methods/members to be

Simon, I read the thread carefully and I commented on it in my last para
(the one starting "As for the issue of content vs embedded resources...")

Are you not the same Simon Hart that said "you won't be JITing a large
assembly during load" ? So it is you that brought JITting into it and in
fact with an erroneous statement. It is that statement that is plain
incorrect and I wanted to make that clear to any future readers (e.g. in the
archives).

Back to the original question, as I said, I haven't measured the difference
as it never was important for my apps. Now, if I had measured, I would have
replied to the OP. Since I haven't, I am not going to attempt to give
possible false advice (e.g. I don't know if it is faster to create an image
by accessing the embedded resource or by accessing the file sytem). If
someone did the numbers I wouldn't be surprised with either result... that
is not what I am contributing to this thread or have a strong position on.

Cheers
Daniel

 

[Guest]

Surely the CLR requires what ever the size of the executable of memory to

be available on load, not nessessarily loading it into RAM at that time,
but making sure that footprint will happily load?

Why would it need to do that? That would be a poor decision on their part
for many reasons, this being one of them. To enable an app to run with
minimal resources, you simply JIT what you need to, and pitch if you have
to. You should be able to run a 2MB exe with only 500k of RAM if 500k is
enough for the heap and stack.

With regards to users deleting files this is really a non-issue. Users
could easily just delete a satallite DLL or any other critical file your
application requires. Just take a look in \Windows directory. You will
find hundreds of resources, I admit some exist in ROM but not all.

The \Windows folder is a different story, and again, I've deployed enough
enterprise apps to know that users _will_ try deleting and modifying apps,
plus if it's a satellite DLL it won't show up in File Explorer, as it hides
DLLs.

Tell your support group it's a non-issue the first time they have to figure
out from some IT department why a devie in the field has failed and it turns
out to be a missing or changed file because the field tech was screwing
around. If you save one call it's worth rolling it all into the main
assembly.

-Chris

 

[Simon Hart]

Surely the CLR requires what ever the size of the executable of memory to

Why would it need to do that? That would be a poor decision on their part
for many reasons, this being one of them. To enable an app to run with
minimal resources, you simply JIT what you need to, and pitch if you have
to. You should be able to run a 2MB exe with only 500k of RAM if 500k is
enough for the heap and stack.

The CLR must allocate memory for the embedded resources onload, or does it
not?

The \Windows folder is a different story, and again, I've deployed enough
enterprise apps to know that users _will_ try deleting and modifying apps,
plus if it's a satellite DLL it won't show up in File Explorer, as it
hides DLLs.

I have been deploying enterprise applications for 10 years and have never
had a customer from our base of around 6000 delete a fundamental file. I
have never heard of any of our distributors customers do this either.

I don't know about you, but I have the "Show all files" option turned on in
File Explorer.