Deploying a solution with ScintillaNET in visual studio

Topics: Developer Forum, User Forum
Oct 2, 2012 at 4:25 PM

I've been working on an application that uses ScintillaNET. During development I followed the "getting started"- guide and placed the .dll-files and changed my path variable in windows. That worked great but now I'm trying to deploy it and I don't really know how to do it.

Ideally I want a single .exe-file (it's for a school assignement).

Since SciLexer.dll and SciLexer64.dll are entirely native DLL's I can't reference them in visual studio like I normally would. Is there any way to embed these files within the exe?

Oct 2, 2012 at 5:32 PM

For .NET libraries it is pretty painless, most of the time, to use a tool called ilmerge to combine the managed assemblies in one .exe file.

When you are doing interop to a native library, as Scintella.NET is doing, the situation becomes more complex.  Most of the time, the .NET assemblies are compiled for any architecture (which generally means x86 and x64).  Therefore, the same .exe and .dll can run on x86 vs. x64 platforms.  Sometimes, a .NET assembly may need to be compiled to a specific platform - usually when interop is used (pointer sizes are of course different based on x86 or x64 but that is just the tip of the iceberg).

You will note that in Scintilla.cs, there is a line like this: "private static string _moduleName = (IntPtr.Size == 4 ? Resources.ModuleName : Resources.ModuleName64);" that causes LoadLibrary to call into the correct dll for your platform based on pointer size.

One thing you can do is to compile your app to be x86 only (if you want the most compatibility, or x64 if that is all you care about).  Now you only have ONE native library to redistribute - either SciLexer64.dll or SciLexer.dll based on how you compiled your managed app.  To get it down to zero, you now have to become an expert on Mixed Mode Assemblies, which allow the combination of native and managed code in a single assembly.  This is the technique used by the folks at Sqlite which has its own issues, especially when you want to consume them from x86 or x64 code.  I am far from an expert on this, and can't offer much more advice on it.  Like I said, this solution will only work for you (one exe) if you only care about running the code for EITHER x86 or x64.

A few other threads in the discussions here discuss wrapping ScintillaNET in a NuGet package.  Sqlite has a NuGet package, and it can because of their use of mixed mode assemblies, but working around the x86 and x64 issues on deployment can be really difficult, especially if you want to use a single installer that works on both platforms.  HINT: Use the GAC, the runtime will pick the correct x86 or x64 assembly. 

The last thing you should concern yourself (in the real world, anyway) with is licensing.  If you are shipping this thing, how does the use of tools such as ilmerge impact your compliance with the license?  Some licenses do not allow you to recompile the code and include it without open sourcing your code (or, sometimes, you just need to open any mods you made to the library).  With Scintilla.NET you have TWO licenses - Scintilla AND ScintellaNET to consider.

Finally, I'm not so sure you need to worry too much about making it one exe in the first place.  As long as the two dlls are in the same directory as your exe, you do not need to change the system path when you release the app (which makes my whole discussion above moot, but I hope it is useful to someone here).



Oct 2, 2012 at 6:45 PM

Thank you for your answer. I see this is far more complex than I'd thought. For now I'll settle with having the .dll-files in the same directory as the exe.

Oct 2, 2012 at 7:15 PM

StevenBone all your points are spot on. VadimSkpin did create a mixed mode assembly.

At the time I tried it out. It took some tinkering but eventually I got it to compile. The MMA worked perfectly. The huge downside to this approach is that you have to compile the Scintilla source. The version of Scintilla bundled with the MMA project is now horribly outdated. Merging in new changes from Scintilla is a major pain, especially when significant changes occur. It's a completely different project type/build system than what the Scintilla contributors maintain.