Mefx like command line tool

[sarda-devesh]

No description provided.

[codecov-commenter]

Codecov Report

Merging #271 (9a90795) into main (06c0786) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #271      +/-   ##
==========================================
- Coverage   89.65%   89.55%   -0.10%     
==========================================
  Files          87       87              
  Lines        6088     6111      +23     
==========================================
+ Hits         5458     5473      +15     
- Misses        630      638       +8     

Impacted Files	Coverage Δ
...sualStudio.Composition/ComposablePartDefinition.cs	95.34% <0.00%> (-3.02%)	⬇️
...mposition/Configuration/AttributedPartDiscovery.cs	96.11% <0.00%> (-0.71%)	⬇️
...position/Configuration/SerializationContextBase.cs	94.10% <0.00%> (-0.41%)	⬇️
...oft.VisualStudio.Composition/RuntimeComposition.cs	92.42% <0.00%> (-0.03%)	⬇️
...crosoft.VisualStudio.Composition/ExportProvider.cs	96.39% <0.00%> (-0.01%)	⬇️
...osoft.VisualStudio.Composition/Strings.Designer.cs	68.67% <0.00%> (ø)
...timeExportProviderFactory+RuntimeExportProvider.cs	97.74% <0.00%> (+<0.01%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 06c0786...9a90795. Read the comment docs.

[AArnott]

Devesh, maybe this regressed when you removed the custom IAssemblyLoader in your tool, but when I try your tool at the CLI, it fails to load the assembly:

dotnet run -- --file C:\git\MEF\bin\Tests\Debug\net6.0\CarOne.dll C:\git\MEF\bin\Tests\Debug\net6.0\CarTwo.dll

It looks like .NET Core rejects it because only the assembly name is passed to Assembly.Load, and .NET Core ignores the codebase path. Did you have this working at some point in the past? If so, can you fix it?

[AArnott]

Note: please git pull before making more changes as I've added to your PR.

[sarda-devesh]

Hello, As you correctly guessed the issue was because of the fact that I removed the CustomAssemblyLoader. This custom loader would create a custom load context and then load the requested files in the custom load context. The change meant that the program defaulted to using the Resolver.DefaultInstance which in turn used the StandardAssemblyLoader.

The issue is that the standard loader calls Assembly.Load which completes ignores the path of the file. To load the file from the file path, want to use Assembly.LoadFrom as that allows us to specify a file path. Thus I created another custom loader called LoadUsingPathFirst that loads the file using Assembly.LoadFrom if a file path is specified and using Assembly.Load if not.

Doing so meant that when I run the following command on the command line dotnet run --parts --file "<path to vs-mef folder>\bin\Tests\Debug\net6.0\CarOne.dll I get the desired output of

Parts in the Catalog are
CarOne.FirstCar
CarOne.InvalidType
CarOne.MoreMetadata

Since to load any assemblies in Mefx a file path must be specified, this means that we will always have a file path for every assembly we want to load. This means that in reality, we will always load assemblies using the Assembly.LoadFrom method. Going through the documentation, I found that

The load-from context contains assemblies for which the user provided a path that is not included in probing. LoadFrom, CreateInstanceFrom, and ExecuteAssembly are examples of methods that load by path.

I was wondering how much of an issue is the fact that LoadFrom doesn't use the default load context is in this case and what steps would you recommend to rectify it?

[AArnott]

Thank you!

I was wondering how much of an issue is the fact that LoadFrom doesn't use the default load context is in this case and what steps would you recommend to rectify it?

There are ways to rectify it (using AppDomain.AssemblyResolve event handlers) but it's very unnatural, and I don't see any problem with using the LoadFrom context in this case.

Note that some assemblies will actually load in the default context though -- assemblies that load implicitly because the ones we explicitly load reference them. Any assembly in the GAC or in the tool's own exe directory are candidates for loading automatically. That's as it should be, but just something to be aware of.

And speaking of assemblies loading implicitly, that's the next major work item to resolve in this new tool from my testing yesterday. I tried passing just one relatively simple dll from the VS installation to this tool and it failed with many assembly load errors. We need to be able to pass an .exe.config file to the tool so that it can resolve assemblies the same way a running app would. I have a (non-trivial) class that already does this for another purpose, so I'll wire it in as a switch to your tool and add to your PR.

[AArnott]

Thank you so much for this contribution.