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 @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