Help to porting SourceCookifier for 64bit
SourceCookifier is written in C# not C++. I know little of either, but have Visual Studio 2017 Community install and after a bit of hacking was able to get SourceCookifier to compile as 64-bit. However, it gives the old “This ANSI plugin is not compatible with your UNICODE N++” …
This is weird because the isUnicode() sub is present and it returns true. Not sure if there’s a compiler flag missing or something.
Anyone who knows C# care to weigh in?
Out of curiosity I gave it a try.
Besides creating a x64 configuration I had to edit
LibToolPathneeds to be set to the path of
lib.exe, for me this was
SdkPathneeds to be set to find
ildasm.exewhich for me was
SdkPath="C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64"
After those changes I was able to build a 64bit version but didn’t do any functional tests as I’m not using this plugin but maybe this enough for you to get started.
Thanks, I needed to do those things as well to get it to compile. The issue is Notepad++ thinks the output DLL is ANSI, not UNICODE. I can’t find an “OutputUnicodeDLL” or some such switch in the C# project files or the MSVC 2017 Community IDE even after much Google-ing.
I haven’t had this issue
Interesting! So if I figure out why it seems I’m outputting ANSI, it should work.
Meta Chuh last edited by
i guess the easiest thing for the op would be if you upload and publish your sourcecookifier x64 unicode test build. eg at your github repo (binary only) or anywhere else.
but that would bring me into a position which I don’t really like,
namely doing some kind of maintenance - it is not really python :-D
Alan Kilborn last edited by
upload and publish your sourcecookifier x64 unicode test build. eg at your github repo (binary only)
but that would bring me into a position which I don’t really like, namely doing some kind of maintenance
Why bin only? One presumes the (source) code fork is already there. And there are plenty of “dead” forks around (so why would you feel obligated to do maintenance).
but if you upload something and offer a solution you will be automatically
the primary person to contact if something doesn’t work as expected as you have
provided that plugin/source code.
Alan Kilborn last edited by
Ha. Nah. All you did was fork something and play around with it. Plenty of examples of people doing that on github. Only if you go so far as to take real ownership do you get into the situation you talk about. :)
Agree - that’s what I’ve been doing with un-maintained N++ plugins. Fork, it improve for me and post if others want it. I don’t plan on trying to include it in the nppPluginList which I think would be the real “taking ownership” thing.
Alan Kilborn last edited by Alan Kilborn
…include it in the nppPluginList which I think would be the real “taking ownership” thing.
Well, you could go that far if you wanted to, and (I’d say) if you got the original author’s permission…but it is up to you.
Downside to not doing this: How would others know about the existence of these plugins (the “column” one especially I look forward to trying out).
@Ekopalypse What version of the Microsoft SDK are you using to compile? Is it version 7? What version of Visual Studio Community?
I’m using VS Comm 2017 and version 10 of the SDK (v10.0A). I’m getting weird errors and overflows when trying to run the successfully build DLL in N++. Wondering if the supplied DLL in DLLExport are geared for an older version of Visual Studio and / or SDK?
More troubling, the same set of tools / versions on Windows 7 actually works for me - my successful build actually runs in N++ without crashing it. But copy that good DLL to Windows 10 and save errors. I wonder if there’s a redistributable that I have on Windows 7 and not on 10? I just don’t know/ understand C#.
Yes, I’m using Win7 as well and I was using VS 2017 community edition and SDK 7.
Unfortunately I don’t have Win10 - so cannot confirm your findings.