6 Replies Latest reply on Nov 9, 2010 8:30 PM by MichaelvdV@Atos

    Using instances in an AFPlugin assembly in a client application

    MichaelvdV@Atos

      Please consider the following situation:

       

      We have a custom DataReference in Assembly 'A'. The custom DataReference uses a static caching mechanism in a static class ('A'.Cache). Assembly 'A' is registered with AF using RegPlugin. Next, we have a Scheduler application in Assembly 'B'. 'B' uses AFSDK to get values from the DataReference in 'A'. Calls are abstracted by AFSDK, so there is no direct knowledge or reference of Assembly 'A'.

       

      Now, we need to access the Cache from Assembly 'A'. This is a static class.

       

      Question:

       

      How can I access the same 'A'.Cache in both the Scheduler application ('B'), as in the DataReference ('A')?

       

      Considered Solution: 

       

      My first thought would be to reference 'A' in 'B', since it will be loaded into 'B' at runtime by AF. Then, I could access 'A'.Cache.

       

      This isn't working. There is a new static reference to 'A'.Cache, not the one that has been accessed by the datareferences in 'A'.

       

      My thoughts are that 'A' is loaded into another appdomain then the current appdomain by AFSDK.

        • Re: Using instances in an AFPlugin assembly in a client application
          cmanhard

          The simplest solution would be to stick the Data Reference in the GAC on the scheduler machine.  Then both AF and your application would load the same one.  Will that work for you?

            • Re: Using instances in an AFPlugin assembly in a client application
              MichaelvdV@Atos

              I have thought about that, but I assumed that the mechanics of loading plugins by AF would prevent this.

               

              Can you tell me a bit more about these mechanics? I either have 2 things in mind.

               

              1) When a datareference is called, AFSDK uses WCF to get the bits of the plugin assembly, and AFSDK calls Assembly.Load (or using AssemblyPart). It could also be that the Assembly is loaded into a seperate Appdomain? Every 'session', the assembly is loaded from AF (if it is

               

              2) When a datareference is called, AFSDK uses WCF to get the bits of the plugin assembly, writes it to disk, and uses Assembly.LoadFrom. It checks for updates, and get the update when it gets available. So, the assembly is basically 'cached' locally.

               

              Am I in the right direction?

               

              Thank you for your answer, if this is the solution, I was thinking in the wrong (and more difficult) direction

                • Re: Using instances in an AFPlugin assembly in a client application
                  cmanhard

                  2 is the mechanism that is used.   Assembly.LoadFrom will still prefer the GAC over the location specified.  If for some reason, you do not want to place in the GAC, then you can force your assembly to load the one from AF Server by adding an AppDomain.AssemblyResolve event handler and then redirecting it to use the Plugin's assembly (you would need to make sure CopyLocal=False for the referenced assembly in your scheduler project).

                   

                  Chris

                    • Re: Using instances in an AFPlugin assembly in a client application
                      MichaelvdV@Atos

                      Nice, I didn't know that Assembly.LoadFrom prefered the GAC over the specified location.

                       

                      I've written a small test application, and it did the trick. Thank you for your clear answer!

                       

                      Another question:

                       

                      Since it seems AFPlugins are loaded into the same appdomain as the hosting application, doesn't this pose a security risk?

                        • Re: Using instances in an AFPlugin assembly in a client application
                          cmanhard

                          Any Plugin architecture, regardless of appdomain use, poses an increased security risk.  By using a separate appdomain, one can control: 1) the ability for a plugin to take down the hosting application and 2) the privileges that plugin has.

                           

                          Regarding 1 - the application itself can control this by hosting AFSDK inside a separate domain.  In the future, we may opt to host analysis rules in separate domains inside the analysis engine for this reason.  As far as the risk of a plugin taking down PI System Explorer or ProcessBook, yes, this would be possible but to date we have deemed this worth the performance trade off. 

                           

                          Regarding 2 - unfortunately, it is difficult to limit privileges of plugins across the board since they often need off-box and unmanaged code access to bring in external data.  However, .NET security for plugins can be configured using caspol (http://msdn.microsoft.com/en-us/library/cb6t8dtz.aspx) to provide more limited rights.  For example, one could specify only specific assemblies or publishers to be trusted.  Note that registering a plugin requires admin privileges on a PI System.

                           

                          Chris