MonoDevelop: what is build action "Content" compared to "Resource"?

In my application all images, local HTML pages etc. are marked as "Build action Content". I have just realized that there is also "Resource".

Which one开发者_如何学编程 should I use for images and which one for HTML pages to display in a UIWebView?

Currently I use images like this:

this.oImgLoginLogo.Image = UIImage.FromFile ( "Data/Images/ball.png" );

But in Monotouch.Dialog I see this line:

static UIImage arrow = Util.FromResource (null, "arrow.png");

But arrow.png is also marked as "content"...?

Puzzled.

What are the disdavantages/advantages of each option?

Embedded resources are embedded into the dll or exe file, and accessible from .NET reflection APIs. Content files are bundle resources and are copied into the app bundle (which is simply a directory), and accessible using file APIs or MonoTouch's Apple bundle APIs.

MonoTouch does support embedded resources, but they aren't straightforward to use from Apple-specific APIs, which are designed to use things from the app bundle. However, embedded resources may make more sense when you aren't dealing with MonoTouch-specific APIs, or when you're writing libraries that are portable to other platforms.

MonoTouch 4.0+ does support Content files in dll libraries - behind the scenes they're mangled into embedded resources when the library is compiled, so you can share it as a single dll file, then they're unpacked into the app bundle when the app is compiled.

My guess is that MonoTouch.Dialog was using embedded resources and not bundle resources because it's a library and predates MonoTouch 4, therefore the file marked as Content is a bug in the project.

In the .NET world, the difference is that during the build process a file marked as Content gets copied to the output folder, while a Resource file becomes part of the DLL itself.

AFAIK, MonoTouch doesn't includes resources into the build, because that doesn't exist in iOS, so that's why you always use Content. A final step then zips the directory with the executable and the content files into the .app file, which is how iOS expects it. The same thing is valid for MonoDroid.

The difference between MonoTouch and MonoDroid in the API exist because the idea of those frameworks is to translate, almost one-to-one, the APIs available in those platforms, instead of creating one interface that supports all platforms equally.