Skip to content
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

Open
Countryen opened this issue Nov 28, 2018 · 11 comments · May be fixed by #331
Open

RFC: Managed Shell Extensions with .NET Core & Side-by-Side Execution via manifests #252

Countryen opened this issue Nov 28, 2018 · 11 comments · May be fixed by #331
Labels
assigned-to-project issue is assigned to a project and therefore in progress/planned feature-request rather a new feature request or request of change than an issue with existing features question only a question, not a problem, might not be sharpshell specific

Comments

@Countryen
Copy link
Collaborator

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.

@dwmkerr
Copy link
Owner

dwmkerr commented Nov 29, 2018

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 😄

@dwmkerr
Copy link
Owner

dwmkerr commented Apr 5, 2019

Adding to this issue, I would like to have a think about how SharpShell now fits in with .NET Standard...

@TechInterMezzo
Copy link

@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.

@Countryen
Copy link
Collaborator Author

@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/

@DoCode
Copy link

DoCode commented May 19, 2019

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.

@Countryen
Copy link
Collaborator Author

@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 Countryen added assigned-to-project issue is assigned to a project and therefore in progress/planned feature-request rather a new feature request or request of change than an issue with existing features question only a question, not a problem, might not be sharpshell specific labels Aug 31, 2019
@dwmkerr
Copy link
Owner

dwmkerr commented Nov 3, 2019

@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 traditional HICON

Any thoughts on this? I'm still in the experimenting / learning phase with .NET Core at the moment!

@TechInterMezzo
Copy link

  • 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

@dwmkerr
Copy link
Owner

dwmkerr commented Nov 4, 2019

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!

@dwmkerr
Copy link
Owner

dwmkerr commented Jul 12, 2020

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 :)

@DarkCreekWay
Copy link
Contributor

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 👍

@dwmkerr dwmkerr linked a pull request Jul 12, 2020 that will close this issue
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned-to-project issue is assigned to a project and therefore in progress/planned feature-request rather a new feature request or request of change than an issue with existing features question only a question, not a problem, might not be sharpshell specific
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants