You previously had a build that signed with a strong name key: <a href="https://www.nu

It is needed for COM interop. See <a class="issue-link js-issue-link" data-error-t

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Create a separate build that signs the dll with a strong name key about scintilla.net HOT 4 CLOSED

vpksoft commented on July 18, 2024

Create a separate build that signs the dll with a strong name key

from scintilla.net.

VPKSoft commented on July 18, 2024

Hi,
Where would this be useful? This would lead to an issue where the satellite packages would also have to have two versions and so on. It is also specifically not recommended to add this on an existing package: https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

from scintilla.net.

abc983ft commented on July 18, 2024

from scintilla.net.

desjarlais commented on July 18, 2024

I will look at a separate build for signed scenarios like COM Interop, but that might take some time to get done.

from scintilla.net.

desjarlais commented on July 18, 2024

@abc983ft out of curiosity, is there any particular reason you don't want to use the workaround suggested by jacob?

"While that's being debated I might suggest you fork the ScintillaNET repo and add your strong-name support for anyone who wants it"

from scintilla.net.