Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer an API to remove parts from ComposableCatalog #73

Open
AArnott opened this issue Mar 28, 2018 · 4 comments
Open

Offer an API to remove parts from ComposableCatalog #73

AArnott opened this issue Mar 28, 2018 · 4 comments

Comments

@AArnott
Copy link
Member

AArnott commented Mar 28, 2018

Although the workaround exists where a new ComposableCatalog can be created with a subset of the parts from a prior catalog, it would be more convenient if a method were offered that returns a new catalog with the parts removed.

Potentially the removal criteria could be based on part type or export.

@znakeeye
Copy link

znakeeye commented Aug 14, 2019

What does the workaround look like? 😛

Looks like reflection is needed?

@AArnott
Copy link
Member Author

AArnott commented Aug 14, 2019

If you wanted to include all parts from the assembly containing the Main class, except that you wanted to substitute the IFoo export with one from your tests, you could create the catalog like this:

var discovery = new AttributedPartDiscovery(Resolver.DefaultInstance);
DiscoveredParts discoveredParts = await discovery.CreatePartsAsync(typeof(Main).Assembly);
var parts = discoveredParts.Parts.Where(p => !p.ExportDefinitions.Any(ed => ed.Value.ContractName == typeof(IFoo).FullName));
var catalog = ComposableCatalog.Create(Resolver.DefaultInstance)
    .AddParts(parts)
    .AddPart(discovery.CreatePart(typeof(MockFoo)));

@znakeeye
Copy link

znakeeye commented Aug 14, 2019

Thanks. That will work for regular types.

Why not make the ContractNameServices class public? That way you can use internal naming conventions whenever you run into hacky string comparisons as shown above.

Also, would you prefer checking ExportDefinitions or ExportedTypes?

@AArnott
Copy link
Member Author

AArnott commented Aug 14, 2019

ExportDefinitions will allow you to remove the export whether you export from the type or a member, so it's more general and doesn't depend on the implementation detail within your application.

Regarding ContractNameServices, we could make that public. Can you open a separate issue for that?

@AArnott AArnott closed this as completed in 641eaa1 Jun 7, 2022
@AArnott AArnott reopened this Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants