System.AddIn Tools and Samples

Closed Issue: CodeGen References Problem [1850]

mSid — Thu, 16 May 2013 09:33:15 GMT

After using the pipeline builder I have to go and fix up references in the generated adapters. Here's an example. Here is one of my contracts:

[AddInContract]
public interface IHostContract : IContract
{
void Register(IServiceContract service, Type serviceType);
IServiceContract Resolve(Type serviceType);
}

This is generated for my IHost contract->view adapter:

public void Register(IService service, System.Type serviceType)
{
...
}
public IService Resolve(System.Type serviceType)
{
...
}

However, the IService references doesn't resolve until I qualify them as Contract.AddInViews.IService.

New Post: AddIns built against an older version of the AddInViews assembly not being found by FindAddIn

dcabral — Wed, 24 Apr 2013 22:15:51 GMT

I also have this issue. I need to update the version numbers of all my classes as I release a new version of my solution. I can't updated the Add-In pipeline classes, specifically the AddInView dll, because that prevents older Add Ins referencing the older AddInView dll from loading (being found) anymore.

I really need an answer for to this dilemma.

New Post: Addins slow again...

prashanthb — Sun, 14 Apr 2013 02:41:06 GMT

Hi Jesse,

I have created a WPF addin application , which is returned as a FrameworkElement, which is being added as a control in MainForm(HOST) application. The MainForm is being loaded in a external class library under Application.Run(new MainForm), after going through several articles including at http://blogs.msdn.com/b/clraddins/archive/2008/02/22/add-in-performance-what-can-you-expect-as-you-cross-an-isolation-boundary-and-how-to-make-it-better-jesse-kaplan.aspx, which is very informative. I have applied LoaderOptimization.MultiDomainHost on top of the method which has Application.Run(new MainForm) and even installed Contracts in GAC, but my application is facing very critical performance issue by taking nearly 25secs to load my addin. I have to improve the performance before UAT. Can you please let me know, how to improve the performance and is it something i have missed. Remember my Contract is not a value type but of IContract type, which is MarshallByRef,.

Thanks
Prash

Source code checked in, #81799

Project Collection Service Accounts — Mon, 01 Oct 2012 21:57:23 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #81798

Project Collection Service Accounts — Mon, 01 Oct 2012 21:51:05 GMT

Checked in by server upgrade

New Post: During activation, what will be the search path for the add-in dependency dlls ?

p_ronto — Wed, 28 Mar 2012 09:37:34 GMT

Hello Agnes,

I made another test to recreate the problem you mention. I did the following:

1) All projects in the pipeline have the following setting: Target framework = .Net Framework 4, Platform Target = Any CPU.

2) The add-in project references an assembly that is not in the GAC. I set "Copy Local" to false. I set this to create a FileNotFoundException.

3) Activated an add-in in a new process with FullTrust security level.

The FileNotFoundException was thrown and in details, I checked the FusionLog property. The log entry is the following:

=== Pre-bind state information ===
LOG: User = panos
LOG: DisplayName = Quartz, Version=2.0.0.100, Culture=neutral, PublicKeyToken=f6b8c98a402cc8a4
(Fully-specified)
LOG: Appbase = file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug
LOG: Initial PrivatePath = NULL
Calling assembly : Cpi.Platform.AddIn.Ocr.FineReader, Version=1.0.0.20018, Culture=neutral, PublicKeyToken=5470f4aca8377cb7.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Quartz, Version=2.0.0.100, Culture=neutral, PublicKeyToken=f6b8c98a402cc8a4
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Quartz.DLL.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Quartz/Quartz.DLL.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Quartz.EXE.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Quartz/Quartz.EXE.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Ocr/FineReader/Quartz.DLL.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Ocr/FineReader/Quartz/Quartz.DLL.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Ocr/FineReader/Quartz.EXE.
LOG: Attempting download of new URL file:///C:/dev/projects/Visual Studio 2010/Experiments/Scanner/output/Debug/Ocr/FineReader/Quartz/Quartz.EXE.

Notice that the AppBase is in the add-in folder. In your log entry, it was in c:\windows\blahblah.

I run the test in a Windows 7 x86 with VS2010 and in a Windows 7 x64 with VS2010 and in both case the AppBase was the same. This means that if I set Copy Local = true, the referenced assembly will be copied in the add-in folder and will be loaded correctly since it will be in the AppBase.

Also note that I get the same behaviour when I activate the add-in in a new AppDomain (created by MAF). Exactly the same thing. AppBase is the add-in's folder. If you created the AppDomain yourself, then you can set any ApplicationBase (in System.AppDomainSetup) you want. This is great if you want to share assemblies between your add-ins. You can even subscribe to the AppDomain.AssemblyResolve event that is triggered when an assembly cannot be resolved and load it from another directory. Unfortunately I haven't found a way to do this when for add-ins hosted in a new process.

I can't understand why in your case the AppBase is in c:\windows\fram.... Maybe you should try to experiment with the project settings. Or maybe do a test solution from scratch and follow the steps I mentioned above.

Regards,

Panos

New Post: During activation, what will be the search path for the add-in dependency dlls ?

agnesw — Fri, 23 Mar 2012 02:32:04 GMT

Hi Panos,

Sorry that I have not really put much time in this since we talked last time, right now, my plugin is running under a new App Pool instead of a separate process.

From my last test, if i were to run the plugin under a separate process, the dependent dlls need to be deployed under GAC, otherwise, I would get the dlls not found error as soon as I started the process.

I plan to go back to this later, maybe I can create a test project and verify this and let you know.

If there is anything that you find, i would be grateful if you could share that with me.

Thanks Panos!
Agnes

From: [email removed]
To: [email removed]
Date: Thu, 22 Mar 2012 07:06:36 -0700
Subject: Re: During activation, what will be the search path for the add-in dependency dlls ? [clraddins:287660]

From: p_ronto

Hello Agnes,
Did you find the solution to this problem? I'm curious because, since I'm currently working on a MAF based application, it would help to be prepared for things that can go wrong.
Panos

Read the full discussion online.
To add a post to this discussion, reply to this email (clraddins@discussions.codeplex.com)
To start a new discussion for this project, email clraddins@discussions.codeplex.com
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

New Post: During activation, what will be the search path for the add-in dependency dlls ?

p_ronto — Thu, 22 Mar 2012 14:06:35 GMT

Hello Agnes,

Did you find the solution to this problem? I'm curious because, since I'm currently working on a MAF based application, it would help to be prepared for things that can go wrong.

Panos

New Post: During activation, what will be the search path for the add-in dependency dlls ?

agnesw — Tue, 31 Jan 2012 10:26:40 GMT

Under the pipeline, this is the only add-in that reference those dlls.

Activating the add-in in a different AppDomain is fine, just activating it under a different process gives me this issue that I must load the referenced assemblies under the GAC.

Thanks.

New Post: During activation, what will be the search path for the add-in dependency dlls ?

p_ronto — Tue, 31 Jan 2012 10:23:10 GMT

Do you reference this assembly from any other project in the pipeline?

By the way have you tried to Activate the add-in in the same AppDomain with the host?

New Post: During activation, what will be the search path for the add-in dependency dlls ?

agnesw — Tue, 31 Jan 2012 04:20:55 GMT

Hi Panos,

I tried to add reference to the common dlls from the add-in project and set the "CopyLocal" to true, but it does not work.

I looked at the Assembly Binding Log Viewer and seems like it starts from the framework directory as AppBase, and only look for the .NET config files, AddInProcess.exe.Config & Machine.config without looking under any application configs, is this expected ?

*** Assembly Binder Log Entry (1/31/2012 @ 12:13:33 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Windows\Microsoft.NET\Framework64\v4.0.30319\AddInProcess.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = NT AUTHORITY\NETWORK SERVICE
LOG: DisplayName = ABC.Common, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = AddInProcess.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\AddInProcess.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

New Post: During activation, what will be the search path for the add-in dependency dlls ?

p_ronto — Mon, 30 Jan 2012 17:05:49 GMT

Hello Agnes,

You don't have to add the referenced DLLs in the GAC.

What I do is simply add a reference to my add-in project and then set "CopyLocal" to true on the reference properties.

Regards,

Panos

New Post: During activation, what will be the search path for the add-in dependency dlls ?

agnesw — Fri, 27 Jan 2012 17:58:26 GMT

I'm loading each add-in in a separate process by using the following:

AddInProcess addInProcess = new AddInProcess();

addIn = token.Activate<IPlugIn>(addInProcess, AddInSecurityLevel.FullTrust);

If the addIn has some dependency dlls, I found that by the time I invoked .Activate, it will try to load the dependency dlls from GAC, is there anyway that I can instruct it to load from a private path ? No matter if i put the dependency dlls under the directory where the host is located or the pipeline directory or the add-in directory, it always tries to load it from GAC, if the assemblies are not installed in GAC, it will report an error saying "unable to locate assembly". Is this expected ? I would like it to locate the dependency dlls from the private path rather than in GAC.

Thanks,
Agnes

New Post: AddIns built against an older version of the AddInViews assembly not being found by FindAddIn

RMorrey — Wed, 02 Nov 2011 17:10:58 GMT

I have a MAF project which has been manually built under VS2010 .Net 4 (fully updated).

If I rebuild all of the required MAF assemblies (HostViews, AddInViews, Contracts and adapter) and all of the AddIns then MAF will successfully find all of the Addins which are stored in the default AddIn folder of the PipelineStore.

However, If I try to include an AddIn which has been build against an older version of the AddInViews assembly (For instance compiled against version (Assembly and File) 1.0.0.1 but the currently loaded version is 1.0.0.2, then calling AddInStore.FindAdd() does not include the AddIn compiled against an older version. All addins compiled against the current version are returned.

I've tried calling AddInStore.Rebuild and AddInStore.Update but there is still no luck. Calling these methods does not return any warnings (nor do I get any exceptions)

Using the debugger to look at the AddInStore details I can see that the AddIn I'm trying to find is located in the AddInStore addinState information but still it doesn't get returned when trying to find it.

I can rebuild the Addin that is not currently being found but my major concern is that once we release our product for 3rd parties to create plugins then we will not be able to issue newer version our project without have to get all Addins rebuilt.

Is there a setting I'm missing which allows MAF to ignore version information? Or is there something else I'm missing?

Thanks for you help.

Rob.

New Post: Addin Shared Libraries

cwang733t — Tue, 27 Sep 2011 19:56:53 GMT

Never mind I figured it out.

IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(IReport), DIRECTORY_PATH);
            _reports = new List<IReport>();
foreach (AddInToken token in tokens)
{
    _reports.Add(token.Activate<IReport>(AppDomain.CurrentDomain));
    addReport(_reports.Last<IReport>());
}

If you pass the current app domain, you pass the current references.

New Post: Addin Shared Libraries

cwang733t — Tue, 27 Sep 2011 19:49:04 GMT

I am using System.Addin for .Net 3.5 Visual Studio 2008.

I have several addins which share the same set of libraries. I would like to have a directory depository for the libraries instead of having to copy an instance of each addon. Is there a way to do this without having to use the GAC (I cannot install on the user's machine).

Thanks, Wang

New Post: Does Eventing Causes Memory Leaks? Seems too...

JohnAlberts — Tue, 19 Jul 2011 09:59:41 GMT

Hi all,

After testing we have found a problem with the HwndSource / AddInHostSite references too. We created a very simple test application where the only thing we do is transfer the FrameworkElement from AddIn to Host. We do NOT use, in any way, the FrameworkElement in the host itself. So the reference is left for the Garbage collector. In this test we set the default Lease and RenewOnCallTime of remoting to 5 seconds. When we loop through this code a 100 times or so, we observed the following:

Memory only increased and was not released. (We use System.GC.Collect and GC.WaitForPendingFinalizers after each call to get the UI)
We noticed that when calling System.AddIn.Pipeline.FrameworkElementAdapters.ContractToViewAdapter(INativeHandleContract inhc) in the Host adapter, an AddInHostSite object was marshalled to the AddIn
When we implemented INativeContractHandle ourselves, we did NOT see the marshalling of the AddInHostSite from Host --> AddIn
The amount of AddInHwndSourceWrapper System.AddIn.Pipeline.AddInHwndSourceWrapper objects was the same as the amount of calls we made to get the FrameworkElement from the AddIn.
The same goes for MS.Internal.Controls.AddInHost and AddInHostSite
When we shut down the Dispatcher with Dispatcher.Current.InvokeShutdown, all references were removed.

This has led us to believe that a circular reference is created between the Host and AddIn. This reference keeps a lot of memory alive as the entire business model is attached to the Framework element at the AddIn side. We have created a very ugly workaraound that basically does the following:

Intercept the Marshalling of the AddInHostSite object to the AddIn appdomain.
Register this object to be disconnected (from the remoting services) and its lifetime revoked (Reflection on private parts of AddInHostSite . . . ugh!)
Disconnect and revoke this object when the host form closes.

I know that this a rather tricky solution but it does clean up the references between Host and AddIn and we could verify that the system was pretty stable in memory consumption. In case anyone has found another/better solution, I would very much like to hear it.

Best regards,

John

New Post: Is MAF still alive?

quetzalcoatl — Mon, 27 Jun 2011 13:40:13 GMT

samirkut - Please correct me if I'm wrong, but the MEF you mentioned is something of on a different level/problem abstraction than MAF. Only the names are similar. MEF is an IoC while MAF is a communication and discovery platform based on Remoting. To be more correct, you would rather compare MAF to the WCF!

no to the my part -

The question on MAF's liveliness is problematic for me, too. I have been using WCF for networking like accessing webservices etc, but I found them really irritating to manage when dealing with 100% localmachine communication (and also quite slow, but that was probably implementational detail). What I have to deal with is a "worker process" "pattern", which is simple in its core, but gets annoingly due to the small addition that my worker is almost guaranteed to crash .... at native level. And pitifully, that libraries I must use are not patchable, so I have to deal with it on the upper level in a checkpoint/restore/retry manner.

The first thought was, that the .Net remoting is the best way to hack up a worker process, but for some time I always stumble upon some notes like "forget remoting, get WCF", "remoting is obsolete" and so on. After glueing together some solutions in WCF and my own worker code, I decided to give Remoting/MAF try and for now, except some Pipelinebuilder nuisances and such, I'm happy with it.

But the questions stays: Microsoft claimed in not a few places that .Net Remoting is obsolete and all developers should switch to WCF wherever possible. MAF is nice but bases on Remoting. Does that mean that MAF (a.k.a System.AddIn) was created/released and instantly dropped? Or maybe it will be ported to WCF? or maybe it is just that the Remoting is NOT obsolete but just discouraged?

New Post: Is MAF still alive?

samirkut — Tue, 17 May 2011 16:42:59 GMT

I am thinking of using MAF for one of my projects. However the lack of activity on MS website & this site is worrying. Is this technology still viable? Or should I be looking at newer alternatives like MEF? Any feedback would be appreciated. Thanks.

New Post: virtual methods in abstract class

mliddell — Mon, 07 Feb 2011 20:47:27 GMT

Can the addin class have virtual members?

Otherwise, every addin variant cannot inherit common functionality.

Mike