Is there an equivalent of ApplicationCatalog in VS MEF?

[PawcioCNCProfi]

Hi, I'm using System.ComponentModel.Composition in a net48 application but after recent updates to some referenced libraries I get exceptions when composing parts. The info I get is very vague and I have hard time identifying the issue so I decided to try your library in hope of better diagnostic. Unfortunately the issue is actually from ApplicationCatalog and since I've read you don't have DirectoryCatalog I suspect there is also nothing like ApplicationCatalog, right?
I just what to figure out if it's worth to invest the time into this as I don't use the MEF very extensively and I've already have problem with the hosting example i.e.

discovery.CreatePartsAsync(Assembly.GetExecutingAssembly())

gives me proper result but takes literally ~5 minutes to execute, and that is only for a single assembly...
If the VS MEF can't scan the whole app and I need to implement something like ApplicationCatalog myself then the whole purpose of getting more diagnostics is gone.

[AArnott]

I've never used ApplicationCatalog, but based on its summary doc:

Discovers attributed parts in the dynamic link library (DLL) and EXE files in an application's directory and path.

That's trivial to reproduce with VS-MEF. Enumerate the files you want to include in the catalog (e.g. Directory.EnumerateFiles) and pass that to PartDiscovery.CreatePartsAsync.

We use this in Visual Studio to scan 300 assemblies in several seconds. One assembly shouldn't ever take 5 minutes unless (maybe?) it was 1GB in size or you had a debugger attached that was slowing it down.

And yes, VS-MEF produces much better diagnostics for catalog and composition level errors.

[PawcioCNCProfi]

Right, that could explain why I have composition failure in the first place. Not sure why I just assumed the ApplicationCatalog only includes assemblies used by the app and I have some other programs in the app's directory that may not necessarily be compatible...
I've just wrote my own, simple parts scanning using Mono.Cecil and it takes 1.5-2s to collect all the parts from 66 dependency assemblies, depending on machine.
I figured out the discovery.CreatePartsAsync(Assembly.GetExecutingAssembly()) is also running ~2s but the actual problem I have is with synchronization - I'm running this form main application thread (WPF) and every possible trick I tried to get the result back to calling thread failed.
I don't want to rework the whole app initialization procedure just for this and it looks like CreatePartsAsync() is the only async method in your API, so I though maybe I could provide my own parts? I see ComposablePartDefinition have some public constructors, but the question is, does VS MEF really support custom parts creation (with all other associated types) or are those constructors public only for convenience? I would like to know that before I start to implement the parts conversions.
My setup is very simple, I only use just a few type exports and few collections imports, with a whopping number of 8 build-in parts (I mainly have MEF for external app plugins).

[AArnott]

CreatePartsAsync return a standard awaitable task, so if you use await CreatePartsAsync on the main thread, it will return to the main thread unless you have something misconfigured in your application (which would be surprising).

I do not recommend you create your own part objects. Instead, just look through the synchronous CreatePart* methods. If you load the assemblies yourself for example, you can enumerate the types in those assemblies and call CreatePart on each one. It may be slower than our tuned and parallel code paths for whole assemblies or lists of assemblies though.

[PawcioCNCProfi]

But that would require to make the calling methods async, all they way to Application.Startup event. And from my experience await returns to calling thread 99.99% of the time but it's not really guaranteed. Normally you don't care about this but it's the WPF which requires use of single thread in the first place...
I see there is one other CratePart() but that is actually a good idea you gave me - I can easily produce list of participating types for my homemade parts.

[AArnott]

Please reply to my comments using the proper text box instead of writing whole new "answers" to your question. It's a github UI thing to get used to.

[PawcioCNCProfi]

Ahh, yea, sorry for that.

[AArnott]

from my experience await returns to calling thread 99.99% of the time but it's not really guaranteed.

It's guaranteed unless you're misreading something or someone screwed up the configuration. Awaiting a Task while on the main thread will always return to the main thread in a WinForms/WPF app unless you use .ConfigureAwait(false) or someone screwed up SynchronizationContext.Current.

would require to make the calling methods async, all they way to Application.Startup event

If you want it to be truly async, yes. If you don't, then your app will freeze while it loads and scans all DLLs. That's a choice you have.
But you can avoid the async keyword going all the way down your callstack (and leave the UI delay) while still calling async methods and blocking on their completion.
Calling Task.Wait() on the result of an async method will often deadlock your app. In this case I think it wouldn't because as a library, VS-MEF uses .ConfigureAwait(false) everywhere. But if you had any doubt, you could move to invoke the CreatePartsAsync method on a threadpool thread and then block on that. e.g.

// on main thread
DiscoveredParts dp =  Task.Run(() => partDiscovery.CreatePartsAsync(listOfPaths)).Result; // main thread blocks on threadpool

[Audionysos]

This example you wrote is actually first(or second) thing I tried, besides several other approaches that usually work and few that I've found just recently... All attempts made it stuck for 2-5min, and somehow produce like 100 worker threads. Not really sure what's going on. The only way I can get result in seconds is passing callback to ContinueWith().

I don't think I do anything extraordinary in terms of configuration. The only other asynchronous thing I see so far is a splash screen window, but it runs on it's own, separate thread so I don't think it should interfere with main thread in any way:

#region Splash screen
private SplashScreen splash;
private bool endSplash = false;
private bool bringSplashToTop = false;
private void showSplashScreen() {
	log("Creating splash screen on new thread.");
	var st = new Thread(() => {
		splash = new SplashScreen();
		splash.Title = "Starting...";
		splash.Show();
		splash.Activate();
		log("Splash screen was activated.");
		CompositionTarget.Rendering += (s, e) => {
			if (endSplash) Dispatcher.ExitAllFrames();
			else if (bringSplashToTop) {
				showAppliactionWindow(splash);
				bringSplashToTop = false;
			}
		};
		Dispatcher.Run();
		log("Splash screen finished.");
	});
	st.IsBackground = true;
	st.SetApartmentState(ApartmentState.STA);
	st.Start();
}
#endregion

PS. Ok, I think I got this.
So I created a dummy test task to run it the same way and at same point:

private Task<string> test() => Task.Delay(1000)
	.ContinueWith(t => "result", TaskScheduler.Default);

The app hangs but this time there are only two worker threads and both are sitting at this ancient helper method for image loading

public static Image imageFromStringAsync(DispatcherObject o, string s, Image i = null, Stretch st = Stretch.None, string baseDirectory = null, bool tryDefaultImageIfNotFound = true) {
	i = i ?? new Image();
	Task.Run(() => {
		var b = getBitmap(s, baseDirectory, tryDefaultImageIfNotFound);
		if (b == null) return;
		b.Freeze();
		o.Dispatcher.InvokeAsync(() => i.Source = b);
	});
	i.Stretch = st;
	return i;
}

So I changed the Invoke() to InvokeAsync() and now the CreatePartsAsync() takes milliseconds to execute.
I know that this is not really your concern and that this is getting off topic but I don't quite get how this works.
I understand that the worker threads waited for the main thread and thus couldn't exit, but I don't know what exactly is going on the main thread 🦧

[PawcioCNCProfi]

Well, that didn't work as I expected :/
Turns out the public ComposablePartDefinition? CreatePart(Type partType) only returns type exports i.e it produces part for something like this

[Export(typeof(FileConverter))]
public class CNC_SVG_Converter : FileConverter {}

but If I give it a type only containing import members, it doesn't pick that:

public class Office : IToolClient {

	#region MEF Components
	/// <summary>Stores external MEF workstations.</summary>
	[ImportMany]
	protected IEnumerable<Lazy<WorkStation>> externalWorks;
}

[AArnott]

The System.ComponentModel.Composition MEF engine doesn't create parts for that either. A class that has no export is not a MEF 'part'. MEF will only satisfy imports on such a class if you pass an instance of that object to SatisfyImportsOnce. VS-MEF also supports that.

[Audionysos]

And this also works! I just didn't go further when I saw "parts" missing, I'm not that familiar with the MEF, over the years I almost forgot I'm even used it. Sorry for bothering you.