THIS
.
I’m only surprised this issue is not more widespread across this site, stack overflow, etc because it relates to making a .dll for the Unity Editor, perhaps as opposed to making a Unity build that uses .NET 4x at runtime with raw C#. (and, if the internet is any indication, these .NET 3.5 / .NET 4.x issues with editor vs runtime have been going on for three of four years now)
.
Out of the box, with Visual Studio (2017), Unity 2017,18,19+ have been providing .NET 4 from VS, not 3.5 or less.
.
Which means, out of the box, C# Unity code cannot make a dll for the editor. While one may use the player setting to allow their project to use .NET 4.x at runtime, the editor uses 3.5.
.
This was less of a problem until very recently (a cascade of Unity updates in the last two weeks), when suddenly older dll .NET 3.5 (or probably less) references made with a much older version of Unity that came with MonoDevelop could not link properly with the editor.
.
The main question is: Why on earth would the Unity editor use a .NET version that is not supported out-of-the-box by using the provided code editor, Visual Studio? (Is it that a dll is never expected to be made by Visual Studio for the Unity editor? And how can this recent assembly reference breakage not break every dll asset on the Asset Store?) oof.
.
Let’s hope this does raise heck, and prompt the included .NET assembly references for Visual Studio to actually be compatible with the Unity editor, so we can actually build a dll that works for the editor.
.
It would be a let down if what is expected is for all dll developers to chase down compatibility issues based on changes to frequent Unity updates, while not supplying them with the necessary dll build assembly references. :\
.
Unity 2019.4.4f1 (now just popping up there’s another new version, that’s four in as many weeks)
VS Community 2017 v.15.9.24
.
my $0.02