Language problems

[Eduardo]

Can anybody in the community help me with a problem please. I’ve read the technical documentation and it says AxCrypt doesn’t provide official support for this.

I can build AxCrypt using Visual Studio with no issue and I can also create a portable version of the file with ILMerge which combines the assorted dynamic link libraries (I exclude the irrelevant PDB files).

The final build doesn’t allow me to change the language from with the GUI. This is because AxCrypt have chosen not to use embedded dependencies and instead rely upon multiple DLLs which are in directories: de, es, fr, it, ko, nl, pt, ru, sv, tr.

All of the language DLLs are identically named as AxCrypt.Content.resources.dll and ILMerge doesn’t (as far as I know) allow recursive merging and, even if it did, they’re all identically named.

Can anybody help me resolve this dependency hell?

[Arendt]

You could do AxCrypt a favour and refactor the code to use AssemblyResolve instead. It’s a better solution but it wouldn’t be quick.

A two second solution would be to create a shortcut to the executable file. You’d have to keep the folder with all of those language folders on the local drive but it would get rid of your problem.

Another method is to try NuGet.

[Ondřej]

I’ve not got the source on my computer so I can’t give specific advice but if you’re wanting to change your default language can’t you substitute the AxCrypt.Content.resources.dll with your preferred language DLL? If the file names are all identical then this will be trivial.

It’s not a perfect solution because you won’t be able to change language throughout the UX but it’s easy. This all depends on how tidily the source code is written.

If you get stuck give MSBuild ILMerge a try!

[SvanteSpectator]

Hello Eduardo,

Our pre-built portable executable includes the language satellite assemblies, and allows language switching. Check the file ‘Axantum.targets’ for hints on how to do it. Unless of course you’re fine with using ours!

As for “chosen not to use embedded dependencies and instead rely upon multiple DLLs which are in directories: de, es, fr, it, ko, nl, pt, ru, sv, tr” – well, that’s just how it works by default.

And, yes, it would be awesome if someone would contribute a way to build a single executable using embedded resouce assemblies with the AssemblyResolve event instead of ILMerge. There’s an issue waiting to be resolved for that: https://bitbucket.org/axantum/axcrypt-net/issues/14/change-single-exe-strategy . We did a proof of concept for that with another software, a portable client version of the password manager and it works fine.

[Eduardo]

Thank you for the response.

I had a look at the .targets file and I think I can see where the script is working – highlighted in blue.

If I ILMerge the contents of the directory (built as a release, not a debug) then AxCrypt works fine and the language is always English but the other languages don’t work.

I can add one locale into AxCrypt.Content.resources.dll, e.g. German, and AxCrypt switches between English and German.

The problem is that if I try to ILMerge all of the locales (de, es, fr, it, ko, nl, pt, ru, sv, tr) into AxCrypt.Content.resources.dll I only get English and one of the locales.

Is there some prefix or suffix that AxCrypt recognises? I’ve tried “de-de” and “de” on their own and that makes no difference.

Arendt, I’ve tried NuGet but it doesn’t make any difference in the language handling here.

Ondřej, that solution only works for a single language, as you thought.

Thank you all!

 

[Bruce]

I’ve reproduced the issue Eduardo. I’ll take a look for you because I’d never noticed that the languages don’t work and I’ve also built the software from the source.

[Stephen]

This will only happen Eduardo if you’re specifying “target:winexe” or you’re not specifying this at the command line. The default behaviour of ILMerge is to match the assembly type which in AxCrypt’s case is “target:winexe” therefore it assumes this is the target type.

To resolve your issue specify “target:exe” but beware that a terminal window will appear upon each execution of the program. It will however allow all the languages without issue and solve your problem.

Only use “Axantum.AxCrypt.exe” and do not merge into”AxCrypt.exe”.

Under no circumstances use the latter with /ndebug or without “BouncyCastle.AxCrypt” as you’ll cause the software (contingent on the .NET version installed on your system) to catastrophically and silently fail rendering the encryption library useless.

I shan’t get chance to check back on here Eduardo for a while but as long as you follow these instructions to the letter you will have no difficulties.

[Eduardo]

Thanks Stephen.

It works just like you said it does.

The documentation does refer to using “winexe” and not “exe” but I’ll put up with the black box terminal window until there’s a fully reproducible build available.

[SvanteSpectator]

Hello Eduardo,

May I ask what it is you’re trying to achieve? Is it something we could put on the to-do list for the main distribution (we do have a portable / standalone build for download, as you know so I’m not sure why you can’t just use our build mechanism)?

[Eduardo]

Hi Svante

I’ve got a copy of the official portable build and it works without problem.

My objective is to be able to recreate the portable build on my system so that I can exactly reproduce the official portable build from source.

Everything I’ve got so far reproduces with the exception of the languages. For reasons I cannot establish from looking at the source when I use ILMerge to merge all of the locales (de, es, fr, it, ko, nl, pt, ru, sv, tr) into AxCrypt.Content.resources.dll I only get English and one of the locales.

I don’t know if there’s an undocumented naming convention for the individual language DLLs (example: DE-axcrypt.dll, ES-axcrypt.dll) because merging all the AxCrypt.Content.resources.dll doesn’t work and prevents me from precisly rebuilding the original from source.

Thankyou

[Ondřej]

I’ve downloaded the source Eduardo to understand your post and I can see the problem. Each language has it’s own identically named DLL. This was my procedure –

• I renamed each DLL like in your list. One called de.dll, the other called es.dll, another fr.ll.dll and so on.
• I then moved all of the DLLs into an empty folder.
• I used ILMerge on them all and named the output AxCrypt.Content.resources.dll

When I started AxCrypt the English language worked and so did the German, but no others.

I’m at a loss to know what’s causing this issue but it looks like you’ll have to use the pre-packed binary if you’re prepared to forego building from source yourself.

[SvanteSpectator]

Hello all,

There’s nothing magic about our build. We do not use anything (except of course code signing certificates) that is not in the public repository.

Our build-server command line to build the stand-alone version is essentially (minus some stuff for our versioning since we inject our build number into the assembly version and naming etc):

msbuild AxCrypt.NET.sln /p:Configuration=Release

This should produce ‘AxCrypt.exe’ with all the required culture satellite assemblies merged in and workable.

That’s it. Please note that we won’t actually do the ILMerge stuff for Debug builds – but if you wish you can change the .targets files for that.

[Eduardo]

msbuild AxCrypt.NET.sln /p:Configuration=Release

This is essentially what I had been doing but from within Visual Studio.

I executed the command from within the MSBuild Command Prompt and it produced exactly the same results – three executables:

(1) AxCrypt.exe [\Axantum.AxCrypt\bin\Release]

(2) Axantum.AxCrypt.exe [\Axantum.AxCrypt\obj\Release]

(3) Axantum.AxCrypt.exe  [\Axantum.AxCrypt\bin\Release]

1 – Works but the languages don’t

2 – Doesn’t run at all

3 – Works and so do the languages (when in \Axantum.AxCrypt\bin\Release) but when it’s copied to the desktop or somewhere else the program works but the languages don’t.

The problem is that the portable version (stored within \Axantum.AxCrypt\bin\Release) doesn’t have language support when moved out of the folder.

[Ondřej]

I’ve replicated your output Eduardo. The third build in your list works in and out of the folder it’s in but the language support disappears when moved to another folder.

The \obj\Release and \bin\Release executables are 1.16 MB and the \bin\Release is 6.51 MB.

There may be a problem with the BitBucket repository because this is abnormal behaviour when compiling.

[SvanteSpectator]

Hello,

The size difference is just due to the fact that the small one is without ILMerge, and the larger one after (i.e. includes all assemblies).

The language problem is different though, when we have time we’ll try to figure out why our builds produce working binaries for all languages, while community builds apparently do not. They should.

[Author]

Posts