Embedded resources are the best choice
if you have to share application
resource (.resx) files between
multiple projects. For example, if you
have a common resource file that
contains your company's logos,
trademark information, and such, using
embedded resources means you have to
copy only the .resx file and not the
associated resource data files.
You cannot edit embedded resources
directly. If you try to edit an
embedded resource, you will receive a
message prompting you to convert the
item to a linked resource in order to
edit it. Conversion is recommended but
optional. You must export them, make
your modifications in an external
program, and then import them back
into your project.
“Resource” and “Content” build actions are to access the WPF resources using the Uris. However “Embedded Resource” is for prior technologies. However both options embed the resource in assembly but “Resource” option to be used for WPF.
A WPF resource (build action = Resource) leverages embedded resources as supported by the core .NET framework, but adds support for accessing the embedded resource via a pack URI. From MSDN:
WPF resource files are not the same as
the embedded or linked type of
resources that can be configured using
the core .NET Framework support for
assembly resources. While WPF resource
files do leverage the core .NET
Framework embedded resource support,
the ability to access WPF resource
files using pack URIs is easier than
using namespaces.
Thanks for all the reports, that helped me find more precisely where was the problem:
For me, it was the images used as project icon in the task bar that was built as resources and had to be built as content. All others images can be build as resources, no problem.