Script Errors After Restart

[david.i.tanzer@gmail.com]

When my scripts execute for the first time I seem to get errors similar to this:

Compiling script (3)Sleep.cs: {interactive}(26,20): error CS0433: The imported type `System.Threading.Thread' is defined multiple times {interactive}(8,17): warning CS0414: The private field `Script.hs' is assigned but its value is never used {interactive}(9,36): warning CS0414: The private field `Script.hs4' is assigned but its value is never used

Is there a reason for this? Once this occurs, it seems to subsequently execute without issue. And I don't reference Script.hs or Script.hs4 in my code.

[tenholde]

Linux or Windows. How are you starting HS4? Manually or autostart when booted or login?

[david.i.tanzer@gmail.com]

Linux: HS4 ZEE S2/PI Edition 4.2.7.0. And this occurred after a normal restart from HS4.

[mrslother]

Short answer: The problem is not correctable by us (scripters).
Longer answer:
It cannot be corrected from the scripting layer. It is correctable, however, by the HomeSeer team. They can enable the scripting engine's //css_co reference so that we can route specific classes to specific assemblies.

I see the same error when I script using the System.Net.Sockets.TcpClient class. This specific problem is that the scripting engine has loaded multiple assemblies which export the same namespace/type: System.Net.Sockets.TcpClient. The error is telling you that the scripting engine does not know which assembly to route the requested object.

You would normally mitigate this by registering alias namespaces and mapping them using "extern alias". But HomeSeer does not enable the registering of these aliases in the namespace engine (normally done by adding a //css_co reference to the top of your script file). Too bad HS doesn't allow this.

You may want to check for multiple installations of System.Threading.Thread assembly. There is probably one registered in the GAC (as part of the .net framework) and another one somewhere else. I found that the ZWave Parameter plugin appears to be a .Net Core app with its own assemblies in the bin\ZWaveParameter directory. There is a System.Threading.Thread.dll file in that directory. If HS is loading that then that could help explain at least one of the multiple definitions.
You can use a tool like Process Explorer (https://docs.microsoft.com/en-us/sys...ocess-explorer) to see what DLL files are loaded into the HS process space. That may help identify where your multiple thread.dll files are coming from.

Background:
HomeSeer enables C# scripting through a scripting engine (I think they use Oleg Shilo's CS-Script engine v3.7.2.0 (circa 2013)).

https://www.csscript.net
https://github.com/oleg-shilo/cs-script
https://github.com/oleg-shilo/cs-scr...lease_notes.md

HomeSeer's C# support is really, really bad. The engine appears to be really old and desperately out of date. This is why some obvious and important c# constructs are not supported. This engine is so outdated that the Oleg Shilo CS-Script engine GitHub repo does not even have a record of this version. And some common C# capabilities are not respected (such as the auto-disposing "using" statement);

using( var myFoo = new SomeDIsposableObject())
{
    // do stuff here...
}

Does not work. Wow. I am not even sure async/await patterns work.

My big ask of the HomeSeer team is that they update their c# scripting engine. Please!
And enable the engine's reference capabilities:

//css_reference <assembly file path>
//css_include <c# file path>
//css_co /r:foo=c:\myAssembly.dll

I had to write my own proxy code to do this so that I could load other CS files as well as load assemblies. The HomeSeer online docs infer that they have enabled such reference abilities but my testing demonstrates otherwise.

HomeSeer enables loading of assemblies for VB scripts (using the config.ini's ScriptingReferences property), just not for C#.

[tenholde]

Short answer: The problem is not correctable by us (scripters).
Longer answer:
It cannot be corrected from the scripting layer. It is correctable, however, by the HomeSeer team. They can enable the scripting engine's //css_co reference so that we can route specific classes to specific assemblies.

I see the same error when I script using the System.Net.Sockets.TcpClient class. This specific problem is that the scripting engine has loaded multiple assemblies which export the same namespace/type: System.Net.Sockets.TcpClient. The error is telling you that the scripting engine does not know which assembly to route the requested object.

You would normally mitigate this by registering alias namespaces and mapping them using "extern alias". But HomeSeer does not enable the registering of these aliases in the namespace engine (normally done by adding a //css_co reference to the top of your script file). Too bad HS doesn't allow this.

You may want to check for multiple installations of System.Threading.Thread assembly. There is probably one registered in the GAC (as part of the .net framework) and another one somewhere else. I found that the ZWave Parameter plugin appears to be a .Net Core app with its own assemblies in the bin\ZWaveParameter directory. There is a System.Threading.Thread.dll file in that directory. If HS is loading that then that could help explain at least one of the multiple definitions.
You can use a tool like Process Explorer (https://docs.microsoft.com/en-us/sys...ocess-explorer) to see what DLL files are loaded into the HS process space. That may help identify where your multiple thread.dll files are coming from.

Background:
HomeSeer enables C# scripting through a scripting engine (I think they use Oleg Shilo's CS-Script engine v3.7.2.0 (circa 2013)).

https://www.csscript.net
https://github.com/oleg-shilo/cs-script
https://github.com/oleg-shilo/cs-scr...lease_notes.md

HomeSeer's C# support is really, really bad. The engine appears to be really old and desperately out of date. This is why some obvious and important c# constructs are not supported. This engine is so outdated that the Oleg Shilo CS-Script engine GitHub repo does not even have a record of this version. And some common C# capabilities are not respected (such as the auto-disposing "using" statement);

using( var myFoo = new SomeDIsposableObject())
{
// do stuff here...
}

Does not work. Wow. I am not even sure async/await patterns work.

My big ask of the HomeSeer team is that they update their c# scripting engine. Please!
And enable the engine's reference capabilities:

//css_reference <assembly file path>
//css_include <c# file path>
//css_co /r:foo=c:\myAssembly.dll

I had to write my own proxy code to do this so that I could load other CS files as well as load assemblies. The HomeSeer online docs infer that they have enabled such reference abilities but my testing demonstrates otherwise.

HomeSeer enables loading of assemblies for VB scripts (using the config.ini's ScriptingReferences property), just not for C#.

While I agree with your request of HS, I'm not sure that is the OP problem as it fails first execution after startup, but then works fine.

[Guest]

I had a similar problem with HS3 and VB script files that had "Include" statements in them. So I wrote a short script file that updates the file "update date" in the various script files, which forces a recompile. I then run that script immediately on HS restart. (Of course that script file does not have in include in it!)

[jon00]

My big ask of the HomeSeer team is that they update their c# scripting engine. Please!
And enable the engine's reference capabilities:

//css_reference <assembly file path>
//css_include <c# file path>
//css_co /r:foo=c:\myAssembly.dll

I had to write my own proxy code to do this so that I could load other CS files as well as load assemblies. The HomeSeer online docs infer that they have enabled such reference abilities but my testing demonstrates otherwise.

HomeSeer enables loading of assemblies for VB scripts (using the config.ini's ScriptingReferences property), just not for C#.

According to the docs //css_reference <assembly file path> is supported:



Whether it works or not is a different matter!

[mstukel]

//css_reference <assembly file path>
//css_include <c# file path>
//css_co /r:foo=c:\myAssembly.dll

I had to write my own proxy code to do this so that I could load other CS files as well as load assemblies. The HomeSeer online docs infer that they have enabled such reference abilities but my testing demonstrates otherwise.

HomeSeer enables loading of assemblies for VB scripts (using the config.ini's ScriptingReferences property), just not for C#.

Thank you for posting this. I found this write-up very helpful. I have struggled with c# scripting when it comes to referencing external assemblies. Would you mind sharing the approach you used in your proxy code in order to leverage other CS files?
Thanks again!

[david.i.tanzer@gmail.com]

I had a similar problem with HS3 and VB script files that had "Include" statements in them. So I wrote a short script file that updates the file "update date" in the various script files, which forces a recompile. I then run that script immediately on HS restart. (Of course that script file does not have in include in it!)

aa6vh, could you post this code? That would be very much appreciated!

[Guest]

aa6vh, could you post this code? That would be very much appreciated!

I will post it later today when I get near my Homeseer computer.

[Guest]

aa6vh, could you post this code? That would be very much appreciated!

Here you go. You will need to make two changes, first to the path variable to match the path to your script files on your server, and then to the file name variable array that contains the file names of the scripts that have the "include" statement in them.

Imports System.IO
Private Function OpenFileOut(ByVal fileName As String) As FileStream
  Dim sw As FileStream = Nothing, errMsg As String
  Try
    sw = New FileStream(fileName, FileMode.Open, FileAccess.Write, FileShare.Write)
  Catch ex As Exception
    errMsg = ex.Message.ToString
    hs.WriteLog("error", "OpenWrite: " + errMsg)
    sw = Nothing
  End Try
  Return sw
End Function
Sub Main(parms As Object)
  Dim fn() As String = {"Virtual.vb", "Alarm.vb", "Alert.vb", "Extra.vb", _
     "Weather.vb"}
  Dim filePath As String = "C:\Homeseer HS3\scripts\"
  Dim sw As FileStream, I As Integer = 0
  Do While I < fn.Length
    sw = OpenFileOut(filePath + fn(I))
    If sw IsNot Nothing Then
      sw.Close()
      sw.Dispose()
    End If
    I = I + 1
  Loop
End Sub

[david.i.tanzer@gmail.com]

Thanks, aa6vh!

[tenholde]

Short answer: The problem is not correctable by us (scripters).
Longer answer:
It cannot be corrected from the scripting layer. It is correctable, however, by the HomeSeer team. They can enable the scripting engine's //css_co reference so that we can route specific classes to specific assemblies.

I see the same error when I script using the System.Net.Sockets.TcpClient class. This specific problem is that the scripting engine has loaded multiple assemblies which export the same namespace/type: System.Net.Sockets.TcpClient. The error is telling you that the scripting engine does not know which assembly to route the requested object.

You would normally mitigate this by registering alias namespaces and mapping them using "extern alias". But HomeSeer does not enable the registering of these aliases in the namespace engine (normally done by adding a //css_co reference to the top of your script file). Too bad HS doesn't allow this.

You may want to check for multiple installations of System.Threading.Thread assembly. There is probably one registered in the GAC (as part of the .net framework) and another one somewhere else. I found that the ZWave Parameter plugin appears to be a .Net Core app with its own assemblies in the bin\ZWaveParameter directory. There is a System.Threading.Thread.dll file in that directory. If HS is loading that then that could help explain at least one of the multiple definitions.
You can use a tool like Process Explorer (https://docs.microsoft.com/en-us/sys...ocess-explorer) to see what DLL files are loaded into the HS process space. That may help identify where your multiple thread.dll files are coming from.

Background:
HomeSeer enables C# scripting through a scripting engine (I think they use Oleg Shilo's CS-Script engine v3.7.2.0 (circa 2013)).

https://www.csscript.net
https://github.com/oleg-shilo/cs-script
https://github.com/oleg-shilo/cs-scr...lease_notes.md

HomeSeer's C# support is really, really bad. The engine appears to be really old and desperately out of date. This is why some obvious and important c# constructs are not supported. This engine is so outdated that the Oleg Shilo CS-Script engine GitHub repo does not even have a record of this version. And some common C# capabilities are not respected (such as the auto-disposing "using" statement);

using( var myFoo = new SomeDIsposableObject())
{
// do stuff here...
}

Does not work. Wow. I am not even sure async/await patterns work.

My big ask of the HomeSeer team is that they update their c# scripting engine. Please!
And enable the engine's reference capabilities:

//css_reference <assembly file path>
//css_include <c# file path>
//css_co /r:foo=c:\myAssembly.dll

I had to write my own proxy code to do this so that I could load other CS files as well as load assemblies. The HomeSeer online docs infer that they have enabled such reference abilities but my testing demonstrates otherwise.

HomeSeer enables loading of assemblies for VB scripts (using the config.ini's ScriptingReferences property), just not for C#.

I've left you a private message

[mrslother]

According to the docs //css_reference <assembly file path> is supported:



Whether it works or not is a different matter!

Unfortunately the docs are incorrect. Whether it works or not is a different matter is the money shot!

The //css_xxxxx directives are indeed supported by the Mono compiler HS uses but HS compiles your script using an auto-class-generation function. It generates a "Script" class where your code is embedded. This is why it fails if you try to define a namespace in your script code.

By compiling this way it, unfortunately, does not render the //css_xxxxx directives. Whomever wrote the docs were not writing the code (maybe they just read the CScript compiler docs and made assumptions). It certainly feels like it wasn't tested.

This is why directives don't work:
//css_include
//css_import
//css_reference
//css_co
... and a bunch others...