Announcement

Collapse
No announcement yet.

PluginSdk.dll

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

    PluginSdk.dll

    I built the sample plugin but it would not initialize until I put the PluginSdk.dll in the HS4 root folder

    Should we be using the Bin/PluginName folder for the PluginSdk.dll file because each plugin could be using a different build of the plugin SDK

    This one could be a pain if you have many plugins like myself - I would want to use the same PluginSdk.dll throughout all of my plugins
    I notice there is a PluginSdk.dll in the Bin/homeseer folder. Can HS4 default to that folder if it cannot find it in the Bin/pluginname folder

    Thoughts?
    Cheers,
    Bob
    Web site | Help Desk | Feature Requests | Message Board

    #2
    There is a corresponding app.config (HSPI_HomeSeerSamplePlugin.exe.config) that is included with the plugin that handles assembly binding and redirecting the MSBuild probing to the correct directories. This should be placed in the same directory as the exe and points to the bin\homeseer\PluginSDK.dll file.

    Comment


      #3
      Could HS4 default to the Bin/homeseer folder in order to use the one in there if we do not specify one.
      It looks like it defaults to the HS4 root folder which could mess up other plugins relying on it to be in the Bin/plugin folder

      Cheers,
      Bob
      Web site | Help Desk | Feature Requests | Message Board

      Comment


        #4
        The pluginsdk.dll file should only be in the bin/homeseer folder. I am probably going to add some checking at startup and delete any dll files that don't belong there, JIC some plugin copies it there. But we will be reviewing plugins submitted through the portal to make sure their install.txt file is ok. However, there is the possibility that someone could install a free plugin outside the updater so a check is probably worth it.

        Originally posted by Blade View Post
        Could HS4 default to the Bin/homeseer folder in order to use the one in there if we do not specify one.
        It looks like it defaults to the HS4 root folder which could mess up other plugins relying on it to be in the Bin/plugin folder
        💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

        Comment


          #5
          I have started a page in the documentation on this subject

          https://docs.homeseer.com/display/HS...ncy+Management

          Comment


            #6
            Originally posted by rjh View Post
            The pluginsdk.dll file should only be in the bin/homeseer folder. I am probably going to add some checking at startup and delete any dll files that don't belong there, JIC some plugin copies it there. But we will be reviewing plugins submitted through the portal to make sure their install.txt file is ok. However, there is the possibility that someone could install a free plugin outside the updater so a check is probably worth it.


            Does this mean you have no intention of updating the sdk post initial release? Limiting all the plugins to the same version of a DLL means you can't update it without potentially breaking other plugins that depend on a specific version.

            Comment


              #7
              Originally posted by sirmeili View Post

              Does this mean you have no intention of updating the sdk post initial release? Limiting all the plugins to the same version of a DLL means you can't update it without potentially breaking other plugins that depend on a specific version.
              The Plugin SDK will continue to be developed along-side the HomeSeer platform. There will be cut-off points when we shift to higher major versions for both the core platform and the SDK, at these points, if a plugin has not been updated to use the newer version, it will not work.

              Comment


                #8
                Originally posted by JLDubz View Post

                The Plugin SDK will continue to be developed along-side the HomeSeer platform. There will be cut-off points when we shift to higher major versions for both the core platform and the SDK, at these points, if a plugin has not been updated to use the newer version, it will not work.
                You need to find a better solution or I think you're gonna dig yourselves into a deep whole which could upset not only your developer community, but also your user base as an update could break vital functionality for them.

                At the very least, you NEED to allow the core product to work with multiple versions of the SDK. You NEED to allow each plugin to access it's own version of the SDK.dll. Finally you NEED to not break stuff form your partners (plugin developers) who do not do this full time and can't always make dll changes fast to plugins.

                The above is only my opinion. Others can correct me if they feel I'm wrong about the above.

                Comment


                  #9
                  Originally posted by sirmeili View Post

                  Does this mean you have no intention of updating the sdk post initial release? Limiting all the plugins to the same version of a DLL means you can't update it without potentially breaking other plugins that depend on a specific version.
                  In HS3 all plugins were limited to the same version of HomeSeerAPI.dll and Scheduler.dll, and I don't think it was a major source of problems, was it?
                  In HS4 those dependencies have been replaced by a single one on PluginSdk.dll, so I don't see why it would cause more troubles than it did in HS3.

                  Comment


                    #10
                    Originally posted by spud View Post

                    In HS3 all plugins were limited to the same version of HomeSeerAPI.dll and Scheduler.dll, and I don't think it was a major source of problems, was it?
                    In HS4 those dependencies have been replaced by a single one on PluginSdk.dll, so I don't see why it would cause more troubles than it did in HS3.
                    That might be true spud. What concerned me was "There will be cut-off points when we shift to higher major versions for both the core platform and the SDK, at these points, if a plugin has not been updated to use the newer version, it will not work."

                    Comment


                      #11
                      Originally posted by sirmeili View Post

                      That might be true spud. What concerned me was "There will be cut-off points when we shift to higher major versions for both the core platform and the SDK, at these points, if a plugin has not been updated to use the newer version, it will not work."
                      I apologize for being vague when it comes to "these cut-off points." It is the most accurate statement I can give you. It is not unheard of for an application to stop supporting some legacy versions at some point along its continued development; when the plumbing between plugins and the core system has to undergo a significant change to, say, fix a major security issue, at some point, the older, bugged version will have to be deprecated. Striking a balance between when to do that and how long to continue supporting legacy versions is something we will have to work with the plugin developer community to figure out; which isn't something we can determine right now. It's tough to appease everyone in the community and do something that works for absolutely everyone's schedules. We will be able to identify what this release and update schedule will look like as we continue to work together through the Alpha phase and moving forward.

                      I'm sorry I cannot be more specific. I do understand and hear your concerns.

                      Comment


                        #12
                        Originally posted by JLDubz View Post
                        The Plugin SDK will continue to be developed along-side the HomeSeer platform. There will be cut-off points when we shift to higher major versions for both the core platform and the SDK, at these points, if a plugin has not been updated to use the newer version, it will not work.
                        This would be really really really bad. If HS would rollout a newer version with a breaking change, the plugin developer is forced to update. If he doesn't, the plugin is broken. If he does, people on an older HS version that would update have a broken plugin with no way to downgrade.

                        Please revise this decision. You SDK needs be backwards compatible at all times

                        Comment


                          #13
                          Originally posted by kriz83 View Post

                          This would be really really really bad. If HS would rollout a newer version with a breaking change, the plugin developer is forced to update. If he doesn't, the plugin is broken. If he does, people on an older HS version that would update have a broken plugin with no way to downgrade.

                          Please revise this decision. You SDK needs be backwards compatible at all times
                          This may have been my miscommunication, but there is no intent to update and immediately break plugins. If such a change is to be rolled out, it will be added to a prior release with notes that the older methodology will be deprecated after X time. (let's say a month or two right now) At that point, yes, the plugin will not work until it is updated. If a plugin developer is not maintaining their popular plugin and updating it after said time when an announcement from HomeSeer was sent out about it, then I'm not sure I understand why HomeSeer should continue to support legacy code for it. Help me understand this if I am missing something, please.

                          I am speaking about critical changes that affect the fundamental communication between plugins and HS4, nothing more. You can most certainly specify your own versions for assemblies by changing the probing patterns of your plugin. See https://docs.homeseer.com/display/HS...ncy+Management

                          Comment


                            #14
                            Originally posted by JLDubz View Post
                            I'm not sure I understand why HomeSeer should continue to support legacy code for it. Help me understand this if I am missing something, please.
                            Because it takes developers time to support the changes - for virtually no return. Unless you are willing to pay the developers for providing support?

                            Comment


                              #15
                              Originally posted by JLDubz View Post

                              This may have been my miscommunication, but there is no intent to update and immediately break plugins. If such a change is to be rolled out, it will be added to a prior release with notes that the older methodology will be deprecated after X time. (let's say a month or two right now) At that point, yes, the plugin will not work until it is updated. If a plugin developer is not maintaining their popular plugin and updating it after said time when an announcement from HomeSeer was sent out about it, then I'm not sure I understand why HomeSeer should continue to support legacy code for it. Help me understand this if I am missing something, please.

                              I am speaking about critical changes that affect the fundamental communication between plugins and HS4, nothing more. You can most certainly specify your own versions for assemblies by changing the probing patterns of your plugin. See https://docs.homeseer.com/display/HS...ncy+Management
                              The only things you should break are things that are already potentially broken and being taken advantage of. I.E. I've had to code around a but, but you fixing that bug might break my plugin. That I can completely understand. but if all plugins are working around it, you still have to consider if it's worth fixing or the best way to handle it and communicate it. Changing to a more efficient method of handling something should either be transparent to the plugin or have a LOT of lead time with the old method deprecated. I'm talking a year, not 1-2 months.

                              1-2 months I don't think is enough time to require plugin devs to change. We have lives. This is not our full time job. I've been on a project that has killed any of my free time for 6 months (60-80hr work weeks). Even if I have a popular plugin, it doesn't mean I can fix the issue ASAP.

                              You asked about optimal developer relationship in another thread, and I'll leave this here: When thinking of changes that affect plugins and ultimately us Devs, put yourself in the developers shoes. You may put in at least 40 hrs a week working on HS, but many of may only put that much into maintaining a plugin over the course of months, not days.

                              Comment

                              Working...
                              X