NHunspell and ARM64

[gottfriedleibniz]

Following up on the discussion about ARM64 support (#270): another potential solution could be to replace NHunspell with WeCantSpell.Hunspell: an actively maintained C# Hunspell implementation.

In addition to having an API that is quite similar to NHunspell, it would also eliminate the NativePath workaround. If this approach seems appealing, I have a branch for testing that includes the minimal set of changes required to update libraries.

Would love to hear your thoughts.

[EWSoftware]

Yes, I'm definitely interested. The one thing holding it back from adding ARM64 support is the x86 native code so getting rid of that would be great.

[gottfriedleibniz]

One thing I did not test in my branch are dictionary and affix files with encoding issues (see WeCantSpell's comments) and ensuring there is no change in user-facing functionality. Additionally dictionary.Affix.Warnings for custom dictionaries could also be exposed the user in some form or fashion.

Given the significance of the change, if this is something you are uncomfortable leaving to a community PR given the change in dependencies, licensing details, assembly signing (potentially), and all other foot-guns, you can certainly use/reference/steal/shame my few changes.

[EWSoftware]

I see you removed the .snk file. Is that because WeCantSpell.Hunspell is unsigned? If so, I can fork a copy of it and create a signed copy so no problem there. Licensing shouldn't be an issue since this is open source as well. Encodings shouldn't be an issue either as this project is .NET Standard 2.0/.NET 4.7.2. I can add something to the Dictionary configuration page to check for issues with the dictionaries if necessary.

Go ahead and create a pull request when you're ready. I can merge the changes and make any necessary adjustments and do further testing at least for the AMD64 version anyway.

[gottfriedleibniz]

I see you removed the .snk file. Is that because WeCantSpell.Hunspell is unsigned? If so, I can fork a copy of it and create a signed copy so no problem there

Correct, see aarondandy/WeCantSpell.Hunspell#42. Ideally there would be a WeCantSpell.Hunspell.Signed package to avoid the maintainers concern with strong naming and compatibility issues (seems like the idiomatic approach anyway to dealing with this).

In the meantime I have pushed a small signing experiment to my test branch. With old package.config setups you could use StrongNameSigner to sign unnamed assemblies. However, now that things are more centrally managed, using that tool as advertised will contaminate the nuget cache. My workaround is to install nuget packages locally and then sign the assembly with your key prior to the VSIX container being created. This may be a viable solution that requires minimal backend work on your part.

Updating Source/VSSpellChecker/License.rtf is still required and is something I am incapable of doing.

[EWSoftware]

Actually, the only assembly that really needs to be signed is the definitions assembly that gets distributed as a NuGet package. The others don't need to be as they are all internal. That should keep things simple as the definitions assembly doesn't reference the Hunspell package.

[gottfriedleibniz]

That should keep things simple as the definitions assembly doesn't reference the Hunspell package.

Much cleaner; updated my test branch w/ this approach (squashing all changes) and included Docs/ updates. Besides some additional testing on my end, this is probably PR ready.

[gottfriedleibniz]

Moved this over to a Pull Request.

In addition, to test building the documentation I updated the SHFB vsixmanifest to support ARM64. Building the entire project on ARM64 devices is a bit difficult (WiXv3 lacks support) however the plugin works as intended. Once (or if) the VSSpellChecker changes are merged, I can create a PR on that repository also.

[EWSoftware]

Thanks for the changes, they've been merged. Regarding SHFB, I only build on x86 so Wix shouldn't be an issue. The standalone GUI uses NHunSpell too so I need to replace it in that as well. I can handle that if you like.

[gottfriedleibniz]

The standalone GUI uses NHunSpell too so I need to replace it in that as well

The changes are trivial, however, the issue of the WeCantSpell.Hunspell package not being strongly named will cause issues (again).

I can handle that if you like.

Go ahead. :)