Hey @LEV3LGames it's a known issue. It isn't your fault you hit this problem. This is something we need to document and handle better.

You have two choices:

1. Delete the plugin while Unity is not running. Then install the plugin after they start Unity.
2. You can also exclude those sfw_*.dll files from the update installer, as they don't normally change.

Our code uses an un-managed library to perform file watching and we can't unload it when people try to upgrade and they are running Unity at the same time.

Ugh, this needs to be filled in.

https://github.com/github-for-unity/Unity/blob/master/docs/using/how-to-install-and-update.md#updating-the-github-for-unity-package

And actually, I just went and tested this flow in updating 1.0.1 to 1.0.2 in Unity 2017.2
It did seem to realize that the files had not been changed and actually did not let me check them.
Not every game and/or version of Unity is going to be as lucky, but it should definitely work with those files unchecked.

Hey @StanleyGoldman! I managed to solve it the same way that you mentioned, but thanks for clarifying it! Actually the idea of creating this issue was to call this problem to your attention.

It is interesting that upgrading from 1.0.1 to 1.0.2 Unity 2017.2 recognized that the file has not changed. It made me realise that I tried to upgrade from 1.0.0 to 1.0.2, but in the description I wrote ("an older version". So either the sfw_x64.dll changed between 1.0.0 and 1.0.1, or the importing works worse in Unity 2018.2.

@LEV3LGames thanks for hanging in there. I hope it is all smooth sailing from here on in!

The best way to get our attention is always with an issue. I'm in discord, but I'm not actively using it so the notifications slip by me sometimes.

Usually we write in the release notes when the sfw library has changes, but I will also double check the import process in 2018.2.

Cheers! 🍻