Strongly-Named DLL / Signed DLL

[muneeebsheikh]

Hi devs,

I am working on a .Net Framework project which requires strongly-named assembly to be referenced.
Can you provide a DLL which has Strong Name property True?

[MarkPflug]

No, I won't be doing that, but you can certainly pull the source code and build a signed version if you need to.

[muneeebsheikh]

Yes I need to but pulling your library and creating my own version is not the best idea, as I discussed with my team.
But thanks anyways.

[bcalco]

@MarkPflug If I may ask, why won't you strong-sign the assemblies?

[bcalco]

I am on .NET Framework and building a tool that integrates with MS Office/365. I don't think the GAC is the issue per se, and frankly I don't know why I need it strong-named. I am getting errors at runtime that indicate it can't load Sylvan.Data.Csv for this reason. It's really a huge impertinence I wish I didn't have to deal with, but the Office API requires my assemblies be strong-named, and so I guess things I used must also be strong-named. However, I don't believe this to be the case of a large number of assemblies I use, so I am not sure now why I get this error message from VS and wish shit would just work, tbh.

[MarkPflug]

Are you using any other strong-named, third-party assemblies in this project?
I'm wondering if they are in the GAC?
How is the plugin registered with MS Office? I've never looked at that API. I'm wondering if in the registration process that MS Office might be registering them in the GAC so that it can load it by name, since it wouldn't otherwise know where to load the assembly from.

[bcalco]

What's strange is, some of it does work. It is quite difficult to explain fully the context of my problem, but essentially I am integrating a scripting engine that is able to reference and load and call into the assembly. But the minute I try to access a namespace in my own assembly that also loads the same DLL, then I get the error that it can't load Sylvan.Data.Cvs "or one of its dependents" because it's not strong-named, and kaboom. But elsewhere I am able to create an instance of CsvDataReader and CsvDataReaderOptions, no problem. The issue is, when setting the StringFactory to an the StringPool.GetString method, I need to do this in C# and not the scripting engine. So I created a helper in one of my strong-named DLLs and the minute I reference a namespace in it that refers to Sylvan, kaboom. I don't even know WTH "strong-naming" supposedly achieves (it seems so easy to dance around, except in Sylvan's case, where the voodoo that you do with testing seems to stretch the utility beyond its usefulness) but now I have this stupid devops issue getting in the way of an elegant wrapper of your library that I really want to use.

[bcalco]

@MarkPflug I am using so many assemblies that I can't believe all of them are strongly named. This problem seems only to appear when one of my strongly named assemblies tries to use anything in an assembly that isn't strongly named directly. Loading it in the runtime via the script engine is not a problem, but some of the syntax of assigning the StringFactory delegate property is a bit out of the ordinary use case for interop with the CLR and so I felt it would be easier just to create a static class in one of my core assemblies that I know is already loaded. everything is good until I try to use a namespace in that DLL that refers to Sylvan (I assume if I was directly accessing another not strongly named assembly, I'd get the same burp up). What I don't get is, why I can load it indirectly, but not directly. The whole scheme seems like more pain than gain, and like swiss cheese from a security point of view (assuming that's the motivation for it).

[bcalco]

I don't have time to figure out what it would take to strongly-name Sylvan because the whole "friend assembly" BS complicates compiling any of it at all. I made all the assemblies in the project use the same snk file, and added the public key to the InternalsVisibleTo in the AseemblyInfo.cs files of Sylvan.Data and Sylvan.Common project. Nothing compiles properly, tons of errors, warnings, whatnot. When I revert to life without pointing to the snk files, all compiles no problem. I am on the verge of having to settle for an inferior alternative, and what's kind of sad is, I can't even explain why I have this stupid requirement. As far as I am concerned, Sylvan does what I want, and all I want to do is use it.

[MarkPflug]

Loading it in the runtime via the script engine is not a problem

Can you show me an example of what that loading code looks like? That might help me understand what's causing the issue.

[bcalco]

It seems I spoke too fast - I am having problems setting the result of that call, which is a Func<char[],int,int,string>, to the value of CsvDataReaderOptions.StringFactory ... but it appears to be a language issue. From your POV, that should be compatible with the StringFactory delegate type, right?

[MarkPflug]

You might try this...
If all you are using from Sylvan.Common is the string pool type, just copy that code into your project and reference it from there. The beauty of open source. It really isn't that much code, and you shouldn't ever have to mess with it.

[MarkPflug]

This is the file:
https://github.com/MarkPflug/Sylvan/blob/main/source/Sylvan.Common/StringPool.cs
Not even 200 lines of code, entirely self-contained, you can just drop that file into your project with no changes.

[bcalco]

I may have to go that route while the script language issue(s) get worked out for this. Ben.StringIntern is strong-name signed so I can also use that more directly. Looks like I just need to create some C# wrapper classes with simpler interfaces around the assignment of the StringFactory property.

[bcalco]

@MarkPflug Just to give you a quick update - I was able to resolve my actual issue at the script language level, dealing with the assignment of delegate types. However, the strong-name signing problem I ran into by attempted to do that assignment in C# appears to be solvable by loading unsigned assemblies indirectly through the scripting engine, and avoiding direct use by my strong-name signed assemblies. I don't know why that works, but it does. That is, I was able to write a C# DLL, not strong-name signed, that my strong-name signed project referred to but did not actually use (the purpose being to make sure it is copied to the target directory). Loading that DLL from the script side allows me to refer to types in Sylvan (which it uses directly) no problem. But it turned out being able to assign lambdas directly to the delegate property in my script language meant I didn't have to set the stringfactory property in a C# wrapper. But when / if I ever need to, now I know how to avoid the problem I ran into here, and I even have a placeholder for it.