wip: .NET Core Support

[dwmkerr]

This is now partially working. To show it in action:

1. Open the solution, build all of the code.
2. Manually install the .NET Core version of the CountLinesExtension with regsvr32.
3. Now load the CountLinesExtension in the server manager.
4. Register the extension as x64.
5. You will be able to run the extension by right clicking on any txt file...
6. ...however, any subsequent run will crash the host process (i.e. explorer in most cases)

The exception is:

And I have no idea why. So far testing with a side-by-side manifest has not fixed the issue. Note that the extension is debuggable as expected from the ServerManager.

Current issues:

• [x] Internals are not visible to tests/SRM, which breaks the build
• [ ] Support registration of .NET Core COM servers; check if the assembly is .NET Core, check for the presences of the*.comhost.dll file; register the comhost; throw if anything looks weird
• [ ] README needs updating with compatibility matrix
• [ ] Extensions built with .NET Core need testing
• [ ] Currently the 'count lines' context menu extension has been setup to use .NET Core 3.1 and doesn't work, so some digging will be needed here.
• [ ] We can clean up the cludgy 'post build' steps to use targets like this https://github.com/dotnet/samples/blob/master/core/extensions/COMServerDemo/COMServer/COMServer.csproj#L47
• [ ] document the differences between registration of .NET Framework and .NET Core COM servers (there are screenshots in the docs)
• [ ] reference the .NET Core COM Hosting guide here: https://docs.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
• [ ] Extract all server registration and extension registration into its own assembly - all it needs to do is basically write to the registry. This library could then be consumed by a CLI, desktop app or other users. It should be smart enough to be able to identify a .NET Core server vs a Framework server. In the future, it could also be used to enumerate extensions, which might be interesting. It would also then be easier to write unit tests which assert that the appropriate registry entries are written.
• [ ] This like ClassRegistration and ClassRegistration could all be pulled into the separate registration library, at the moment they are only used by the half baked GUI that I'd been working on to manage shell extensions.
• [ ] Eliminate MEF and essentially just load and register servers via pseudo Duck Typing, if there's something which implements ISharpShellExtension or whatever then we assume we can try and register it. This will fix the requirements that the server manager needs to be compiled with the same version of SharpShell as the server itself.
• [ ] We will only be able to register .NET Core Shell Extensions using the tooling from version 3.0 onwards - because only that version of the tooling can correctly identify if an assembly is a .NET Core assembly.
• [ ] The registration manager project (which will be extracted) will need to have tests for both the .NET Framework and .NET Core, because the code is different for the different platforms (see MetadataReader)
• [ ] docs: .NET Core extensions will not support self-contained deployments (check the proper nomenclature)

Server Manager

• [ ] Rewrite in WPF?
• [ ] Elevate permissions only as needed?

Closes #252

[guardrails[bot]]

:warning: We detected security issues in this pull request:

Hard-Coded Secrets (1)

https://github.com/dwmkerr/sharpshell/blob/e049b361dcd65ed2a944aaf680bdecd962261b05/SharpShell/SharpShell/SharpShell.csproj#L77

More info on how to fix Hard-Coded Secrets in General.

---

👉 Go to the dashboard for detailed results.

📥 Happy? Share your feedback with us.

[guardrails[bot]]

All previously detected findings have been fixed. Good job! 👍🎉

We will keep this comment up-to-date as you go along and notify you of any security issues that we identify.

---

👉 Go to the dashboard for detailed results.

📥 Happy? Share your feedback with us.

[guardrails[bot]]

:warning: We detected security issues in this pull request:

Hard-Coded Secrets (1)

https://github.com/dwmkerr/sharpshell/blob/63aeca67f5c6508d35eaf2351a49b7f6dec3868e/SharpShell/SharpShell/SharpShell.csproj#L77

More info on how to fix Hard-Coded Secrets in General.

---

👉 Go to the dashboard for detailed results.

📥 Happy? Share your feedback with us.

[wangfu91]

First of all, great work! thanks for the library.

...however, any subsequent run will crash the host process (i.e. explorer in most cases)

I checked out this PR locally, played with the CountLinesExtension sample, can't reproduce this issue anymore.

It seems to be the same issue with https://github.com/dotnet/runtime/issues/38950, which has been fixed recently and backported to .net core 3.1.x: https://github.com/dotnet/coreclr/pull/28073

[DarkCreekWay]

Verified @wangfu91's findings. The crash does not happen with sdk 3.1.8 and beyond.

[DarkCreekWay]

@dwmkerr Would you mind to add an .editorconfig file to the solution ? This would make it way more easy to contribute.

[Mik4sa]

Do you have any timeframe for when this should be done? And what is still missing here?

[Repiteo]

Echoing the previous comment; very excited to see this merged to the main branch!

[luky92]

Is this project dead or still active?

[dwmkerr]

I'm looking for others who can continue it if possible - it's not 'officially' abandoned but I have super limited capacity

[kocburak]

Sorry to hear that. I am trying to create a Encryption tool for folders and want to browse it's inside (like zip) without first exporting to persistant storage. Is there an alternative library for this? I dont want to program a whole File Explorer.