Plugin errors while loading in 4.3.

[KaoDome]

Hi! Just to let you know of two plugin loading errors I encountered in the newly released 4.3 (64-bit). It wasn't installed through the Store, it was a manual installation in the environment described in the attached file. No crash log was generated so I supposed it's something that isn't critical, still I decided to report on in just in case.

 

One plugin is included in the default installation and the other was a 3rd party one:

 

C:\Program Files\Paint.NET\PaintDotNet.Effects.dll, version 4.300.7934.42555

Type: PaintDotNet.Effects.ColorFillEffect
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.InvalidOperationException: This effect should never make it in to a Final Release build
   at PaintDotNet.Effects.ColorFillEffect..ctor() in D:\src\pdn\src\Effects\ColorFillEffect.cs:line 33
   --- End of inner exception stack trace ---
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)
   at System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic, Boolean wrapExceptions)
   at PaintDotNet.Effects.EffectsCollection.TryGetEffectInfoFromType(Type effectType) in D:\src\pdn\src\PaintDotNet\Effects\EffectsCollection.cs:line 395

 

The installation was clean by the way, the previous installation of 4.2 was removed prior to installing this one. The 3rd party plugin was the one for SVG graphics:

 

C:\Program Files\Paint.NET\FileTypes\SvgFileType.dll, version 1.0.0.0

Type: System.Web.IHttpAsyncHandler
System.TypeLoadException: Could not load type 'System.Web.IHttpAsyncHandler' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

 

Maybe it'd need to be re-compiled to target .NET 5?

 

Anyway, an off-topic discussion, is bundling .NET the best option? I mean, if the app depended on the system-wide installation it'd benefit from updates pushed through Windows Update directly, for example, without needing to re-release or wait for a new release to ship an updated runtime. Just a thought, I'm sure if you decided to switch away to self-contained deployment it was well thought.

 

Cheers!

- Kao.

 

PS. Don't if it's already on .NET 5, but in case it was useful either for Paint.NET or other development of yours (thinking of portable applications) take a look at Costura by Fody: https://github.com/Fody/Costura there's a NuGet package and it just needs to be referenced (maybe tweaked to your liking).

Environment.txt

Edited September 23, 2021 by KaoDome

[otuncelli]

First one is by a mistake which will be fixed in the next version of Paint.NET I assume.

 

 

C:\Program Files\Paint.NET\FileTypes\SvgFileType.dll, version 1.0.0.0

Type: System.Web.IHttpAsyncHandler
System.TypeLoadException: Could not load type 'System.Web.IHttpAsyncHandler' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

 

For the second one, update to latest version of SvgFileType plugin. There was ASP.NET dependency in SVG.NET library for some reason.

 

[Rick Brewster]

Quote

Anyway, an off-topic discussion, is bundling .NET the best option? I mean, if the app depended on the system-wide installation it'd benefit from updates pushed through Windows Update directly, for example, without needing to re-release or wait for a new release to ship an updated runtime. Just a thought, I'm sure if you decided to switch away to self-contained deployment it was well thought.

 

I spent 5 months working on this and spent quite a bit of time wrestling with whether to use FDD or SCD. And yes, I have concluded that SCD is the best option, by a long shot. There are soooooooo many problems that are caused by relying on system-wide installations of the runtimes for C++ and .NET, I'm so glad that Paint.NET can finally be free of all of that. You have no idea how many times I get e-mails from folks with broken installations because some WPF DLL is refusing to load because it got corrupted. Or the C++ runtime (back before I switched to app-local use of it) was uninstalled and it just completely bricks everything with absolutely no way of diagnosing it for an ordinary user (the error messages are basically hieroglyphics). And these are just a few simple examples. I no longer accept the security argument for using system-wide library/runtime installations -- apps like Paint.NET should strictly use app-local deployment as much as possible as long as they have a regular release cadence of their own.

 

And no, .NET 5 is not updated by Windows Update, not like Framework was. It might get updated if you enable "Receive updates for other Microsoft products when you update Windows", but I've yet to see confirmation of this theory, and that's an opt-in feature that almost nobody will have enabled (statistically speaking).

[KaoDome]

Thank you both for the quick input! I just read both your posts and yep, I'll update the SVG plugin to the current version, to be honest I didn't even check if there were an update to it, I've copied it from before (for some reason it was abandoned in my mind).

 

I can see that you gave a lot of thought to the way things are deployed @Rick Brewster! I already knew that'd have been the case, but thought of mentioning anyway. I had never thought of those problems you mentioned, but they're certainly plausible; having a runtime uninstalled without a way to tell the user "hey, this/these app(s) will stop working if you uninstall it" is a recipe for disaster, especially given the error messages since they're not all delay loaded.

 

For little (C/C++) programs I tend to even statically link to the runtime (when possible that is), but on bigger things I have always thought of system-wide runtimes to be better (worked on both things), but never really gave it proper thought because I've never been in the position to evaluate a change.

 

About .NET 5 being distributed through Windows Update, you may be right, the only instance I know of where that happens is in a test system at my current work, they have the 2022 preview of Visual Studio installed and if there are updates to .NET 5 they either come through its own update system or Windows Update (if you don't update VS first); but it's in no way representative of the majority of systems, not even the minority, it's more of a niche at the moment.

 

So yep, shipping self contained seems like the better way to go towards having a stable, working program for the majority of users and gives you more control over what goes and what doesn't.