-
-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Managed Shell Extensions with .NET Core & Side-by-Side Execution via manifests #252
Comments
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: 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. 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: |
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).
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:
Any thoughts on this? I'm still in the experimenting / learning phase with .NET Core at the moment! |
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 👍 |
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:
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.
The text was updated successfully, but these errors were encountered: