DotNET project resources and memory, what's going on?

Question

Where can I find reliable information regarding project resources and memory? I'd like to know when resources are loaded into memory from the dll, when they are removed by the GC etc.

Reason is my app carries the help-file topics as HTML-Strings inside the source, and I'm about to add the possibility to include images. I don't care if my dll-size grows substantially, but I do care if the memory-footprint of my app grows substantially.

Answer 1

Take a look at this blog it has excellent information on debuging techniques to find issue also take a look at son of strike which is more .net centric.

Answer 2

This application will give you a lot (if not all) of that information, but it's kind of hard to read.

There are a couple different versions of it for different versions of .Net. The one I have linked is the one for 3.5 I believe.

Answer 3

A memory profiler will help you with this information. I can recommend SciTech .Net Memory Profiler, but there are more options. See the answers to this question for example.

Answer 4

It sounds like you might be looking for a memory profiler. The one from SciTech is pretty good: .NET Memory Profiler. They have a free two week trial.

Answer 5

I'm not entirely sure if .NET works the same as plain Win32, but the way it normally works is:

Embedded resources (i.e. resource strings) in DLLs/EXEs are loaded into memory as soon as the library/app is loaded. However, if the resources are not used for a long time, they can be unloaded / paged out. Thus you don't really need to worry about running out of memory.

Having said that - HTML help isn't such a great thing to shove inside a program. If you have a lot of it, I'd really suggest storing it somewhere external to the app. That's what formats like CHM are for.

Update:

Based on your comment, I think you might want to look into satellite assemblies. This is a very common approach when you need to store large amounts of embedded resources that will be used infrequently (or not at all), i.e. for localization. They are still compiled assemblies which should hopefully fit into your plugin system.

Each plugin would effectively be two assemblies, one loaded by your main app and another declared as a reference inside the plugin. Everything is still completely self-contained, but you don't load the satellite DLL until a user actually asks for help.