Cull'log

Stefan Cullmann's Blogging

<November 2008>
SuMoTuWeThFrSa
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456


Navigation

CodeGen

Blog roll

Nice to have

Code Generation

Subscriptions

Post Categories

Article Categories



Working with AppDomains inside a VisualStudio Add-In

The VisualStudio Add-In "MyTestPlugIn" is installed by default at %Program Files%\MyTestPlugIn. I have to create an AppDomain inside the Add-In and to create an instance of a Worker Class. This will result in an InvalidCastException.

This code is called from the exec command inside the connect class:

try
{
    AppDomainTest.Worker Worker = AppDomainTest.Factory.CreateWorker ();
    Worker.DoIt();
}
catch
(SystemException ex)
{
     MessageBox.Show (ex.GetType().ToString()+": "+ ex.Message);
}

The appdomain factory and worker class look like this: 

using System;
using System.Runtime.Remoting;
using System.Reflection;

namespace AppDomainTest

{
     public class
Worker:MarshalByRefObject 
     {
         
public
Worker(){}
         
public void
DoIt()
          {
              
System.Windows.Forms.MessageBox.Show ("Hello World");
          }
     }

     public class Factory
     {
         
public static Worker CreateWorker()
          {
               Assembly currentAssembly =Assembly.GetExecutingAssembly();
               AppDomain ad = AppDomain.CreateDomain("WorkerTest"); 
               ObjectHandle oh = ad.CreateInstanceFrom 
                         (currentAssembly.Location,
typeof(Worker).FullName );
              
return (Worker) oh.Unwrap(); //InvalidCastException
          }
     }
}

Note:
The call will work without raising an exception if called from a winform or console. It seems that the add-in assembly can not be found by visual studio to decide if it is the same assembly and type. As a matter of fact copying the add-in assembly inside the Visual Studio\common7\ide directory solves this problem.

But I don't want to place my add-in dlls at two different locations and certainly not under the Visual Studio Path.

Playing around with AppDomain.AppendPrivatePath, added an AppDomainSetup setting the ApplicationBase and PrivateBinPath but this problem remains unsolved.

posted on Sunday, March 21, 2004 5:13 PM by stefan@cullnet.de





Powered by Dot Net Junkies, by Telligent Systems