It seems obvious from the title, but it took me several hours to get it. I am working on a .NET application which I delay-sign in my development machine, and the automatic build process fully signs all the assemblies. When I started the project, I used the sn.exe tool that comes with Visual Studio to tell my computer to not bother checking that assembly’s signature. So far, so good.

Today I started localizing it, adding a second language. I decided that English would be the default language, and also added Spanish. I opened the main form, changed its Localizable property to true, and the language to Spanish. Then I started translating some UI elements.

My main form derives from a reusable base form I have on a DLL, so I did the same process to start translating that form to Spanish.

Then I added code at the beginning of Main to change the main thread’s CurrentUICulture to es-MX and ran the application. Oh surprise, everything came out in English.

I did everything I could think off. I stepped in the debugger through InitializeComponent for both the base and derived forms, and it just did not work. I created a new little project with a base form in a DLL and a derived form in the EXE, and it worked as expected. I read the entire Internet and still could not make my app work.

After a couple of hours or trying everything I could think of, I stopped for a moment, and while staring at Windows Explorer, I noticed my noverif.bat file. It is a batch file that I have on the root folder of my project, which simply calls sn.exe for all the assemblies. I run that once, and then I can use the delay-signed assemblies in that computer.

That’s when it struck me. Resource translations are stored in their own satellite assemblies, which also are delay-signed. I gave it a try (calling sn.exe on it), and then it worked fine.

I hate it when I spend hours trying to find the cause of a problem, and it turns out to be something totally unrelated!