Announcement

Collapse
No announcement yet.

BUG: HS3 restore doesnt reset hard coded Scripting References

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • BUG: HS3 restore doesnt reset hard coded Scripting References

    rjh - another huge fail here...

    ScriptingReferences=System.Data.SQLite;C:\Program Files (x86)\HomeSeer HS3\Bin\System.Data.SQLite.dll;System.Web.Script.Serializati on;C:\Program Files (x86)\HomeSeer HS3\Bin\System.Web.Extensions.dll

    I changed my HS3 install path and your restore doesnt remap them.

    And, yup you guessed it... no startup log errors. you only know about this when HS3 runs a script and it doesnt work and then you check the logs.

    RJH: Why bother to have a Backup/Restore function if all it is doing is Zipping up the files and there is zero intelligence behind it? If you going to have a mostly useless function, at least document all the pitfalls of using it and the things people need to change manually for it to actually work when changing the install path.

  • #2
    Originally posted by Ltek View Post
    rjh - another huge fail here...

    ScriptingReferences=System.Data.SQLite;C:\Program Files (x86)\HomeSeer HS3\Bin\System.Data.SQLite.dll;System.Web.Script.Serializati on;C:\Program Files (x86)\HomeSeer HS3\Bin\System.Web.Extensions.dll

    I changed my HS3 install path and your restore doesnt remap them.

    And, yup you guessed it... no startup log errors. you only know about this when HS3 runs a script and it doesnt work and then you check the logs.

    RJH: Why bother to have a Backup/Restore function if all it is doing is Zipping up the files and there is zero intelligence behind it? If you going to have a mostly useless function, at least document all the pitfalls of using it and the things people need to change manually for it to actually work when changing the install path.
    Hardly a huge fail....why are you defining the full path? If it is within the Homeseer directory, you should be able to define your references as follows:

    Code:
    ScriptingReferences=System.Data.SQLite;Bin\System.Data.SQLite.dll;System.Web.Script.Serialization;Bin\System.Web.Extensions.dll
    Then your problem would not arise.

    Even if there is a bug with HS3 restore, I don't think reporting this in such an aggressive way is necessary or warranted.
    Jon

    Comment


    • #3
      Originally posted by jon00 View Post

      Hardly a huge fail....why are you defining the full path? If it is within the Homeseer directory, you should be able to define your references as follows:

      Code:
      ScriptingReferences=System.Data.SQLite;Bin\System.Data.SQLite.dll;System.Web.Script.Serialization;Bin\System.Web.Extensions.dll
      Then your problem would not arise.

      Even if there is a bug with HS3 restore, I don't think reporting this in such an aggressive way is necessary or warranted.
      Homeseer's install procedure is defining these paths (putting them in the settings.ini) -- the restore function built-in nor HS3 startup processes attempt to validate ANY of them to ensure they are valid -- which should be simple since HS3 should KNOW what path it installed to! Even I (and I'm a crappy coder) know how to check a file system to see if a file exists or a path exists. Its ONE command - one line of code to trap/surface the error.

      I have identified 3 bugs where HS3 doesnt validate paths that IT is hard-coding into the settings.

      All 3 bugs are caused by HS3 hard-coding paths (file or COM port) and not doing ANY error trapping on HS3 load to surface them in the 'startup log' or correct them during the native Restore process. Collectively, Huge Fail and clearly lazy programmers. Am I frustrated, yes - it has taken me several hours to identify and correct these manually and I'm a tech geek. Imagine the average PC user running into these issues.

      Comment


      • #4
        Originally posted by Ltek View Post

        Homeseer's install procedure is defining these paths (putting them in the settings.ini) -- the restore function built-in nor HS3 startup processes attempt to validate ANY of them to ensure they are valid -- which should be simple since HS3 should KNOW what path it installed to! Even I (and I'm a crappy coder) know how to check a file system to see if a file exists or a path exists. Its ONE command - one line of code to trap/surface the error.

        I have identified 3 bugs where HS3 doesnt validate paths that IT is hard-coding into the settings.

        All 3 bugs are caused by HS3 hard-coding paths (file or COM port) and not doing ANY error trapping on HS3 load to surface them in the 'startup log' or correct them during the native Restore process. Collectively, Huge Fail and clearly lazy programmers. Am I frustrated, yes - it has taken me several hours to identify and correct these manually and I'm a tech geek. Imagine the average PC user running into these issues.
        The average user would not be changing the HS install path so your point is invalid. This is all self inflicted! Calling Rich lazy is unkind and totally unwarranted.

        Clearly you need to attend some anger management classes. If you don't like Homeseer move on to something else.
        Jon

        Comment

        Working...
        X