kbilsted / NotepadPlusPlusPluginPack.Net

.Net package to install into visual studio to make plugins for Notepad++
Apache License 2.0
166 stars 52 forks source link

.NET and ANSI?? Plugin cannot be loaded #114

Closed LexaGV closed 11 months ago

LexaGV commented 11 months ago

I try to make x64 plugin for my x64 N++ (on Win7 x64 with VS 2022). I got strange error after compiling my project:

...c:\Program Files\NotepadPP\plugins\NppDecodeUrl\NppDecodeUrl.dll This ANSI plugin is not compatible with your Unicode Notepad++.

Sorry, what?? Since when .NET have to deal with outdated rubbish like ANSI? All .NET apps support Unicode and only unicode. How this error appeared at all?

Small history: I played with "Guid" plugin and it worked well. Then I created my own project ".NET library" and added all files from "PluginInfrastructure" folder. Then I created Main class, added necessary fields/methods - it compiled successfully. Then copied result DLL into /plugins/ and started N++, but got this "ANSI error" - why?

I lost a whole hour jumping between settings of project, but didn't find ANYTHING related ansi. BTW zip file with project template doesn't work - VS simply cannot see this template (even unpacked).

LexaGV commented 11 months ago

OK, I got what is a problem... Meh, I waste SO MUCH TIME on that 1d1ot... I have no another words for that "smartie" who made such "trap". Explanation:

When you compiled your plugin, it obviously stays in your bin\Debug. As a smart dev you try to automate process of deployment. What you do? You define "AfterBuild" task, which just copies your DLL into N++\plugins folder. NOT SO FAST, dude! That mentioned "smartie" made... HIS OWN task for "AfterBuild"! So when you define your "AfterBuild", his "AfterBuild" do not work. But what it does, actually? Nobody can say for sure, but at least it MODIFIES YOUR DLL (probably, inserting some attributes). As a result, if your DLL didn't pass his "screwer", it simply won't work! What a stupidity......

Even if you found only one clumsy solution (to screw DLLs) AT LEAST it worth to MENTION IN DOCUMENTS!!! What a negligence to keep this important conversion hidden! facepalm Second, why the hell you occupy "AfterBuild" event? IT IS NOT YOUR. Define own task or even better - create separate CONSOLE TOOL, which can be used at any time under control of developer. Third, I would find better solution than "fixing" alien's DLL - why not just give developer "special attribute"?? I write plugin, put proper attribute and viola - it works WITHOUT CONVERSION!

I'm so angry at these stupid solutions... Why not DISCUSS THEM? Before you do smth stupid, always consult more experienced developers, they have TENS solutions for your task! (most of your task already solved, BTW)

Well, I wasted my time on this clumsy "solution", but hope nobody will waste again! FIX THE DOC and don't touch "AfterBuild" - listen your engineer inside.

kbilsted commented 11 months ago

Thanks for your feedback. Please consider contributing to free and open source projects. Being rude and crying like a baby won't get you very far.

mahee96 commented 11 months ago

@kbilsted , I too feel the same, pointing out issues and help fixing it is one thing, whereas nit picking and complaining about passively maintained project is on whole another level...🤦🏼‍♂️

@LexaGV, try to understand how the Plugin Infrastructure works and fix it if you need solution immediately or wait until the maintainers look at what the problem is and provide feedback!

LexaGV commented 11 months ago

@kbilsted : crying was your mom, when I made you. I don't cry - I explain how stupid it was - to make hidden conversion of DLLs.

LexaGV commented 11 months ago

@mahee96 : are you seriously so "stupidly optimistic" that think it's rational "fix it if you need"??? Sorry, in FOSS there is BILLIONS stupid decisions and just to understand their code you need to spend time! I'm not Duncan Mclaud to inspect, understand and fix ALL errors I see! So relax with your useless advices, THEY DO NOT WORK.

What is working: when people complain about smth, pause your selfish existence and pay attention on the problem they point. Understand WHY it become problem. Offer solution. DISCUSS solution. Fix the problem and publish your code. Obviously AUTHOR of that library has big advantage compare to me (because he understands his code). So my minimal actions done: I FOUND and explained problem - hidden conversion of DLLs (what a stupidity!!). Now it's turn of author:

  1. AT LEAST explain in docs that DLLs have to be screwed before they come to N++/plugins
  2. Make console tool (instead of MSBuild task) of that converter (because some people DO NOT use MSBuild at all)
  3. Try to explain what he does during conversion - MAYBE there is another much easy and obvious way to make DLLs visible by N++

Stupidity cannot be "swallowed" - it must be exposed and fixed.

LexaGV commented 11 months ago

@kbilsted bhah :)) Just found YOU are author of the project. Dude, you could AT LEAST say sorry that you made such "timebomb" in your solution! I would blush if I make dilettantish code and people HAVE PROBLEM with it. Anyway all said is still in charge - your "way of conversion" is quite dilettantish and dangerous, it's time to make it proper way. At least to avoid issues when people define own "AfterBuild", which YOU occupied with your converter. BTW why converter is closed source??

kbilsted commented 11 months ago

Closing toxic