Why use delegates when using object remoting MarshalByRefObj?









up vote
4
down vote

favorite












My app allows plugins, I have a Core class (MarshalByRefObj) that plugins must inherit and this class offers various functionality. Now my question is, when this class is instantiated on main app domain and passed to the plugin in different app domain, what would be the benefit of using delegates in such scenario:



public class Core : MarshalByRefObject

public void DoSomething()

MyMainApp.Delegate1("SomeMethod", "Test");




So as you can see, my core class calls a delegate method on MyMainApp. I could as well just do MyMainApp.SomeMethod("test") instead.



However in many examples online about how remoting and plugin system works, everyone seems to be using delegates. Is there any specific reason for that? Could someone give me a more practical example of why?










share|improve this question



























    up vote
    4
    down vote

    favorite












    My app allows plugins, I have a Core class (MarshalByRefObj) that plugins must inherit and this class offers various functionality. Now my question is, when this class is instantiated on main app domain and passed to the plugin in different app domain, what would be the benefit of using delegates in such scenario:



    public class Core : MarshalByRefObject

    public void DoSomething()

    MyMainApp.Delegate1("SomeMethod", "Test");




    So as you can see, my core class calls a delegate method on MyMainApp. I could as well just do MyMainApp.SomeMethod("test") instead.



    However in many examples online about how remoting and plugin system works, everyone seems to be using delegates. Is there any specific reason for that? Could someone give me a more practical example of why?










    share|improve this question

























      up vote
      4
      down vote

      favorite









      up vote
      4
      down vote

      favorite











      My app allows plugins, I have a Core class (MarshalByRefObj) that plugins must inherit and this class offers various functionality. Now my question is, when this class is instantiated on main app domain and passed to the plugin in different app domain, what would be the benefit of using delegates in such scenario:



      public class Core : MarshalByRefObject

      public void DoSomething()

      MyMainApp.Delegate1("SomeMethod", "Test");




      So as you can see, my core class calls a delegate method on MyMainApp. I could as well just do MyMainApp.SomeMethod("test") instead.



      However in many examples online about how remoting and plugin system works, everyone seems to be using delegates. Is there any specific reason for that? Could someone give me a more practical example of why?










      share|improve this question















      My app allows plugins, I have a Core class (MarshalByRefObj) that plugins must inherit and this class offers various functionality. Now my question is, when this class is instantiated on main app domain and passed to the plugin in different app domain, what would be the benefit of using delegates in such scenario:



      public class Core : MarshalByRefObject

      public void DoSomething()

      MyMainApp.Delegate1("SomeMethod", "Test");




      So as you can see, my core class calls a delegate method on MyMainApp. I could as well just do MyMainApp.SomeMethod("test") instead.



      However in many examples online about how remoting and plugin system works, everyone seems to be using delegates. Is there any specific reason for that? Could someone give me a more practical example of why?







      c# delegates marshalling






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 11 at 14:36









      J. van Langen

      13.8k22342




      13.8k22342










      asked Nov 11 at 13:29









      Alex Maher

      212




      212






















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          0
          down vote













          Most of the time the controls in a user interface are created by the main thread unless you intentionally create them in another thread. Here is the important bit: ONLY the thread which created the control can access that control.



          If you call DoSomething directly, and code in DoSomething wants to interact with a UI control, it will not be allowed and you will get an exception. MyMainApp.Delegate1("DoSomething" is equivalent to: Please execute the specified method on the main thread. Now it can access UI controls.



          There are other reasons too but that is the most important bit to remember. See MSDN for more.






          share|improve this answer



























            up vote
            0
            down vote













            One of the benefits would be, that the information passed to the MyMainApp.Delegate1 is serialized for transport from the plugin appdomain to the main-appdomain. The Delegate1 method will execute the DoSomething in the main domain. They don't share memory (so no directly access to object instances is possible). So you can dynamically run methods on another appdomains. And if it's done via reflection, a plugin might be able to run unlisted methods.



            I'd rather not use this type of construction, because there is no compile-time check on calling methods. I'd rather use interfaces that are in satelite assemblies. (to prevent the main-appdomain gets a reference to/loading the plugin assembly, so it can't be unloaded anymore)




            The other thing:
            If you call MyMainApp.SomeMethod("test") directly. This implies that the plugin must know the definition of the plugin loader. Meaning that you get a tight coupling (from the plugin) to the 'parent' application(s version). Which makes the whole plugin structure 'useless'. You could fix that by implementing a ISupportSomeMethod interface on the MyMainApp which is defined in a satelite assembly that is used by both the mainapp en the plugin. If your MyMainApp doesn't implement the ISupportSomeMethod interface, the plugin isn't compatible with that program. This way your MyMainApp can support multiple plugin structures.




            In this case you prefer an event structure. Because the child object wants to trigger a method of it's parent. Too bad cross domain event calls are not useful, because your main module will load the assembly and it can't be unloaded. You could write a proxi class for that.






            share|improve this answer






















              Your Answer






              StackExchange.ifUsing("editor", function ()
              StackExchange.using("externalEditor", function ()
              StackExchange.using("snippets", function ()
              StackExchange.snippets.init();
              );
              );
              , "code-snippets");

              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "1"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53249215%2fwhy-use-delegates-when-using-object-remoting-marshalbyrefobj%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              0
              down vote













              Most of the time the controls in a user interface are created by the main thread unless you intentionally create them in another thread. Here is the important bit: ONLY the thread which created the control can access that control.



              If you call DoSomething directly, and code in DoSomething wants to interact with a UI control, it will not be allowed and you will get an exception. MyMainApp.Delegate1("DoSomething" is equivalent to: Please execute the specified method on the main thread. Now it can access UI controls.



              There are other reasons too but that is the most important bit to remember. See MSDN for more.






              share|improve this answer
























                up vote
                0
                down vote













                Most of the time the controls in a user interface are created by the main thread unless you intentionally create them in another thread. Here is the important bit: ONLY the thread which created the control can access that control.



                If you call DoSomething directly, and code in DoSomething wants to interact with a UI control, it will not be allowed and you will get an exception. MyMainApp.Delegate1("DoSomething" is equivalent to: Please execute the specified method on the main thread. Now it can access UI controls.



                There are other reasons too but that is the most important bit to remember. See MSDN for more.






                share|improve this answer






















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  Most of the time the controls in a user interface are created by the main thread unless you intentionally create them in another thread. Here is the important bit: ONLY the thread which created the control can access that control.



                  If you call DoSomething directly, and code in DoSomething wants to interact with a UI control, it will not be allowed and you will get an exception. MyMainApp.Delegate1("DoSomething" is equivalent to: Please execute the specified method on the main thread. Now it can access UI controls.



                  There are other reasons too but that is the most important bit to remember. See MSDN for more.






                  share|improve this answer












                  Most of the time the controls in a user interface are created by the main thread unless you intentionally create them in another thread. Here is the important bit: ONLY the thread which created the control can access that control.



                  If you call DoSomething directly, and code in DoSomething wants to interact with a UI control, it will not be allowed and you will get an exception. MyMainApp.Delegate1("DoSomething" is equivalent to: Please execute the specified method on the main thread. Now it can access UI controls.



                  There are other reasons too but that is the most important bit to remember. See MSDN for more.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 11 at 13:56









                  CodingYoshi

                  17k22132




                  17k22132






















                      up vote
                      0
                      down vote













                      One of the benefits would be, that the information passed to the MyMainApp.Delegate1 is serialized for transport from the plugin appdomain to the main-appdomain. The Delegate1 method will execute the DoSomething in the main domain. They don't share memory (so no directly access to object instances is possible). So you can dynamically run methods on another appdomains. And if it's done via reflection, a plugin might be able to run unlisted methods.



                      I'd rather not use this type of construction, because there is no compile-time check on calling methods. I'd rather use interfaces that are in satelite assemblies. (to prevent the main-appdomain gets a reference to/loading the plugin assembly, so it can't be unloaded anymore)




                      The other thing:
                      If you call MyMainApp.SomeMethod("test") directly. This implies that the plugin must know the definition of the plugin loader. Meaning that you get a tight coupling (from the plugin) to the 'parent' application(s version). Which makes the whole plugin structure 'useless'. You could fix that by implementing a ISupportSomeMethod interface on the MyMainApp which is defined in a satelite assembly that is used by both the mainapp en the plugin. If your MyMainApp doesn't implement the ISupportSomeMethod interface, the plugin isn't compatible with that program. This way your MyMainApp can support multiple plugin structures.




                      In this case you prefer an event structure. Because the child object wants to trigger a method of it's parent. Too bad cross domain event calls are not useful, because your main module will load the assembly and it can't be unloaded. You could write a proxi class for that.






                      share|improve this answer


























                        up vote
                        0
                        down vote













                        One of the benefits would be, that the information passed to the MyMainApp.Delegate1 is serialized for transport from the plugin appdomain to the main-appdomain. The Delegate1 method will execute the DoSomething in the main domain. They don't share memory (so no directly access to object instances is possible). So you can dynamically run methods on another appdomains. And if it's done via reflection, a plugin might be able to run unlisted methods.



                        I'd rather not use this type of construction, because there is no compile-time check on calling methods. I'd rather use interfaces that are in satelite assemblies. (to prevent the main-appdomain gets a reference to/loading the plugin assembly, so it can't be unloaded anymore)




                        The other thing:
                        If you call MyMainApp.SomeMethod("test") directly. This implies that the plugin must know the definition of the plugin loader. Meaning that you get a tight coupling (from the plugin) to the 'parent' application(s version). Which makes the whole plugin structure 'useless'. You could fix that by implementing a ISupportSomeMethod interface on the MyMainApp which is defined in a satelite assembly that is used by both the mainapp en the plugin. If your MyMainApp doesn't implement the ISupportSomeMethod interface, the plugin isn't compatible with that program. This way your MyMainApp can support multiple plugin structures.




                        In this case you prefer an event structure. Because the child object wants to trigger a method of it's parent. Too bad cross domain event calls are not useful, because your main module will load the assembly and it can't be unloaded. You could write a proxi class for that.






                        share|improve this answer
























                          up vote
                          0
                          down vote










                          up vote
                          0
                          down vote









                          One of the benefits would be, that the information passed to the MyMainApp.Delegate1 is serialized for transport from the plugin appdomain to the main-appdomain. The Delegate1 method will execute the DoSomething in the main domain. They don't share memory (so no directly access to object instances is possible). So you can dynamically run methods on another appdomains. And if it's done via reflection, a plugin might be able to run unlisted methods.



                          I'd rather not use this type of construction, because there is no compile-time check on calling methods. I'd rather use interfaces that are in satelite assemblies. (to prevent the main-appdomain gets a reference to/loading the plugin assembly, so it can't be unloaded anymore)




                          The other thing:
                          If you call MyMainApp.SomeMethod("test") directly. This implies that the plugin must know the definition of the plugin loader. Meaning that you get a tight coupling (from the plugin) to the 'parent' application(s version). Which makes the whole plugin structure 'useless'. You could fix that by implementing a ISupportSomeMethod interface on the MyMainApp which is defined in a satelite assembly that is used by both the mainapp en the plugin. If your MyMainApp doesn't implement the ISupportSomeMethod interface, the plugin isn't compatible with that program. This way your MyMainApp can support multiple plugin structures.




                          In this case you prefer an event structure. Because the child object wants to trigger a method of it's parent. Too bad cross domain event calls are not useful, because your main module will load the assembly and it can't be unloaded. You could write a proxi class for that.






                          share|improve this answer














                          One of the benefits would be, that the information passed to the MyMainApp.Delegate1 is serialized for transport from the plugin appdomain to the main-appdomain. The Delegate1 method will execute the DoSomething in the main domain. They don't share memory (so no directly access to object instances is possible). So you can dynamically run methods on another appdomains. And if it's done via reflection, a plugin might be able to run unlisted methods.



                          I'd rather not use this type of construction, because there is no compile-time check on calling methods. I'd rather use interfaces that are in satelite assemblies. (to prevent the main-appdomain gets a reference to/loading the plugin assembly, so it can't be unloaded anymore)




                          The other thing:
                          If you call MyMainApp.SomeMethod("test") directly. This implies that the plugin must know the definition of the plugin loader. Meaning that you get a tight coupling (from the plugin) to the 'parent' application(s version). Which makes the whole plugin structure 'useless'. You could fix that by implementing a ISupportSomeMethod interface on the MyMainApp which is defined in a satelite assembly that is used by both the mainapp en the plugin. If your MyMainApp doesn't implement the ISupportSomeMethod interface, the plugin isn't compatible with that program. This way your MyMainApp can support multiple plugin structures.




                          In this case you prefer an event structure. Because the child object wants to trigger a method of it's parent. Too bad cross domain event calls are not useful, because your main module will load the assembly and it can't be unloaded. You could write a proxi class for that.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Nov 12 at 8:34

























                          answered Nov 11 at 14:33









                          J. van Langen

                          13.8k22342




                          13.8k22342



























                              draft saved

                              draft discarded
















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53249215%2fwhy-use-delegates-when-using-object-remoting-marshalbyrefobj%23new-answer', 'question_page');

                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Top Tejano songwriter Luis Silva dead of heart attack at 64

                              政党

                              天津地下鉄3号線