Customize the location and filename of the native DLLs

[W1zzardTPU]

I'd like to request the ability to customize modulePathScintilla and modulePathLexilla

Right now this isn't possible because the relevant parts in Scintilla.cs are marked as private (not protected)

Another option could be to allow us to define some configuration options, or just expose the statics and make them writeable

[VPKSoft]

Hi,
There is certainly no reason why those paths shouldn't be configurable.
One option would be to create nullable public static string properties which the control would use as primary source and fallback to the defaults.
Other would be to have a property for a nullable Action or Func which would optionally do the initialization via

Scintilla.Something = () => 
{
  // Your code here...
}

Would you like to create a PR as a suggestion for the modification you suggested?

[W1zzardTPU]

Yeah, seems simple enough. Unfortunately I don't have the time at the moment, still wanted to let you know

[VPKSoft]

Thank you

[VPKSoft]

Hi,
Sorry for the silence - I have been busy as always 🙂The original idea is nice, I just don't think it is worth implementing with this much interest and possible useful use cases. If someone creates a PR and the code checks, that is fine, otherwise I'll just leave this hanging here...

[W1zzardTPU]

If you persist, I tested a solution similar to that used by certain products (like Syncfusion) to check the existence of licenses. This solution consists of a function IMPRATIVELY called before the creation of the first instance of the control (see example below) ScintillaNET.Scintilla therefore in the main entry point of the application for the reasons described previously (see https:// learn.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/ms182351(v=vs.80)?redirectedfrom=MSDN).

        static void Main()
         {
             ScintillaNET.Scintilla.SetScintillaDllPath(@"I:\LGProjects\Scintilla\VPK v.5.3.2.7\original\Scintilla.NET-v.5.3.2.7\native");
             Application.EnableVisualStyles();
             Application.SetCompatibleTextRenderingDefault(false);
             Application.Run(new Form1());
         }

And the description of the function:

     /// <summary>
     ///
     /// </summary>
     /// <param name="path">Path or filename of the native Scintilla DLL</param>
     /// <remarks>
     /// If path is a directory, if the scintilla.dll is not in the directory, we search in the path/X(64 or X86, depending on the platform) directory.
     ///
     /// </remarks>
     /// <exception cref="InvalidOperationException"></exception>
     static public void SetScintillaDllPath (string path)

I added a property:

         /// <summary>
         /// Gets the path of the Scintilla.dll user by the control.
         /// </summary>
         [Description("The path of the native Scintilla DLL"), Category("Design")]
         public string ScintillaDllPath => scintillaDllPath;

For the reasons described above: 1 - having referenced the package allows you to call the SetScintillaDllPath(...) function in the program entry point. 2 - This function cannot be called in the Form code. 3 - The native dll Scintilla.dll (version 5xxx) automatically loads the Lexilla.dll dll in the same directory as it, we cannot change the path of Lexilla.dll. 4 - In design mode, this function cannot be called, the native dlls used in this mode are those of the package. 5 - It is possible to call the SetScintillaDllPath function with a path relative to that of the application executable.

Attached a package to test: Scintilla.NET.5.2.9-alpha7.zip (Normaly, following https://learn.microsoft.com/en-us/nuget/concepts/package-versioning, the version should be a 5.3.0-alpahn)

Excellent idea, this approach should work very well. Can you submit a PR?

[W1zzardTPU]

Just after this proposal, I developed a more flexible and open version. If anyone is interested, I can send them the sources because I am not a contributor (nor do I wish to appear as such).

Definitely interested, [email protected]

[desjarlais]

I'm not against the idea...I think there are some inherent challenges and use case aspects to consider, but I'd be interested in hearing you out.

[W1zzardTPU]

"What is the objective of this need to customize modulePathScintilla and modulePathLexilla?" ..."

For me: to be able to ship a single binary, that extracts the DLLs to %TEMP% or another temporary location.
Also not a fan of the two-folder structure with two files each

[W1zzardTPU]

"to be able to ship a single binary, that extracts the DLLs to %TEMP% or another temporary location". Wouldn't you wish that the scintilla and lexilla dlls were embedded into Scintilla.NET?

Sure, but that's not possible from what I understand.. can't load native DLLs from memory

[W1zzardTPU]

For example, you can read https://stackoverflow.com/questions/72264/how-can-a-c-windows-dll-be-merged-into-a-c-sharp-application-exe

Yup that's pretty much what I want to do. Store the DLLs in the binary, extract it to the filesystem, load it from temp.

Boxedapp is not an option because it's closed-source, commercial and using a code cave to load a DLL from memory will get flagged by antiviruses anyway

The other answers are for managed DLLs only

[desjarlais]

@W1zzardTPU for these two comments:

"to be able to ship a single binary, that extracts the DLLs to %TEMP% or another temporary location."
"Also not a fan of the two-folder structure with two files each".

Can you elaborate more on what the scenario is you are trying to accomplish with extracting the dll's to a temp folder? Also, what problem does the two folder structure currently create and what is your suggestion for how to handle all 4 dll's?

[W1zzardTPU]

Can you elaborate more on what the scenario is you are trying to accomplish with extracting the dll's to a temp folder?

To make it work in a portable scenario? Again .. I'm just shipping the EXE, no installer, just double-click to run

Also, what problem does the two folder structure currently create and what is your suggestion for how to handle all 4 dll's?

I'd just detect the right OS conditions and extract what is needed, to a temp location as mentioned before, so it doesn't pollute the user's directly

[desjarlais]

Would you say the temp folder location getting added to the initial check for the native libraries is the best way to accomplish this in your opinion?

[W1zzardTPU]

I would rather have a way to provide a folder, maybe even the full path to the DLL file (including filename)

[Babscoole]

We've an application that uses this. Application is run and the native .dlls are placed a couple of levels up from our application directory. Real world, where this becomes an issue, is user sees a "mystery" directory on their drive and deletes it. It's recreated when the application is run again. User has no idea where it's coming from and believes their system is now infected. This has happened.
Optimal to have some means of specifying where the native dlls are installed to, so we can have them placed in our application directory.

I wish I had the knowledge and skill to generate a fix and post a PR, but I don't.

[Babscoole]

Has there been any traction on this issue? Thanks.

[W1zzardTPU]

Not here, would love to solve this for my application, too