About my missing Print It-SOLVED

[Scooter]

Not needing the Print It effect for some time, I've just discovered that it is not in the designated place on the Effects/Tools menu. (note: enclosed graphics)

Though I seem to have two files of each, dated differently and of different sizes. I have not had any problem using it until today.   I have turned Paint.net off and back on, I would reload the files from Martin's original plug in (as recommended to another member, but am concerned that it may:  1) interfere with XX---or something.

                                                                                                                                                                                                2) could be a result of the last PdN up date ?

                                                                                                                                                                                                3) with my luck cause an melt down.

Suggestions from you all?

 

[midora]

@Scooterpaint.net 4.3 forces you to place the OptionBasedLibrary files in the Effect folder (and in the FileTypes folder if a fileType is using the OBL).

[Rick Brewster]

"forces" is a strong word. These files should never have been placed in the main application folder to begin with. 

[midora]

There was no other logical place where you could share the lib for Effects and FileTypes (not different as for the shared paint.net dlls).

[Reptillian]

1 minute ago, midora said:

There was no other logical place where you could share the lib for Effects and FileTypes (not different as for the shared paint.net dlls).

This isn't a issue.

 

Two ways to remedy this problem:

1. Copy and paste to different places
2. Symbolic Linking

I would use symbolic link.

[midora]

I will not open this discussion again. I'm just telling there was a reason 5 years ago to choose a single place for a shared library. It's no longer allowed by the rules and blocked in paint.net 4.3. Linking is not an option which can be managed by a user (and it's against my interpretation of the rules).

[Scooter]

Thank you all for your attempts to answer my problem.  As “computer Program-ery” is not a language I understand. I would like to ask if there is a simple “do this then do that” sort of answer that could be possible.     My interest in the arcane history and workings of the programing in question, though I’m sure is most enlightening to some, is not what I was asking for. Please don’t think me ungrateful for your time and offerings, but they, at this time, are not what I was needing.

  With Respect, I remain,

[Rick Brewster]

4 hours ago, midora said:

There was no other logical place where you could share the lib for Effects and FileTypes (not different as for the shared paint.net dlls).

 

You never came to me asking for or looking for another solution. 

 

1 hour ago, midora said:

I will not open this discussion again.

 

Excuse me? I'll open the discussion if I want. As much as I'd rather not throw dirt in @Scooter's thread here, you made a mess for everyone who's installed your plugins and you've refused to acknowledge that nor accept any responsibility for it, and have been rather flippant to me in every conversation about it. Your attitude stops now or you're gone.

[Rick Brewster]

31 minutes ago, Scooter said:

Thank you all for your attempts to answer my problem.  As “computer Program-ery” is not a language I understand. I would like to ask if there is a simple “do this then do that” sort of answer that could be possible.     My interest in the arcane history and workings of the programing in question, though I’m sure is most enlightening to some, is not what I was asking for. Please don’t think me ungrateful for your time and offerings, but they, at this time, are not what I was needing.

  With Respect, I remain,

 

In your C:\Program Files\paint.net folder there will be files named "OptionBasedLibrary". These should be moved to the Effects folder.

[Scooter]

7 hours ago, Rick Brewster said:

 

In your C:\Program Files\paint.net folder there will be files named "OptionBasedLibrary". These should be moved to the Effects folder.

Thank You, Rick. I shall do just that.  I do hate to further the quandary but as noted in the original post I have two (2)  sets ( i.e. revisions)  of the "OptionBasedLibrary"s ; would I be correct in deleting the older version (at its current location-the main application folder ) and only moving the more recent version to the Effects folder.? 

With Respect, I remain,

[Rick Brewster]

13 minutes ago, Scooter said:

Thank You, Rick. I shall do just that.  I do hate to further the quandary but as noted in the original post I have two (2)  sets ( i.e. revisions)  of the "OptionBasedLibrary"s ; would I be correct in deleting the older version (at its current location-the main application folder ) and only moving the more recent version to the Effects folder.? 

With Respect, I remain,

 

With OptionBasedLibrary you need every version. Different plugins will use different versions.

[Scooter]

7 minutes ago, Rick Brewster said:

 

With OptionBasedLibrary you need every version. Different plugins will use different versions.

Will do Thanks. 

[kreemoweet]

Print It plugin is broken no matter where you put those OBL files.

 

File: C:\Program Files\paint.net\Effects\PrintIt.Effect.dll
      Name: OptionBasedEffects.PrintIt
      Version: 0.9.0.1162
      Author: Martin Osieka
      Copyright: © 2014, ComSquare AG, Switzerland
      Website: http://forums.comsquare.ch/viewforum.php?title=Paint.NET Tools
      Full error message: System.IO.FileNotFoundException: Could not load file or assembly 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at ControlExtensions.PrinterInfos.Property(String printerName, String propertyName)
   at ControlExtensions.PrinterInfos.PrinterStatus(String printerName)
   at OptionControls.OptionPrinterDevice.PopulatePrinterStatusInfo()
   at OptionControls.OptionPrinterDevice.UpdateFromPrintDocument()
   at OptionControls.OptionPrinterDevice.OnValueChanged()
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
   at OptionControls.OptionPrinterDevice..ctor(Enum optId, OptionContext optContext, VirtualPrintDocument vpd)
   at OptionBasedEffects.PrintIt.OnSetupOptions(OptionContext optContext)
   at OptionBased.Effects.OptionBasedEffect.CreateConfigDialog()
   at PaintDotNet.Menus.EffectMenuBase.RunEffectImpl(IEffectInfo effectInfo) in D:\src\pdn\src\PaintDotNet\Menus\EffectMenuBase.cs:line 846

 

[Scooter]

12 hours ago, kreemoweet said:

Print It plugin is broken no matter where you put those OBL files.

 

File: C:\Program Files\paint.net\Effects\PrintIt.Effect.dll
      Name: OptionBasedEffects.PrintIt
      Version: 0.9.0.1162
      Author: Martin Osieka
      Copyright: © 2014, ComSquare AG, Switzerland
      Website: http://forums.comsquare.ch/viewforum.php?title=Paint.NET Tools
      Full error message: System.IO.FileNotFoundException: Could not load file or assembly 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at ControlExtensions.PrinterInfos.Property(String printerName, String propertyName)
   at ControlExtensions.PrinterInfos.PrinterStatus(String printerName)
   at OptionControls.OptionPrinterDevice.PopulatePrinterStatusInfo()
   at OptionControls.OptionPrinterDevice.UpdateFromPrintDocument()
   at OptionControls.OptionPrinterDevice.OnValueChanged()
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
   at OptionControls.OptionPrinterDevice..ctor(Enum optId, OptionContext optContext, VirtualPrintDocument vpd)
   at OptionBasedEffects.PrintIt.OnSetupOptions(OptionContext optContext)
   at OptionBased.Effects.OptionBasedEffect.CreateConfigDialog()
   at PaintDotNet.Menus.EffectMenuBase.RunEffectImpl(IEffectInfo effectInfo) in D:\src\pdn\src\PaintDotNet\Menus\EffectMenuBase.cs:line 846

 

Hummm, Curiouser and curiouser, this particular tangle of 1s and 0s. 😕    

Perhaps one of the members has a functional work around or at least a good idea as to returning the  functionally to PrintIt ?

Though to be honest, it seems from the exchanges above, there are some deep-seated severe issues as to the original location of the file; that are just now being overtaken by the current improvements to paint.net.

I hope the  issue can be rectified for the good of all the members, (especially me, as I am in need of the PrintIt functionality for a current assignment that has a fast approaching dead line) 😟

Hope springs eternal.

[Scooter]

brief  update: I to, received an error. 

File: C:\Program Files\paint.net\Effects\PrintIt.Effect.dll
      Name: OptionBasedEffects.PrintIt
      Version: 0.9.0.1162
      Author: Martin Osieka
      Copyright: © 2014, ComSquare AG, Switzerland
      Website: http://forums.comsquare.ch/viewforum.php?title=Paint.NET Tools
      Full error message: System.IO.FileNotFoundException: Could not load file or assembly 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at ControlExtensions.PrinterInfos.Property(String printerName, String propertyName)
   at ControlExtensions.PrinterInfos.PrinterStatus(String printerName)
   at OptionControls.OptionPrinterDevice.PopulatePrinterStatusInfo()
   at OptionControls.OptionPrinterDevice.UpdateFromPrintDocument()
   at OptionControls.OptionPrinterDevice.OnValueChanged()
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
   at OptionControls.OptionPrinterDevice..ctor(Enum optId, OptionContext optContext, VirtualPrintDocument vpd)
   at OptionBasedEffects.PrintIt.OnSetupOptions(OptionContext optContext)
   at OptionBased.Effects.OptionBasedEffect.CreateConfigDialog()
   at PaintDotNet.Menus.EffectMenuBase.RunEffectImpl(IEffectInfo effectInfo) in D:\src\pdn\src\PaintDotNet\Menus\EffectMenuBase.cs:line 846

SIGH

[otuncelli]

Here is a workaround.

 

The plugin should include System.Management.dll.

 

You can get it from here: https://nuget.info/packages/System.Management/5.0.0 

Double Click on runtimes->win->lib->netcoreapp2.0->System.Management.dll

Put this DLL in the same folder as other plugin' files.

 

 

It should work if you're using the plugin from the first page.

 

But if you're using this one, it'll crash if you click on the "Menu". Because it links to OptionBasedLibrary v0.8.dll which is not qualified for shimming by Paint.NET. Maybe @Rick Brewster can do something about this for the upcoming Paint.NET release?

 

Exception details:
System.TypeLoadException: Could not load type 'System.Windows.Forms.ContextMenu' from assembly 'System.Windows.Forms, Version=5.0.10.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
   at ControlExtensions.ControlSplitButton.OnMouseDown(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, WM msg, IntPtr wparam, IntPtr lparam)

 

Edited October 28, 2021 by otuncelli

[Rick Brewster]

I was not aware that there was an OptionBasedLibrary v0.8, I only knew of v0.7.9 and earlier. I can look into it. 

[Scooter]

On 10/28/2021 at 4:59 AM, otuncelli said:

Here is a workaround.

 

The plugin should include System.Management.dll.

 

You can get it from here: https://nuget.info/packages/System.Management/5.0.0 

Double Click on runtimes->win->lib->netcoreapp2.0->System.Management.dll

Put this DLL in the same folder as other plugin' files.

 

 

I

 

 

otuncelli  Thank You.  Your solution worked (as our Brit. friends say ) "a treat" . Granted in my usual excessive cautionary worry wort-ness I slowly "plot out" the work making sure I had the correct 1 of the 2 choices you gave. long story short , I found the folder, I sent the sys. man. dll , I received the long lost PaintIt back and its running fine. Your helpful reply was just the answer I was needing to achieve this correction.  I hope others having the same problem will try this solution. Again Thank You.

[Rick Brewster]

On 10/28/2021 at 8:23 AM, Rick Brewster said:

I was not aware that there was an OptionBasedLibrary v0.8, I only knew of v0.7.9 and earlier. I can look into it. 

 

I just looked into this. OBL v0.8 is using reflection to reach into Paint.NET's internal app/object model to do things it shouldn't be doing (via the "PaintDotNetEx" class). This has been explicitly prohibited in the "Plugin Rules" for many years (since its inception, in fact), and OBL v0.8 looks like it was published earlier this year. I will not be shimming this. Both OBL and PrintIt will need updated versions that do not do this sort of thing.

[Rick Brewster]

@midora Do not publish a version of OBL that uses reflection to reach into Paint.NET ever again. You know this is blatantly against the rules and yet you do it anyway. This is your only warning.

[midora]

Rick, we are talking about plugin versions which are older than 5 years. OBL was used by others before a final version has been published (because of my break). I totally accept your rules and that you are enforcing them now stronger than earlier. I didn't publish anything which was against the rules since I returned beginning of the year. So it's a little bit unfair to attack me about this old stuff.

 

But if you think there is no value in my work than block me and remove the old stuff. It will not hurt me. I'm just asking myself why you are so angry. But OK. Sometimes we may have a different opinion about sw development but that's nothing unusual between developers. Maybe you are just frustrated about the amount of work to get all these old plugins to run. Let them die and remove the threads if its too much work and no fun for you.

 

Maybe you should also have in mind that English is not my native language. So if I'm using the word 'force' it may have a little bit different semantic. I just used it to explain that - against mentioned in the plugin documentation - paint.net no longer allows you to place OBL in the paint.net root (which worked with older paint.net versions and nobody complained in all the years). If you had complained 5 years ago I would have changed it at this time.

 

I'm not sure why inactive code should harm paint.net but if you care about this then for sure I will not use it in newer plugins. There are other solutions to reach the same effect for my private workflow. It's not true that I didn't ask for an other solution using a shared library.

 

[otuncelli]

It seems "fixed" now 😂 I mean, that plugin was old (7 years), it broke the rules so it shouldn't have been published on this forum. But, with all that shimming and compatibility patches, it was working fine so far. 

 

I have a suggestion. Maybe Paint.NET can allow to bypass plugin blacklist with a switch similar to /disablePlugins (maybe /allowUnsafePlugins ? ). So anyone who using them or maybe dependant on them can continue to use them on new PDN releases with being aware of the consequences (may crash, behave differently etc...).

[BoltBait]

3 hours ago, otuncelli said:

I have a suggestion. Maybe Paint.NET can allow to bypass plugin blacklist with a switch similar to /disablePlugins (maybe /allowUnsafePlugins ? ). So anyone who using them or maybe dependant on them can continue to use them on new PDN releases with being aware of the consequences (may crash, behave differently etc...).

 

The problem is @midora had included a hidden command in that plugin (something he never told anyone about) that used reflection (something @Rick Brewster doesn't allow in plugins).  Midora did this for his own use--which is totally fine.  However, he then published his plugin on the forum.

 

The simple solution is for Midora to publish a build of the plugin that doesn't have that hidden command.

 

The Print-It plugin is brilliant and I would hate to lose it.  But, rules are rules.

 

[midora]

59 minutes ago, BoltBait said:

The simple solution is for Midora to publish a build of the plugin that doesn't have that hidden command.

 

But this would violate the rules

 

On 12/15/2008 at 9:44 AM, Rick Brewster said:

When a new plugin or a new plugin update is published, it must work on the latest public/stable release of Paint.NET. 

 

BTW: Because the first entry in 'Rules for plugins that are published on this forum' is work in progress I can only reference

  

On 1/23/2016 at 8:20 PM, Rick Brewster said:

New rule added to clarify this. see also: http://forums.getpaint.net/index.php?/topic/107032-tile/#entry511100

 

Quote

Plugins must not use reflection to reach into Paint.NET's internals.

 

Means this rule has been added years after the plugin has been published and I wasn't active at this time.

Maybe there was a 'should not use reflection rule' in 2014.

 

Sorry but there is no quick solution. OBL is work in progress and there is no ETA.

 

 

 

 

[Rick Brewster]

Claiming OBL is "a work in progress" and thus you're not doing anything wrong, nor have any responsibility for this mess, is incorrect. Real plugins have been published which use OBL, real users download those plugins, and they depend on them for their workflow and creative flows. These plugins were not tagged as "beta" or "pre-release" or "in-development." At best you've been sloppy, reckless, irresponsible, and have a complete lack of empathy.

 

Quote

But if you think there is no value in my work than block me and remove the old stuff.

 

I did not say there's no value in your work. Clearly many developers and users see value in your library and the plugins based on it. If that were not the case, there really wouldn't be a problem -- if nobody was really even using these plugins, I could just block them and move on. What you don't understand is that plugins are very popular. Lots and lost of people use them. Not 10s of people, or 100s. But, 10s of thousands and potentially 100s of thousands of people, maybe even millions. It isn't just the relatively small number of people you see engaged in discussion here on the forum.

 

Quote

Sometimes we may have a different opinion about sw development but that's nothing unusual between developers.

 

That's the thing. We're not developers on two unconnected projects, or even developers on the same project. Your code is in "my house", and when we have a difference of opinion on something like this, my opinion is the one that wins. You can't just shrug it off like it's no big deal. It's my app, my product, my business, and the lives of the people who use Paint.NET who're affected. Not you. If I say "don't do X" you don't get to just "lol" and do it anyway, or shrug it off like some casual difference of opinion between peers. We are not peers.

 

Quote

Maybe you are just frustrated about the amount of work to get all these old plugins to run. Let them die and remove the threads if its too much work and no fun for you.

 

See above comment about real people depending on plugins for their real work and real creativity. Old plugins don't die, they sit on people's computers forever, often getting frequent use and being depended on. "Real people" don't check back on the forum to meticulously check whether their plugins are updated, obsoleted, etc. And even if they did, many people have HUNDREDS of plugins installed and that just wouldn't be practical. Old plugins are still depended on, and I try my best to ensure their compatibility, because that's the right thing to do for the users of Paint.NET.

 

Here's the big issue. By violating these rules, by using reflection to access Paint.NET's internals, and publishing or allowing the publication of plugins that do that (or by just not saying anything when they are published), you're putting me in a terrible position. Either I have to support what your plugin/library does, which means bending over backwards and not breaking it when/if possible, and which hinders progress on Paint.NET's development, or I have to block the plugin/library and become "the bad guy," potentially ruining people's workflows and creative flows. People get upset when things are broken like this, and whether it's my fault or not it's my responsibility. You've indicated clearly you don't take any responsibility for this, but I take backwards compatibility very seriously and I don't like breaking things for reasons that normal users don't care about nor understand (and why should they have to understand or care?). If someone's plugins break when they install a Paint.NET update, they are likely to try and revert to the old version, tell all their friends not to update ("it's broken"), and it also degrades my reputation of providing high quality software that doesn't break or crash. You are harming Paint.NET with your actions.

 

I don't mind putting in work to shim plugins to get them to work, at least when it's for innocent things like using ContextMenu or for various things that I want to remove from the app and that I can easily provide workarounds for. But I do mind very much when you blatantly break rules that have been in place for many years, long before you broke them, rules which are there to ensure Paint.NET can continue evolving and growing without breaking people's workflows and creativity, and then just shrug it off like you did nothing wrong and you're not responsible for the resulting mess for me and for real users. "No reflection" has been there since the the rules were posted in 2008, and you clearly didn't read those rules and/or you don't care about them at all.

 

I spent weeks working on the compatibility shims for various plugins, including and especially those that use OBL. I will never support your plugins or libraries like this ever again, and anyone who is thinking of using OBL for a new plugin (or even an update to an existing plugin) would be wise to abandon that idea.