Connecting Tech Pros Worldwide Forums | Help | Site Map

microsoft doesn't support dotnet "plugins" good enough

alexl
Guest
 
Posts: n/a
#1: Nov 20 '08
if my program is an .exe application and I need to reference external
assemblies, no problem. I can embed my manifest as resource 1. But if
my program is itself a "plugin," that is a dll that gets loaded to
another .exe program, there's problems. I can still reference the
external assembly via resource identifier 2, but if it is a com
oriented external assembly I have to either modify the hosting .exe
application's resource manifest, use regsvr32, or I have to play
around with activation contexts. thoughts?

sloan
Guest
 
Posts: n/a
#2: Nov 20 '08

re: microsoft doesn't support dotnet "plugins" good enough


One idea: (if you have any control in the other exe)

Provide an interface (ahead of time) to the other .exe.

Then you can provide any number of concretes versions of the interface.

Then instantiate via Reflection.

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry
See the Reflection example.




"alexl" <alextheblade@gmail.comwrote in message
news:d10ee2bb-8466-44c4-bb8f-03b708ae39c2@v42g2000yqv.googlegroups.com...
Quote:
if my program is an .exe application and I need to reference external
assemblies, no problem. I can embed my manifest as resource 1. But if
my program is itself a "plugin," that is a dll that gets loaded to
another .exe program, there's problems. I can still reference the
external assembly via resource identifier 2, but if it is a com
oriented external assembly I have to either modify the hosting .exe
application's resource manifest, use regsvr32, or I have to play
around with activation contexts. thoughts?

Closed Thread