Community
    • Login

    C# plugins share AppDomain?

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    4 Posts 3 Posters 439 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • moon6969M
      moon6969
      last edited by

      TLDR: I have 2 independent C# plugins that appear to share the same .Net AppDomain when running in NPP.
      Does anyone know the side-effects of this?
      Is it something I should investigate further?

      I wrote a C# plugin and had to jump through some hoops so .Net could find a required 2nd dll…

      I hooked into AppDomain.CurrentDomain.AssemblyResolve event so I could give the exact path via System.Reflection.Assembly.LoadFrom().

      This works well enough, but I just discovered that a new C# plugin I am writing is being trapped by the above event in the first plugin.

      I can re-work the first plugin and avoid the AppDomain.CurrentDomain.AssemblyResolve event, but I am wondering if there is something I could do to prevent my plugin affecting other .Net plugins (and vice-versa).

      Any thoughts?

      EkopalypseE 1 Reply Last reply Reply Quote 0
      • EkopalypseE
        Ekopalypse @moon6969
        last edited by

        @moon6969

        what about this, sounds like you can isolate the domains. Note, I have no idea what I’m talking about.

        1 Reply Last reply Reply Quote 0
        • Makwana PrahladM
          Makwana Prahlad Banned
          last edited by

          Hello,@moon6969

          Follow this information,To C# plugins share AppDomain?

          1.Check if the assembly is already loaded
          2.If its not loaded, read the assembly into a byte array. This will prevent locking the file.
          3.Supply the byte array as an arguement to Assembly.Load

          Assembly assembly = null;
          
          foreach(Assembly loadedAssembly in AppDomain.CurrentDomain.GetAssemblies())
              if (loadedAssembly.FullName == "foobar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null")
                  assembly = loadedAssembly;
          
          if(assembly == null)
          {
              byte[] studybin = System.IO.File.ReadAllBytes(@"C:\pathToAssembly\foobar.dll");
              assembly = Assembly.Load(studybin);                
          }
          

          Note :
          If you are trying to find a specific assembly in a directory, you can run ‘System.Reflection.AssemblyName.GetAssemblyName(path);’ to see if the FullName matches what you are looking for. ‘GetAssemblyName(path)’ does NOT inject the assembly into your current AppDomain.

          I hope this information will be usefull.
          Thank you.

          1 Reply Last reply Reply Quote 2
          • moon6969M
            moon6969
            last edited by

            Thanks both.

            I’ve not much idea myself about AppDomains, but I am swatting up. I’m also learning about Managed Extensibility Framework (MEF) and Managed AddIn Framework (MAF) to see if they can help.

            @Makwana-Prahlad
            Thanks for the example - easier for me than theory sometimes!

            1 Reply Last reply Reply Quote 1
            • First post
              Last post
            The Community of users of the Notepad++ text editor.
            Powered by NodeBB | Contributors