What has changed lately when my script components no longer throws exceptions. The only response I get is the following message in the Command Window on the Rhino side, but component is not being marked red.
Exception System.NotSupportedException:
Message: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See <loadFromRemoteSources> Element | Microsoft Learn for more information.
Despite the link to more information, I still don’t get it how to enable the “loadFromRemoteSources”.
Perhaps this is the good news, Microsoft no longer supports exceptions. Exception are dead?
Cache Problems
BTW, there are more problems with the ScriptComponents; At one point an earlier Component.Message got “stuck” in the code, even if I removed the string assignment from the code altogether it still showed up, and obviously, the component ran older code than that which was visible in the editor. Only after a restart of Rhino the ghost code disapeared. Probably a cache problem.
Port Name Problems
Similar problem (cache) when modifying Inport or outport (Param) names. One has to add an extra new port, and then remove the extra inport (or outport), to get a new name to stick (to be compiled into the main signature), otherwise the default name remains (the x, y, z defaults, etc).
This last misbehaviour can be dealt with with a consistent workaround. Cached code giving strange execution results OTOH can be trickier to identify before wasting half a day on non existant bugs that are actual bugs, at least in runtime (old replaced cached code still in effect…).
Once loaded an assembly cannot be unloaded, and a script that is replaced by another script will still remain active. If it has no ties with the rest of the program it will eventually get garbage collected, but if it’s responding to events, yeah it’ll stay alive and running until the entire appdomain is unloaded, i.e. a Rhino restart.
I do run into this issue sometimes when writing scripts myself, basically there’s no mechanism in the SDK for telling a compiled script “hey you’re about to be replaced by a newer version, clean yourself up”. So you get these ghost assemblies interfering.
I did add RH-46167, it will probably help with detecting these cases.
Based on your image there are no custom references to the script. The left panel is empty. So presumably one of the regular references is now giving problems. Which would mean you should also see that problem if you create a brand new script which does something trivial. Is that the case?
So then there must be some “non-usual” assembly reference in the code that fails to throw the exception in the component attached. Do you get any exception? (it should, as long as the wire is not connected to the Num at the far right)
Nope, it’s fine both with and without. Nothing in the Rhino command line, nothing in the runtime message menu.
This however, is a bug: if (m_current_result == double.NaN)
NaN are equal to nothing, not even themselves. You must use double.IsNaN(m_current_result) to test for nanity. Fun fact, the IsNaN method actually uses the equality comparer and returns true if the value isn’t equal to itself.
After fixing this, it still doesn’t manage to display the error (which it actually catched earlier too, not oonly now), with the following message to the Rhino command line
Exception System.NotSupportedException:
Message: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See <loadFromRemoteSources> Element | Microsoft Learn for more information.
