Gitlab is just a read-only mirror, github has the most up-to-date content.
Compatible with .Net Standard 2.0, .Net Core 2.0+ and .Net 4.6 and above
If you use Costura this tool probably comes in handy as well.
Costura cannot embed localization resources (*.resources.dll) as Costura runs before MS Build can generate them.
This tool will embed the localization assemblies. Works just as easy as Costura: Add nuget package to project and done!
Many thanks to Simon for the excellent Fody and Costura which this tool is heavily inspired from.
By embedding translations it is possible to create "zero dependency" executables that can simply be deployed and "just run".
In order to embed any reference dll's, use Costura (which cannot embed satellite assemblies due to the way it's integrated into the build process (it runs before they are generated)).
By adding the NuGet package to an assembly all it's satellite assemblies will automatically be embedded as resources and loaded from there. No more need for deploying the satellite assembly folders.
(Use the Core package if you want to manually inject resources)
- Compatibility issue with Fody/Costura
There is an incompatibility with Fody 4.x, I suggest you downgrade to Costura 3.3.2 in the meantime (which uses Fody < 4).
Fody 4 embeds its class multiple times into the same assembly if used in conjunction with resource embedder. This will cause a BadImageEsxception on launch (#13).
- SDK style project + PostBuild
If you use this combination and you happen to run something like xcopy * * to copy all your files elsewhere, you will find that the culture folders are included in the postbuild. This is due to the cleanup running after the postbuild event.
I recommend you use "dotnet publish" instead (with -o you can specific where to copy the files to) as the cleanup runs before publish
- .Net Core deps file
If you build or publish a .Net Core app, it will have a *.deps.json file that is required to run.
Inside the file you will still find sections that seem to reference the satellite assemblies even though the files don't exist on disk. To my knowledge there is no downside to still having this entry.
"resources": {
"de/DemoWebAppDotNetCore.resources.dll": {
"locale": "fr"
}Nevertheless, even without a satellite file on disk (as it's embedded into the dll) the .Net Core app will run just fine and is automatically localized.
Alternative solution if you want to embed custom files or control exactly which resources are embedded how and where.
Example usecases for this:
- Allow drag & drop style embedding (when user drags a dll or other files onto the exe)
- Include default plugins (that are always loaded) inside your dll
- Embed any file dyamically during runtime
By adding the NuGet package to an assembly it is possible to manually inject resources and code into other assemblies.
See this code for injecting resources and this code for injecting code.
The NuGet package uses MSBuild events to hook into the build pipeline and:
- Embedding the satellite assemblies into the assembly as resources as per Jeffrey Richters example.
- Uses Cecil to add/edit the module initializer which will call the hooking code to load the satellite assemblies from resources (The Injected code)
Using tools like JustDecompile it is possible to see that any project using this package contains resources "<AssemblyName>.<culture>.resources.dll"
Currently nothing can be configured and it "just works" out of the box.
Note that the satellite assemblies are always copied to the output directory by Visual Studio.
After the build finishes the Resource.Embedder will delete all resource files it has embedded, leaving only the resource files that have not been embedded (if any).
If there are no resource files left for a specific language (empty localization directory) the directory is deleted as well.
See Changelog.md