I recently learned that Embedded Resource means that assets are saved to an external .resx file.
Setting assets to Resource makes them join the .exe file simply.
Now, I'm confused of when to use Content and Resource.
Any info?
Resource : Embeds resource into the
assembly (or culture specific
satellite assembly)
Content : this leaves resource as
loose file and upon compilation this
resource information is not embedded
to assembly. Instead, it adds custom
attribute to the assembly
(AssemblyAssociatedContentFile) which
records the existence and relative
location of file.
It is also possible
to access the resource file without
adding into the project. However, with
this approach management of resource
file becomes bit difficult. However,
this approach is useful if resource
file is generated dynamically using
some runtime information. In such a
case, resource file will not be
available at compile time so can not
be added to project.
Source: Resources in WPF.
Related
If I include a .bin.gz file in a DLL as an embedded resource, it doesn't show up in the Assembly.GetManifestResourceNames() list, and cannot be loaded with Assembly.GetManifestResourceStream(). If I rename the same file to anything else, it does show up.
The .bin.gz file shows up in .csproj. I'm building a .NET Core 2.2 class library.
What's going on? Is there some kind of filter by file type that prevents certain types from being embedded?
EDIT: On further inspection. It appears that the .bin.gz resources are placed in a different .dll named [AssemblyName].resources.dll, which is placed in a "bin" folder next to the [AssemblyName].dll. Why is this and why does this not happen with other files?
When nesting a .resx file under a .cs file using the DependentUpon element in the .csproj file and then accessing a resource using the wrapper a MissingManifestResourceException is thrown.
The message reads:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "Namespace.Resource.resources" was correctly embedded or linked into assembly "Assembly" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Example code:
MessageBox.Show(Resource.Key);
Why does this error occur?
The MSBuild target PrepareResourceNames (on which PrepareResources, which also calls ResGen, depends on) calls a task called CreateManifestResourceName.
[see Microsoft.Common.targets]
This task creates the name of the .resources file. For C# the actual method that creates the name is CreateManifestNameImpl in Microsoft.Build.Tasks.CreateCSharpManifestResourceName. This method checks whether the .resx file has a .cs file as parent. In that case it searches the .cs file for the first fully qualified class name it can find and takes it as the .resources file name.
[see Microsoft.Build.Tasks.v4.0.dll]
The .resx wrapper does not expect this file name change and thus an exception is thrown.
I guess this behavior was implemented for WinForms localization which nests its resources under the corresponding form or control.
I decided not to nest the .resx files. A possible solution could be to implement a CreateCustomManifestResourceName task for which MSBuild provides a hook.
Is it possible to create single exe file from my C# WPF project? The project contains some images and videos in Movies folder inside bin.
How can I compile all of this in singe exe file? I know it will be large in size but it is OK.
You should add this files to you project and use Build Action: Resource for this files. In this case, it will be introduced into the main assembly of application.
It will be a binary resource, because it is embedded in the compiled assembly as an opaque binary large object.
Quote from Matthew MacDonald book: Pro WPF 4.5 in C#:
There are a couple of things that you must not do in order to use assembly resources successfully:
Don’t make the mistake of setting the Build Action property to Embedded
Resource. Even though all assembly resources are embedded resources by
definition, the Embedded Resource build action places the binary data in another
area where it’s more difficult to access. In WPF applications, it’s assumed that you
always use a build type of Resource.
Don’t use the Resources tab in the Project Properties window. WPF does not
support this type of resource URI.
the Resources folder typically contains all the app images (those 16 X16) that we use to look our apps good. I haven't dealt with installation and resources folder before therefore :
When application needs to be deployed, what would happen to those images in that Resource folder?
I haven't tried this before so when I install the application where would that resource folder be saved?
If the installation creates another resource folder to keep those images, then what if a user manually deletes that folder? App would crash? what is the solution to overcome this?
I've heard some place the images in a .dll file, is this a common practice?
thanks
When you build your application, Visual Studio invokes the resgen.exe tool to convert your application resources into an internal class called Resources. This class is contained in the Resources.Designer.cs file which is nested under the Resources.resx file in Solution Explorer. The Resources class encapsulates all your project resources into static readonly get properties as a way of providing strongly-typed resources at run-time. When you build through the Visual C# IDE, all the encapsulated resource data, including both the resources that were embedded into the .resx file and the linked files, is compiled directly into the application assembly (the .exe or .dll file). In other words, the Visual C# IDE always uses the /resource compiler option. If you build from the command line, you can specify the /linkresource compiler option that will enable you to deploy resources in a separate file from the main application assembly. This is an advanced scenario and is only necessary in certain rare situations. A more common scenario for deploying resources separately from the main application assembly is to use satellite assemblies as discussed below.
All your queries is answered above
i.e.
When application needs to be deployed, what would happen to those images in that Resource folder?
I haven't tried this before so when I install the application where would that resource folder be saved?
If the installation creates another resource folder to keep those images, then what if a user manually deletes that folder? App would crash? what is the solution to overcome this?
I've heard some place the images in a .dll file, is this a common practice?
For More information
http://msdn.microsoft.com/en-us/library/7k989cfy(v=vs.80).aspx
I have a C# application that is being internationalized. I want to keep all of my language resource directories (en-US, es-SP, etc...) in a single directory called "languages" within the installation directory, so that the file path would be something like C:\application\
languages\en-US\resource.dll for each compiled resource file.
Unfortunately, the .dll that references the language resource file is in the C:\application\mainprogram.dll location. What do I need to set in Visual Studio so that mainprogram.dll can correctly access all of my language resource dll files?
Also of note is that the language resource files work fine if all of their folders are on the same level as the mainprogram.dll file.
You can specify additional private paths using the Probing Element in your configuration.
Alternatively and probably more than you would need:
You can hook in to the AppDomains Assembly resolve event which gets called every time it fails to find an assembly via standard probing.