0

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.

KBO
  • 653
  • 7
  • 17
  • sounds to me like - especially with the requirement of controls - you would need to use DependencyInjection. Check out MEF as a rather simple tool for the job that is also native to .NET. Be aware there are two versions of it (MEF and MEF 2). I have only ever used MEF. If your product is already 'out there' and you aren't currently allowed to touch the codebase then that is not an option. – Steffen Winkler Jun 18 '19 at 13:29
  • @Steffen: Thanks for the comment, we are still using StructureMap for DI. It is more an organizationally problem and how the satellite assemblies can be build in our infrastructure. I solved it in between, it works as (shortly) described above. The source code of the original project is used by the extended SVN project (for the additional language), the new resources and other changes are made and it is recompiled using the version number of the original project. Then, the new satellite assemblies for the additional language can be copied to the original program installation. – KBO Jun 20 '19 at 05:30
  • ah, gotcha. It seems I misunderstood the question. Glad to here you were able to solve the issue yourself. – Steffen Winkler Jun 20 '19 at 09:32
  • Why don't you use a localization tool. They can create a satellite assembly either from the .csproj or from the compiled main assembly (.exe or .dll). You can also tell the localization tool to use the same key as the main to sign the satellites Sisulizer is a bit outdated tool. I would use Soluling; www.soluling.com – Jaska May 31 '20 at 03:09
  • @Jaska: Working with such a tool, that creates the binaries directly, is a manual step on your working machine. But we are using a centralized build as written above, that requires a different workflow. The binaries must be created on the build server. The problem is solved in between, as written above. – KBO Jun 12 '20 at 05:21
  • @KBO It is not manual. In my case I have hooked the command line version of the localization tool into my Azure DevOps pipeline. – Jaska Jun 12 '20 at 23:27

1 Answers1

0

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.

Jaska
  • 1,007
  • 10
  • 9