Server Registration Refactoring, Additional Improvements

[dwmkerr]

from @falahati, originally #260

This changes are in continuation of PR #259 aiming to improve the registration process and provide multiple ways for easy shell extension manipulation and should address multiple issues currently or previously open. This should be a backward compatible update.

First of all, I should probably apologize for committing the majority of changes in one commit, I didn't expect to go this far into the registration process. It just happened.

Commit's description already contains the majority of changes; however, the following list copied from the commit's description should also help:

• SRM no longer loads assemblies with MEF but rather with Reflection and in a sandboxed application domain
• SR and SRM no longer keep assemblies open
• SR updated to .Net4.62.2
• SRM now supports installation of older versions
• It is now possible to get server information without loading a server instance
• Installation and Registration information are now available separately
• SR updated to allow manipulation of all registered extensions including managed extensions
• Multiple enum types are strongly valued to act as a reminder to not change the value of items for backward compatibility
• Executing CustomRegisterFunction and CustomUnregisterFunction now respects the compiled version of SharpShell
• Public Attributes are no longer need to be strongly typed to the assembly to retrieve information
• RegistrationType enum renamed to RegistrationScope
• SharpShellInfo now contains information about the SharpShell assembly used by a SharpShellServer
• SR ShellDebugger now redraws on resize
• SR TestShell functionality temporarily disabled

TODO:

• Move possible BaseType defined custom registration and unregistration methods to SRM
• Adding custom registration status to ShellRegistrationInfo (Registered Namespace, etc)

[dwmkerr]

OK note to self, I need to unpick this into:

1. Small changes which can easily be merged into master as minor releases (minor refactoring, whitespace, non-functional changes)
2. Changes which should be separated out for now (language/framework version upgrades, which might affect consumers, and might need to be released separately)
3. The core functional changes, which are significant enough to justify keeping a release branch from the current master made to allow people to use the old mechanisms if needed

I had a bit of a play around earlier but started yak shaving, will look again soon.

[falahati]

Please feel free to ask about anything ambiguous in the code.

I checked the PR again and I don't see any changes to the framework of the main project. The only change is regarding the "ShellExtensionManager" project which is not a part of the library and is rather an additional standalone tool.

The changes to the C# language version, however, should not create any problem since its just syntax update. The final compiled library is the same with or without it.

And sorry again that I made it hard for you by committing all the changes at once.