I’m having trouble referencing certain .NET namespaces, such as a System.Collections.Concurrent and System.Text.RegularExpressions
when running Rhino 8 in .NET Framework mode. If I switch to .NET Core, the Concurrent namespace starts to work and Regex also (but directly since it behaves differently between the .NET versions).
A colleague of mine does not face this same problem, and the best explanation we could think of is that my colleague has Visual Studio installed and possibly .NET installation is a bit different from mine. I suspect that if I install it too, the problem gets solved. But that does not help the majority of users who are not developers.
So my question is, what are the directories from which the Script Editor looks for available assemblies? And why does switching from .NET Framework to .NET Core fix the problem?
So the main thing is: if I load Rhino in .NET Framework mode, both of these give errors suggesting they cannot find the required files/assemblies. If I run Rhino in .NET Core mode, everything works even without any additional #r statements.
Is this intended or should it just work out of the box?
Foremost, I really don‘t like the fact that you can run Rh8 in both modes, but I guess the decision is mainly based on the point to sell Rh8 with the full plugin spectrum. Basically if you migrate from Framework to Core, you are making all plugins obsolete. You are replacing the foundation of C#, this is a significant change.
Here is the problem, you should develop new tooling exclusively for Core, because this is the future. But of course this only works if you are free from old Net Framework dependencies.
Its not just about replacing the standard library in between, there are functional differences. You can‘t load a dll, and expect to have the same equivalent for the other framework. On some parts they have reworked quite a lot, putting it into different libraries etc.
To make it worse, a lot of the old framework functionality is not within the standard installation anymore.
Often you need to install additional (official) NuGet packages now. If your coworker has loaded another plugin which provides this additional content already, it could explain why he finds the namespaces, while you are lacking it. But hard to tell from here. If you begin the to load single dll‘s then you also need to ensure that they fit your active runtime. This problems grows exponentially if you load too many plugins.
Furthermore there are also these very short official support ranges from Microsoft nowadays.
By all the advantages of the C# ecosystem, but it’s becoming a pure mess atm. So McNeel is more a victim of this development, than the root of evil.
Its simply often the case that it’s impossible to know the right way of doing it.
These problems are more causing you to swim in uncharted terrain, and you need to have quite a decent understanding of the matter to solve them. Chicken-egg…
Therefore the only true solution is to keep it as simple as possible. Why do you need this namespace, which can‘t be solved by default concurrent features?
I agree, it would be best if we could run everything in Core. But due to the requirements of certain software like Tekla Structures and Revit (?) we have to use Framework in many cases. This also creates annoying problems like Lunchbox not running on Framework etc.
It is a good advice to restrict only to the most default libraries and namespaces. And in my specific case with concurrency, I resolved it by relying on PLINQ which allows parallel calculation while staying inside Linq namespace. Also the Parallel.For etc. would be a good option. But the main question remains: is there anything that can be done about this on McNeel’s side and specifically the Script Editor, since this stuff used to run just fine before. It’s like we are moving backwards regarding this, whereas the new Script Editor in general has allowed Python3 for example and more modern C#. And I really appreciate the effort that is being put to the new Script Editor and I hope it keeps getting better and better!
When it comes to Regex, the question is how should I run it on Framework? Do other people face this issue?
It is either: I have .NET installation done somewhat incorrectly or I’m lacking something, OR there is a bug/limitation with the Script Editor not locating the assemblies it should locate. I would like to get to the bottom of that so we can find a solution that takes us forward.
See this definition. I added these two NuGet references to your scripts:
#r "nuget: System.Text.RegularExpressions, 4.3.1"
using System.Text.RegularExpressions;
#r "nuget: System.Collections.Concurrent, 4.3.0"
using System.Collections.Concurrent;
Script editor pulls the correct package framework and installs on your machine (under ~/.nuget/packages) folder for each of these packages depending on dotnet framework that Rhino is running on.
This script should work on any rhino with no issues as long as it has internet access and can install packages. You can also preinstall these packages on target machines using the nuget command line tool.
I installed Visual Studio two days ago after which everything started to work as suspected. Must have something to do with DLL installations or something similar.
However, I contacted another colleague who does not have Visual Studio or any other IDE installed (so is basically running Rhino 8 the same as I used to do prior to installing VS). For him, the components look as follows:
So basically none of the different variations work. Nuget packages seem to install correctly.
Restarting Rhino does not help nor does opening the C# editor and pressing Play.
So the problems persists. If running Rhino in Framework mode, getting access to either RegularExpressions or Concurrent libraries don’t work.
Is there anything else I can test or deliver to help finding the root cause? I think this colleague is running Rhino 8.10 and I tested this same thing on 8.10 and 8.11 as well.
For some reason NuGet packages don’t seem to be installed. Would you mind running the definition in a fresh instance of rhino and let it show the errors, then run RhinoCodeLogs in Rhino command line and share the full logs. The window has a save menu item.
