tenScripting 3.36 Now Available

[tenholde]

Bug fixes and additional error checking.

Please view this video describing new Realtime Debugging feature: http://tenholder.net/tenWare2/tenScr...timeDebug.aspx

[mterry63]

tenholde, in the case of tenscripting3 being remote to the HS3 computer, how is user context managed? I was having problems writing to a file when debugging in tenscripting3, and I realized after adding System.Security.Principal.WindowsIdentity.GetCurrent().Name that the script is executing in my remote user context (the user running Visual Studio), not as a user of the HS3 windows machine.

I guess it wasn't reasonable to assume I was running under some HS3 local machine context, but I'm surprised that HS3 allows me to run code under a basically "unknown" user context.

Maybe I just don't understand how this works?

[tenholde]

All HS plugins are run as if they were remote, as separate .exes and their own contexts. All communications between HS and a plugin is via remoteing using the HSCF product to perform the remoting. HS/HSCF allows a plugin to create remote copies of the critical HS objects. The plugin is actually accessing a proxy created by HSCF that communicates via TCP to HS to provide for property changes and method execution, etc. The plugin accesses the HS objects like if they were local objects, but they are actually dealing with the proxies.

tenScripting is just another HS plugin and accesses all HS capabilites (and hence your scripts are doing the same when run by tenScripting) this same way. Any .net functions that you call in your script will be dealing with the local context (that is, your HS computer when run under HS and your tenScripting computer when run under tenScripting.

[mterry63]

Thanks for the explanation. I suppose as long as the script doesn't interact with anything in the remote system that involves Security ACLs the difference will never come up. In this case a StreamWriter object couldn't open a file under the HomeSeer directory when running the script under the tenScripting environment. A workaround is to make sure my user context on my development computer has access to the HomeSeer file system. Under a workgroup and involving Microsoft accounts, that is a challenge.

I appreciate all the work you've put into this system, I find Visual Studio much better than working in a text editor.

[tenholde]

Thanks for the explanation. I suppose as long as the script doesn't interact with anything in the remote system that involves Security ACLs the difference will never come up. In this case a StreamWriter object couldn't open a file under the HomeSeer directory when running the script under the tenScripting environment.

If you are running the script in tenScripting on computer A, then the file you are trying to open must also be on computer A, or you need to reference it via a network share. If you are doing extensive testing of a script this way, there are two options. (1) make a local copy of the files you are referencing in an identical folder structure so you can reference the local file exactly the same way on both computers or (2) create a network share to the file on the HS computer and reference it. You can make it so that you can export it from your local computer to the HS computer without making any changes by doing something like:

filePath = "c:\myFile.txt"
filePath = "\\HsComputer\c\myfile.txt"      '@DONOTEXPORT
fileContents = My.Computer.FileSystem.ReadAllText(filePath)

When you run this code under tenscripting, filePath will reference the file through the Share.

When you export this code, the second filePath= statement will be removed, so the script will reference the file via the local path.

Hope this helps.

[mterry63]

Ah, I missed this distinction, that file references are the local machine. In that case I can code around the differences as you suggested.

Thanks again for your generous gift of time!


Sent from my Pixel 2 using Tapatalk