Signing Add-In with a strong name, sometimes it's needed?

[Helmut Ortmann]

Hello,

I come across that registering of an Add-In usually works without bothering about .net signing in C#.

Last time I couldn't register an unsigned DLL with EA to use as GUI/COM object in the Add-In window. After signing everything runs smooth.

In debug mode of VS 2017 everything runs smooth, regardless of signing or not. So, I'm a bit puzzled.

The thing is: In the past, everything works fine with a lot of Add-Ins, regardless of signing or not. I've searched a lot and I've found a lot about the signing of dlls, no silver bullet.

Any idea?

Thanks,

Helmut

[EXploringEA]

Hi Helmut

Reading your post I have a vague recollection of a similar issue years ago where I ended up having to sign a DLL, but then miraculously the problem just disappeared after a few days so I didn't explore further.

Also, it wasn't clear from your post whether the problem happens on the same machine and for same users or not.

Thinking about what it could be:

If this isn't for a single user/machine my guess would be that it is related to some windows policy.  On taking a quick look Windows local security policy supports rule based actions for DLL's with AppLocker.  In this case it may be worth a look there to see if any rules configured for users / admin.  But a word of warning this is not an area where I have personally done a lot, I'm just aware of cases working with different systems where administrators have set machine/user policies that caused us issues.

Be interested to know the outcome.

BR

Adrian

[Helmut Ortmann]

Hi Adrian,

thanks for your elaborate answer.

It is the same user, the same machine and the dll is installed as per user.

I just tried it once more with the same user, and the same machine. Without signing it doesn't install the Add-In GUI and with signing it installs the Add-In EA GUI.

Because I can live with signing I'm not that keen on testing and trying.  There is always the possibility to sign an used external dll. All other Add-Ins run smoothly.

If I come along with an explanation I'll inform you.

Best regards,

Helmut

[Helmut Ortmann]

Hi Adrian,

it looks as if I have solved the issue. The NeutralResourcesLanguage should be correct and the same for all dlls. Maybe it's best to avoid specifying a neutral language altogether. It looks complicated but now it works.

Witout strong name for a DLL (assembly properties)
[assembly: NeutralResourcesLanguage("en")]  // I had used english-europe (en-150) for one dll

or just:
[assembly: NeutralResourcesLanguage("")]

If I've correctly read the documentation strong names support dll with version and culture.

Best regards,

Helmut

[EXploringEA]

Hi Helmut

Thanks for the information - I'd better make a note of this for future reference.  It is something I would never have thought about - what gave you the clue or was it just luck you found the solution?

BR
Adrian

[Helmut Ortmann]

Hi Adrian,

it was just luck!

I wanted to check the release of the dll and used my "About" functionality which lists all dll releases. This function tries to load the dll in question and reported a meaningful error message.

After fixing the error I haven't investigated it deeper. Maybe just loading a dll is a mean for this kind of error.
 
Best regards,

Helmut

[EXploringEA]

Helmut,

Seems like a valid experiment rather than pure luck, and fortunate that you got a meaningful message!

All makes sense as loading the AddIn DLL is exactly what EA does.

Good to have a logical reason (and test).

BR

Adrian