Additional satellite assembly without recompilation of the main assembly

Question

I have an already localized WinForms program with four languages. It consists of one EXE and several DLL's. All C# projects are contained in one solution. The satellite assemblies are generated automatically from localized resource files, e.g. Strings.fr.resx or MyForm.it.resx.

The source code is stored in Subversion, the centralized (build server) generated binaries in Artifactory. Maven is used for dependency resolution. The corresponding source code for the binaries (snapshot) is also stored in Artifactory. So, both binaries (DLL, EXE) and corresponding source code can be referenced from other projects.

Now, I want to add an additional language to the program without recompilation. The original binaries must not be touched.

The idea is to create an additional solution that depends (Maven) on the original program version. So, I get the binaries and source code. Then I can create tool projects for each original project to create the satellite assemblies, e.g. using a batch file. That will work for projects with localizable text and other things in resource files.

But what about Controls and Forms. Different languages may have different resulting control layouts, line breaks, position changes, sizes etc. It is not only text translation. So, the WinForms designer would be very helpful. Does anybody know a good way to create satellite assemblies containing controls?

Additional tools (e.g. Sisulizer) are not possible. The original binaries are strong named and the key is available only on the build servers. So, the new satellite assembly must be strong named with that key, too.

Answer 1

This is how I do by localized builds. I use a localization tool (Soluling) that can read the Windows Forms EXE. First, I use the GUI version of the localization tool to create a localization project file (XML file) that I include in my repo. Then in the build process on the build server, uses the command-line version of the localization tool to scan the EXE file. This scan process extracts the new or changed strings, and the build process sends them for translations. After that, the build process builds the satellite assembly files. The output artifacts of the build process are the main assembly (.exe), some other assemblies (.dll), and satellite assemblies (.resources.dll) for the main and other assemblies. This is all done by the command line version of the localization tool as part of the normal build process.

In your case, you don't want to rebuild the EXE. That is fine. You would only use the satellite build part of the build process.

In general, I use three kinds of build processes (depending on the project)

1) Local

I install the command-line version of the localization tool locally on my machine and call it from PowerShell or Bat file.

2) Own build server/agent

Same as above, but a task of the build pipeline calls the command-line version of the localization tool.

3) Cloud based build

This is a bit trickier because I cannot install my own software on a cloud build like Azure. I do this by including the command line version of the localization tool (single EXE, SoluMake.exe) into my repo. During the build, this EXE is then available in the Azure DevOps build machine and the build can use is just like in case #1 and #2.