By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,666 Members | 1,784 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,666 IT Pros & Developers. It's quick & easy.

microsoft doesn't support dotnet "plugins" good enough

P: n/a
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?
Nov 20 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
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" <al**********@gmail.comwrote in message
news:d1**********************************@v42g2000 yqv.googlegroups.com...
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?

Nov 20 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.