<p>I am developing an .net application which heavely depends on plugins. The application itself contains an connection to a remote server.</p>

<p>Recently I digged into Application domains and see them as the ideal solution for isolating the plugin code from the rest of the application. </p>

<p>However there is one big disadvantage which makes me unable to implement the application domains for hosting the plugins. It seems there is no way to pass an object by reference to another application domain which is needed to pass an reference to the connection object. </p>

<p>I was hoping someone could give me a workaround so I can pass an reference to that object.</p>

<p>Note: Creating a proxy is out of the question, the connection layer already acts as a proxy since the classes are auto generated.</p>

<p>Note2: System.AddIn can not be used as it is not available on the compact framework.</p>

Have you tried deriving from
MarshalByRefObject
? It's a pain in that it screws up your inheritance hierarchy, but I think it's what you want.
From the docs:
MarshalByRefObject is the base class
  for objects that communicate across
  application domain boundaries by
  exchanging messages using a proxy.
  Objects that do not inherit from
  MarshalByRefObject are implicitly
  marshal by value. When a remote
  application references a marshal by
  value object, a copy of the object is
  passed across application domain
  boundaries.
MarshalByRefObject objects are
  accessed directly within the
  boundaries of the local application
  domain. The first time an application
  in a remote application domain
  accesses a MarshalByRefObject, a proxy
  is passed to the remote application.
  Subsequent calls on the proxy are
  marshaled back to the object residing
  in the local application domain.
Types must inherit from
  MarshalByRefObject when the type is
  used across application domain
  boundaries, and the state of the
  object must not be copied because the
  members of the object are not usable
  outside the application domain where
  they were created.
In my experience, it can be pretty limiting - you really need to do as little as possible across the AppDomain boundary, preferrably restricting yourself to operations which only require primitive types, strings, and arrays of both. This may well be due to my own inexperience in working with multiple AppDomains, but it's just a warning that it's a bit of a minefield.