System.AddIn

  • Thread starter Thread starter Nikola Novak
  • Start date Start date
N

Nikola Novak

I've started working with System.AddIn namespace. I downloaded some sample
projects and I managed to make some addins for them.

Later I tried loading controls I made earlier. I've created an exact
replica of the addin project, as well as other projects required by the
system to work, except the controls are now in .cs files rather than .xaml
(when adding a control I made a normal user control file, rather than the
user control (WPF)), but the addin loader seems to simply ignore these
addins. There is no error message, it's just that no addins are found (it's
as if they're not there, even though they are).

Do I need to remake my old controls as WPF conrols, or am I missing
something?

Thanks,
Nikola
 
I've started working with System.AddIn namespace. I downloaded some sample
projects and I managed to make some addins for them.

Later I tried loading controls I made earlier. I've created an exact
replica of the addin project, as well as other projects required by the
system to work, except the controls are now in .cs files rather than .xaml
(when adding a control I made a normal user control file, rather than the
user control (WPF)), but the addin loader seems to simply ignore these
addins. There is no error message, it's just that no addins are found (it's
as if they're not there, even though they are).

Do I need to remake my old controls as WPF conrols, or am I missing
something?
Click to expand...

System.AddIn does not know anything about WPF specifically. So the
answer to your last question is "no, that isn't the problem".

Other than that, without seeing the code for your add-in, and the
loading code in the host, it is very hard to say anything in
particular.
 
System.AddIn does not know anything about WPF specifically. So the
answer to your last question is "no, that isn't the problem".

Other than that, without seeing the code for your add-in, and the
loading code in the host, it is very hard to say anything in
particular.
Click to expand...

That's OK, I just wanted to know if I'm doing it wrong. I'll be posting
code when I'm out of ideas of my own.

Thanks,
Nikola
 
System.AddIn does not know anything about WPF specifically. So the
answer to your last question is "no, that isn't the problem".

Other than that, without seeing the code for your add-in, and the
loading code in the host, it is very hard to say anything in
particular.
Click to expand...

I see from the example I have that in the AddInView, a
System.Windows.Controls.UserControl becomes a FrameworkElement and in
Contract it is handled as INativeHandleContract. It becomes that by means
of FrameworkElementAdapters.ViewToContractAdapter(fe) method which is
called in the AddInViewToContractAdapter, where fe is a FrameworkElement.
Then in ContractToHostViewAdapter it becomes a FrameworkElement again, and
in the main application it is once again a
System.Windows.Controls.UserControl.

What should a System.Windows.Forms.UserControl become (it can't become a
FrameworkElement) in order to pass through the pipeline? Which method
should I call where?

Thanks,
Nikola
 
I see from the example I have that in the AddInView, a
System.Windows.Controls.UserControl becomes a FrameworkElement and in
Contract it is handled as INativeHandleContract. It becomes that by means
of FrameworkElementAdapters.ViewToContractAdapter(fe) method which is
called in the AddInViewToContractAdapter, where fe is a FrameworkElement.
Then in ContractToHostViewAdapter it becomes a FrameworkElement again, and
in the main application it is once again a
System.Windows.Controls.UserControl.
Click to expand...

This all is needed because FrameworkElement does not inherit from
MarshalByRefObject.
What should a System.Windows.Forms.UserControl become (it can't become a
FrameworkElement) in order to pass through the pipeline? Which method
should I call where?
Click to expand...

Nothing. Just pass it around (and, in general, anything derived from
System.Windows.Forms.Control).

This will still fail, but for a different reason :) and that's because
you can only work with a WinForms control on the thread you've created
it on. Yes, there's Control.Invoke() which can marshal, but you can't
create control on one thread, and insert it into a container created
on another thread. Which will be the case with different appdomains.

You can sort of hack around this by using WPF at the boundary. That
is, in your container WinForms application, you use ElementHost
WinForms control. In the add-in, you create your WinForms UI, and host
it in WindowsFormsHost WPF control. You then marshal the later as
usual for WPF, get it in container, and insert it into your
ElementHost. Yes, this is messy.

In general, I do not recommend System.AddIn for most scenarios,
particularly UI - the isolation is seriously overkill. Use MEF instead
(http://www.codeplex.com/MEF) - it's much easier and more "natural" to
use, especially if you've used an IoC/DI container before - and, since
it doesn't provide appdomain isolation, there's no problem with
WinForms either (or WPF for that matter) - everything just works.
Visual Studio 2010 uses MEF for a lot of stuff, particularly UI-
related - editor extensibility, for example (that had a neat demo on
PDC).
 
This all is needed because FrameworkElement does not inherit from
MarshalByRefObject.


Nothing. Just pass it around (and, in general, anything derived from
System.Windows.Forms.Control).

This will still fail, but for a different reason :) and that's because
you can only work with a WinForms control on the thread you've created
it on. Yes, there's Control.Invoke() which can marshal, but you can't
create control on one thread, and insert it into a container created
on another thread. Which will be the case with different appdomains.

You can sort of hack around this by using WPF at the boundary. That
is, in your container WinForms application, you use ElementHost
WinForms control. In the add-in, you create your WinForms UI, and host
it in WindowsFormsHost WPF control. You then marshal the later as
usual for WPF, get it in container, and insert it into your
ElementHost. Yes, this is messy.

In general, I do not recommend System.AddIn for most scenarios,
particularly UI - the isolation is seriously overkill. Use MEF instead
(http://www.codeplex.com/MEF) - it's much easier and more "natural" to
use, especially if you've used an IoC/DI container before - and, since
it doesn't provide appdomain isolation, there's no problem with
WinForms either (or WPF for that matter) - everything just works.
Visual Studio 2010 uses MEF for a lot of stuff, particularly UI-
related - editor extensibility, for example (that had a neat demo on
PDC).
Click to expand...

MEF worked like a charm. Thank you very much for the info.

How come you know so much about VS 2010? Are you one of its developers or
do they have a newsletter about such things somewhere, of which I'm
unaware?

Thanks again,
Nikola
 
Back
Top