COM-Visible assembly needs language pack to run, but language pack not available !

[lalbatros]

Hello,

I created a COM-Visible assembly in C#.
I aim to use this assembly in Excel-VBA, for number-crunching.

It works perfectly in the "English(US)" regional settings.
It works perfectly in the "French(France)" regional settings for which the language pack is installed.
It works perfectly in the "Dutch(Netherlands)" regional settings for which the language pack is installed.

It fails in the "German(Germany)" regional settings for which the language pack is NOT installed.
It fails in the "French(Belgium)" regional settings for which the language pack is NOT installed.
It fails in the "Dutch(Belgium)" regional settings for which the language pack is NOT installed.

Failure occurs only when the exact type of the method parameters is not used.
If the exact type is passed to the method it always works, independently of the Regional Settings.
Note however that my Assembly does not -logically- need any Regional Settings to be used.
It is just pure number crunching which is involved.
But the numbers can be passed as a Cell (Range) object in some cases.

The funny thing is that there is NO language pack available for "French(Belgium)" or "Dutch(Belgium)".
Of course, asking end-users to change their regional settings is not really a good solution.
(unless the "French(Belgium)" or "Dutch(Belgium)" Regional Setting are really pure cosmetic without real use)

I would be interested to solve the problem somehow at the root instead of changing C# or VBA code.
(This would avoid me headaches!)

Any suggestion welcome!

Thanks

Michel

 

[mole999]

you've probably tried this, but on the off chance it hasn't been, how about using codepages https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx which the machine might understand

 

[RoryA]

In all honesty you're probably more likely to get an answer in a C# related forum, rather than here since this isn't an Excel problem per se. (unless someone like Colin happens to see this...)

 

[lalbatros]

Hi mole999!

No I didn't think to that until now!
I checked my codepage, it is 437 = OEM United States.
I observed that changing the Regional Setting doesn't affect the codepage.
But, unfortunately, it can affect my (any) COM-visible Assembly if there is no Language Pack installed.

Thanks,

Michel

 

[lalbatros]

In all honesty you're probably more likely to get an answer in a C# related forum, rather than here since this isn't an Excel problem per se. (unless someone like Colin happens to see this...)

Actually, I started discussing this problem on an MSDN forum for Office developers. (months ago)
I launched many threads.
At the beginning, the issue looked more complicated as I didn't detect that Regional settings were the root cause.

I have also used a support ticket, and experts from MS are investigating.

It seems to me that it is an Office issue.
Unfortunately, I couldn't make it totally clear using VBScript for some other technical reasons (probably group policies).
Therefore, it is only a conjecture that the issue is specific to Office.

But there are good hints that it is specific to Office.
For example, when passing the exact data type to the method, it always work.
Conversely, when the parameter needs conversion, the method is not even called.
Instead I receive this error in VBA:

*** Class does not support Automation or does not support expected interface ***

Since the conversion is typically from a Range to a double or to a string, this implies that Excel should come to the rescue.
My guess is that Excel remains silent, not willing to help, when the Regional Settings are not supported by an Office Language Pack.

Therefore, I thought that Excel fans could help.

Thanks,

Michel

 

[mole999]

what code do you have written in excel, are you DIMming for a result As String etc, excel might want to choose a different conversion and by limiting it therefore exacerbating the issue