search

oleg-shilo / cs-script.npp

CS-Script (C# Intellisense) plugin for Notepad++ (x86/x64)
MIT License
246 stars 52 forks source link

initial x64 build #13

Closed chcg closed 6 years ago

chcg commented 6 years ago

Build, see https://ci.appveyor.com/project/chcg/cs-script-npp/build/1.7.6.64

oleg-shilo commented 6 years ago

Thank you. Looking forward to see the how far it is in the x64 land. I am on holidays right now so it will need to wait till the next year (a week or so :o)

oleg-shilo commented 6 years ago

Just wanted to let you know that I have started the actual porting to the new x64 hosting model (https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net).

The effort requires significant project restructuring thus please put on hold any modifications based on the current master.

If you must to work on something before the completion x64 porting please use before_x64_porting branch.

chcg commented 6 years ago

The minimum required parts from https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net are already merge with this PR and are functional. I think just if you want to use the new splitted interface you need to port. Be carefull to take the data from the template, as the demo is outdated.

I already worked in the suggestion for VS2017 from https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net/issues/31 to remove the path:

Ok, by simply removing the LibBoolPath attribute on the DllExportTask in NppPlugin.DllExport.targets it works for me in both VS2015 and VS2017. :P

oleg-shilo commented 6 years ago

The minimum required parts from https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net are already merge...

I am not sure thatI follow. I tried to build the merged project and had no luck with hosting x64 binaries at runtime. I also noticed that the correct NPP interface (content of PluginInfrastructure) still wasn't in the codebase.

Anyway, I have already brought the correct "NppPluginNET*.cs" and their dependencies as well as have a working x86/x64 plugin hosting infrastructure. Thus I am really close to get is all together.

And yes, "Ok, by simply removing the LibBoolPath attribute on the " is a silly thing that supposed to be already fixed in the https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net but.... I have also figured this out. Interestingly enough "LibBoolPath" does not upset VS2015 but breaks VS2017 build. But removing it makes both IDEs to build just fine.

chcg commented 6 years ago

Similar to:

    - if "%PlatformToolset%"=="VS15" call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" %archi%
    - if "%PlatformToolset%"=="VS17" call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" %archi%

also the path to the libtool is no longer at: LibToolPath="$(DevEnvDir)\..\..\VC\bin"

, but anyhow the path seems to be set automatically by the IDE, so maybe:

LibToolPath="$(DevEnvDir)....\VC\bin;$(LibToolPath)"

would work similar.

oleg-shilo commented 6 years ago

I also want to use this opportunity to restructure the project by making both core assemblies pure .NET and introducing a lean pure plugin (exported) assembly that simply loads the core assemblies at runtime.

Though this task has its own challenges as it is a canonical cyclic dependency case. But I have solved it by mixing binary and source sharing.

Merging both core assemblies may be somewhat beneficial but not essential (at least at this stage)