VB.NET scripts are interpreted by the Microsoft .NET runtime environment installed on the computer under the control of, and with extensions added by, HomeSeer.  When a VB.NET script is executed, it is first compiled into .NET runtime code.  Once this is done, the script is loaded by the runtime and CAN NOT be unloaded from the runtime memory pool.

HomeSeer 2 Build 1984 addresses this runtime limitation by tracking the compiled version of all VB.NET scripts for re-use, thus eliminating the need to recompile the same script repeatedly.  HomeSeer 2 cannot, however, unload or replace the memory used by a compiled script with a new version when the script is modified.  Thus, continuous editing and testing (compiling) of VB.NET scripts, or the execution of many different VB.NET scripts will result in potentially large amounts of system memory being consumed which cannot be restored without restarting HomeSeer.  While the exact number of compilations or different scripts being run necessary to impact the system varies with each installation, HomeSeer Technologies believes the number to be sufficiently high enough that most users will be unaffected by this situation.

If you use VB.NET scripts in your HomeSeer 2.0 installation, please keep these usage suggestions in mind:

• After making changes and testing your VB.NET scripts repeatedly, shut down and restart HomeSeer 2.0 if possible.
• If you are a script author, refrain from writing scripts that modify other VB.NET scripts such as to include data from an INI configuration file.  HomeSeer provides script commands to directly read data from INI files so that the code in VB.NET scripts does not need to be modified.  Modification of scripts by external programs or scripts will result in the script needing to be recompiled.
• If you are a script author, avoid breaking scripts up into several separate script files containing different pieces of functionality and instead consider a single monolithic script file with many subs and functions to fulfill the needs of the script system being written.  Although the overhead for each script is not that great, every little bit may help an end user's system if they are low on RAM resources.