Update NotepadPlusPlusPluginPack.Net DllExport Function

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 Thelen

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

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

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.

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 Thelen

@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

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.

Mark Olson

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

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

Guido Thelen

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?

rdipardo

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

Guido Thelen

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

Regards
Guido

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.

rdipardo

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:

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 Thelen

@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