sharpshell
sharpshell copied to clipboard
dwmkerr
RFC: Managed Shell Extensions with .NET Core & Side-by-Side Execution via manifests
Version of SharpShell used: 2.7 Related type(s) of SharpShell-Server: Any
This is more a discussion about documentation / in general than an issue.
After there is (some) advice to not use Managed In-Process COM Server Shell Extensions (like our SharpShell Servers) as noted in the docs https://github.com/dwmkerr/sharpshell/blob/master/docs/managed-shell-extensions.md
Maybe we can/should improve the reliability/security/stability in this case? Maybe with added manifests to force/support side-by-side / isolated CLR loading?
.NET Core Did you ever consider .NET Core instead of .NET Framework? IMO the only problem is the loading of the full .NET Framework / CLR when using Managed Shell Extensions (with Side-by-Side execution) - but not with .NET Core. Maybe that would add extra performance. Also SCD/Side-by-Side is supported.
According to this article, .NET Core 2 added COM-Interop (just w/o IDispatch / dynamic-keyword). http://joelleach.net/2018/06/06/com-interop-with-net-core-2-0/ Note from the article:
If you’re using in-process (DLL) COM servers, be aware of 32-bit vs 64-bit issues.
Did you @dwmkerr ever consider/try using .NET Core instead? Also please comment on forcing use of Side-by-Side loading of CLR via manifest.
Great comments @Countryen. By preference, isolated CLR loading would be safer. .NET core would also be better it seems (it was not available when I started, but I've been thinking of it recently). I've got a few issues to close in some other repos then I'll look into this - it might make an excellent key feature for a v3 of SharpShell 😄
Adding to this issue, I would like to have a think about how SharpShell now fits in with .NET Standard...
@Countryen Could you explain how .NET Core would solve the problem of the .NET Framework regarding shell extensions? Is side by side execution of .NET Core working better? I would like to learn more about it.
@TechInterMezzo I am no guru at all but here my explanation: .NET Core basically is built for side-by-side execution. You can either use SCD (Self-Containing Deployment) or FDD (Framework-Dependend Deployment). With SCD all the user needs to run your app is the folder of your app - no prerequisites (like installing .NET Framework version xyz) - it contains the complete .NET Core "Framework" (stupid name, I know) and your app code. It is completely isolated from other applications.
You can have multiple SCD (and/or FDD) on your system at the same time. So if you could use SharpShell with SCD and .NET Core - you'd basically have no conflicts with any other program on the system (in theory). That was always 1 major issue (and feature) of .NET Framework, that all programs on the system shared 1 framework (and mostly 1 runtime).
As stated above, there are some warnings from known vips and co, not to use managed-shell-extensions, because of sharing framework/runtime/appdomain issues. Those should be gone.
I think most SharpShell COM-Servers could be .NET Core Server without much problem - they most likey don't need visuals (like Forms, MessageBoxes, etc.) and don't rely on native implementations/pinvoke.
Also it would open possibilities for interoperability with other systems. Also .NET Core is more leightweight than .NET Framework and focuses on modern devevelopment.
But afaik, all the "do not use warnings" are old and maybe only a risk of <1% nowadays, so focussing on other improvements until then maybe would prove more useful.
References: https://docs.microsoft.com/de-de/dotnet/core/deploying/
Any news here? .NET Core would be the perfect solution for this project and with the latest announcements (.NET 5, .NET Core COM) it would perfectly fit in.
@DoCode Just read the information about .NET 5 - pretty exciting news. No news from me, though.
Why do you think .NET Core (or .NET 5) would be better for SharpShell than .NET Framework? Any insights/pros? Maybe we could start on a quick prototype-project with the new .NET Core 3 (with COM Support).
Adding to this issue, I would like to have a think about how SharpShell now fits in with .NET Standard...
I hope with .NET 5 coming, .NET Standard will vanish - so we don't need to do much here.
@Countryen I've been reading through this:
https://www.amarinfotech.com/difference-between-net-core-2-0-vs-net-framework.html
I see two potential issues at the moment:
- WinForms / WPF - these are not available in .NET Core, but a number of servers will need them (property sheet extensions, deskbands, namespace extensions etc) will often use these technologies for the GUI
- Win32 hands - given that .NET Core is more geared towards cross platform, will it have the basic types we need such as
Icon, particularly given they are essentially wrappers around a traditionalHICON
Any thoughts on this? I'm still in the experimenting / learning phase with .NET Core at the moment!
- WinForms / WPF - these are not available in .NET Core
This is not true anymore for .NET Core 3.0.
I think, you should read this: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0
Awesome :) I'll start experimenting! I think like the plan of attach will be to eliminate regasm as there are already PRs for this, and this will be a significant enough change to bump SharpShell up to v3, in the meantime I'll create a branch to investigate .NET Core 3 support!
OK I've migrated my other large project sharpgl to support multiple frameworks, including .NET core and written up the experiences here:
https://dwmkerr.com/modernising-dotnet-projects/
I can now start on the same process for SharpShell - hopefully it should be fairly quick as I'll be following the guide I wrote :)
Great news!
I'm migrating some of my projects to .NET core too.
Having SharpShell on .NET core makes it possible for me to migrate all of them. Perfect timining 👍
