Community
    • Login

    Update NotepadPlusPlusPluginPack.Net DllExport Function

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    16 Posts 4 Posters 1.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Guido ThelenG
      Guido Thelen
      last edited by

      First I would like to thank Kapser and others for creating and maintaining the NotepadPlusPlusPluginPack.Net project. This makes developping N++ Plugins using .net and C# really easy.

      I understood that the dllExport functions are mandatory to build the plugin’s dll. The dllExport currently requires .Net Framework 3.5 to be installed. Net Framework 3.5 is still available but I wonder how long it will still be availabe. Therefore I am asking the N++ community if you have ideas/suggestions how we could upgrade this function to a higher .Net Versioin.
      Unfortunately I do not understand how this process is working and how it could be upgraded.
      Is there anybody in the N++ Cmmunity of .Net developpers who knows more about this?

      Regards
      GuidoMarcel

      PeterJonesP 1 Reply Last reply Reply Quote 1
      • PeterJonesP
        PeterJones @Guido Thelen
        last edited by PeterJones

        @Guido-Thelen ,

        As described here, @Mark-Olson forked that unmaintained plugin pack to https://github.com/molsonkiko/NppCSharpPluginPack . It’s already listed in the User Manual.

        Thus, Mark will probably chime in soon with information about the Framework now used and plans going forward.

        1 Reply Last reply Reply Quote 2
        • Mark OlsonM
          Mark Olson
          last edited by Mark Olson

          NppCSharpPluginPack uses .NET Framework 4.8 and probably always will. There are a few reasons for this:

          • Versions of .NET Framework older than 4.8 are not supported out-of-the-box by Visual Studio 2022, which is the only development environment I develop C# in.
          • The GitHub action that I use for the plugin pack doesn’t work with older versions of .NET Framework
          • If I switched to .NET Framework 4.8.1 (or anything newer) a lot of older versions of Windows 10 would no longer natively support the plugin
            • unfortunately, Windows 8 and older do not natively have .NET Framework 4.8, but my understanding is that very few people have such an old OS
          • The newest versions of C# that can be used with .NET Framework 4.8 are way nicer (have more useful features, are probably faster and safer) than the newest versions usable with older .NET Framework versions.

          If somebody else wanted to fork NppCSharpPluginPack and make it work for an older version of .NET Framework, they are welcome to try, but I won’t help them do it.

          Guido ThelenG 1 Reply Last reply Reply Quote 3
          • Guido ThelenG
            Guido Thelen
            last edited by

            @Mark-Olson , @PeterJones ,
            these are very good news. An upgrade to 4.8 is fantastic.
            I will have a look to your fork and give it a try.
            Thanks!!

            1 Reply Last reply Reply Quote 0
            • Guido ThelenG
              Guido Thelen @Mark Olson
              last edited by Guido Thelen

              @Mark-Olson I think, I need some guidance. Reading the architecture documentation at https://github.com/molsonkiko/NppCSharpPluginPack/blob/main/PluginPackArchitecture.md it says that we should download a release (the VS template) and place it (the NppPlugin.zip) in the visual studio path (typically “My Documents\Visual Studio 20xx\Templates\ProjectTemplates\Visual C#”)

              Where can we find the new zipped template file in your forked repo?
              Probably I did not yet understand how to use your new repo
              Regards
              Guido

              PeterJonesP 1 Reply Last reply Reply Quote 0
              • PeterJonesP
                PeterJones @Guido Thelen
                last edited by PeterJones

                @Guido-Thelen ,

                I’ve never used it, but looking at the page you linked, vs the front page for the new project, here is what I discovered:

                The PluginPackArchitecture.md still links to the Releases page for the old project.

                But if you instead just read the front page when you go to https://github.com/molsonkiko/NppCSharpPluginPack directly, the Downloads and Installation section has a link to the new pack’s Releases page for getting older versions, or direct “Download latest 32-bit version” and “Download latest 64-bit version”. If you click the third of those, you will get the 64bit version of the zipfile you desire.

                8914c2b2-b54e-4e4a-ab96-0ca86d7a30dd-image.png

                So @Mark-Olson should probably update that inner PluginPackArchitecture.md page in his project, but the right instructions do appear to be on the main project page (which is where I’d always look first for most recent installation information for any GitHub project.)

                Guido ThelenG 1 Reply Last reply Reply Quote 2
                • Guido ThelenG
                  Guido Thelen @PeterJones
                  last edited by

                  @PeterJones Hi Peter, thanks for your answer. The “download latest 32/64 bit version” links are for the N++ Plugin itself (CSharpPluginPack) but not for the VS2022 project template. Maybe the template from Kasper is still the one to be used or do we copy the Infrastructure folders manually to VS2022 project?
                  Regards
                  Guido

                  rdipardoR 1 Reply Last reply Reply Quote 0
                  • rdipardoR
                    rdipardo @Guido Thelen
                    last edited by rdipardo

                    @Guido-Thelen, if it answers your question, there is no 2022-edition equivalent of @Kasper-Graversen’s *.vstemplate project, which is a special kind of project that adds a “Npp Plugin” item to the IDE’s “New Project” menu, if you follow the old installation instructions.

                    The new template is a fully “instantiated” Visual C# project targeting VS 2022. You are supposed to start working on that project, then change everything to suit your individual use case.

                    1 Reply Last reply Reply Quote 2
                    • Mark OlsonM
                      Mark Olson
                      last edited by

                      @Guido-Thelen

                      Thanks for pointing out those sources of confusion. I’ve changed the README to hopefully be more helpful.

                      Try reading the instructions in this section and let me know if are still confused.

                      Guido ThelenG 1 Reply Last reply Reply Quote 2
                      • Guido ThelenG
                        Guido Thelen @Mark Olson
                        last edited by

                        @Mark-Olson This is excellent, now. Many thanks!!

                        Guido ThelenG 1 Reply Last reply Reply Quote 0
                        • Guido ThelenG
                          Guido Thelen @Guido Thelen
                          last edited by

                          May I draw your attention to the dllExport functions again?
                          When I install the dllExport functions from the PluginInfrastructure folder, I need to install in VS2022 also the .NET Framework 3.5. Is it the same for you? It looks like the dllExport functions is using feature which are not available for .net > 3.5. is my observation correct?

                          rdipardoR Mark OlsonM 2 Replies Last reply Reply Quote 0
                          • rdipardoR
                            rdipardo @Guido Thelen
                            last edited by

                            @Guido-Thelen

                            The .NET 3.5 dependency comes from the (obsolete) ILMerge tool, which is used to edit the binary content of your plugin assembly. Note where the original documentation says:

                            ILMerge can work with .NET 3.5 and below. . .

                            You would only need that if your plugin references third-party .NET libraries and you want to physically copy them into a “merged” plugin assembly. The alternative is to package your plugin with all its dependencies and load them at runtime, as some .NET plugins already do.

                            You should be able to safely delete whatever build task needs ILMerge. At worst, you may have to launch the Visual Studio Installer and get the .NET 3.5 development tools — not the “targeting pack,” which isn’t available anyway:

                            vs-2022-net35-build-tools.png

                            Guido ThelenG 1 Reply Last reply Reply Quote 3
                            • Guido ThelenG
                              Guido Thelen @rdipardo
                              last edited by

                              @rdipardo yes, this is exactly my situation :-)
                              Any suggestion where to find the build tasks which need ILMerge.?

                              Regards
                              Guido

                              rdipardoR 1 Reply Last reply Reply Quote 0
                              • Mark OlsonM
                                Mark Olson @Guido Thelen
                                last edited by Mark Olson

                                @Guido-Thelen said in Update NotepadPlusPlusPluginPack.Net DllExport Function:

                                I need to install in VS2022 also the .NET Framework 3.5. Is it the same for you?

                                I don’t think I need to do that, looking at my installed extensions. Are you on Windows 11? Because that might explain it. I’m still on Windows 10.

                                In any case, I defer to rdipardo’s expertise on the subject of ILMerge and the other things that relate to exporting to a DLL. The sad truth is that I haven’t actually taken the time to understand every facet of this template; I only really know the parts that I interact with directly.

                                It would be nice to shed the dependency on ILMerge, as that might fix the annoying bug (solved by NppCSharp/Utils/NanInf.cs) that causes double.NaN and +/-double.Infinity (and anything that evaluates to those at compile time) to cause a compiler error.

                                1 Reply Last reply Reply Quote 0
                                • rdipardoR
                                  rdipardo @Guido Thelen
                                  last edited by

                                  So @Guido-Thelen is right and there really is a legacy dependency at the heart of the template, including the latest version, and it’s more fundamental than ILMerge. Fortunately it’s a development dependency, so end users won’t have to know about it.

                                  TL;DR Every .NET plugin developer needs to install a very old version of MSBuild (2.0.0.0), which the Framework 3.5 development tools will provide, but you must install that separately into your Visual Studio instance, as illustrated above.

                                  Just to make sure, I used a Windows 10 PC with no Framework 3.5 runtime at all:

                                  win10-no-net35-rt.png

                                  No Framework 3.5 development tools either, just the essential components for Framework 4.8+ development, as the exported configuration shows:

                                  {
                                    "version": "1.0",
                                    "components": [
                                      "Microsoft.VisualStudio.Component.Roslyn.Compiler",
                                      "Microsoft.Component.MSBuild",
                                      "Microsoft.VisualStudio.Component.CoreBuildTools",
                                      "Microsoft.VisualStudio.Workload.MSBuildTools",
                                      "Microsoft.VisualStudio.Component.Windows10SDK",
                                      "Microsoft.VisualStudio.Component.VC.CoreBuildTools",
                                      "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
                                      "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
                                      "Microsoft.VisualStudio.Component.TestTools.BuildTools",
                                      "Microsoft.Net.Component.4.8.SDK",
                                      "Microsoft.VisualStudio.Component.TextTemplating",
                                      "Microsoft.VisualStudio.Component.VC.CoreIde",
                                      "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
                                      "Microsoft.VisualStudio.Component.Windows10SDK.19041",
                                      "Microsoft.VisualStudio.Workload.VCTools",
                                      "Microsoft.VisualStudio.Component.NuGet.BuildTools",
                                      "Microsoft.Net.Component.4.8.TargetingPack",
                                      "Microsoft.Net.Component.4.8.1.SDK",
                                      "Microsoft.Net.Component.4.8.1.TargetingPack",
                                      "Microsoft.VisualStudio.Component.NuGet"
                                    ],
                                    "extensions": []
                                  }
                                  

                                  I clone the NppCSharpPluginPack source tree and run msbuild /v:diag NppCSharpPluginPack\NppCSharpPluginPack.sln.

                                  The assembly builds just fine, — I get a *.dll and matching *.pdb both in NppCSharpPluginPack\bin\Debug-x64.

                                  The one and only build error comes from the “AfterBuild” target of the imported NppPlugin.DllExport.targets project:

                                  C:\git\NppCSharpPluginPack\NppCSharpPluginPack\PluginInfrastructure\DllExport\NppPlugin.DllExport.targets(13,5): error MSB4062: The "NppPlugin.DllExport.MSBuild.DllExportTask" task could not be loaded from the assembly C:\git\NppCSharpPluginPack\NppCSharpPluginPack\PluginInfrastructure\DllExport\NppPlugin.DllExport.MSBuild.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5
                                  f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Bui
                                  ld.Framework.ITask.
                                  

                                  You will notice there are binary assemblies under the PluginInfrastructure\DllExport tree. I think these were extracted from a NuGet package and checked into source control. The originating package has not been updated since before @Kasper-Graversen published the first template in 2016.

                                  But these dusty old assemblies are the key to interoperating with native C++ applications. Without them, your plugin is just a .NET library. There is no simple replacement for this legacy code, which we only have in binary form.

                                  If somebody could dig up the original source of the DllExport assemblies, maybe they could be rebuilt for newer Framework targets. Though I guess a build dependency on Framework 3.5 isn’t so bad as long as Visual Studio keeps on supporting it.

                                  Guido ThelenG 1 Reply Last reply Reply Quote 3
                                  • Guido ThelenG
                                    Guido Thelen @rdipardo
                                    last edited by

                                    @rdipardo said in Update NotepadPlusPlusPluginPack.Net DllExport Function:

                                    a build dependency on Framework 3.5 isn’t so bad as long as Visual Studio keeps on supporting it.

                                    Yes, let’s hope that .net Framework 3.5 will be supported/available for future Visual Studio Versions.

                                    @rdipardo , thanks for digging into this.

                                    I contacted the author from the UnmanagedExport Nuget Package asking if the package could be made available for higher .net versions. Let’s see

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    The Community of users of the Notepad++ text editor.
                                    Powered by NodeBB | Contributors