Skip to content

DefaultLoader.SearchForStartupAttribute get all assembly attribute instances during initialization #278

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

Closed
jinek opened this issue Mar 20, 2019 · 6 comments
Labels
3 - Done enhancement up-for-grabs We will consider contributions
Milestone

Comments

@jinek
Copy link
Contributor

jinek commented Mar 20, 2019

Method DefaultLoader.SearchForStartupAttribute executes
customAttributes = referencedAssembly.GetCustomAttributes(false);
Which means instantiating of all assembly attributes (that is not necessary and can bring problems)
Can be replaced by
customAttributes = referencedAssembly.GetCustomAttributes<OwinStartupAttribute>(false);
or similar.

@Tratcher Tratcher added up-for-grabs We will consider contributions enhancement labels Mar 20, 2019
@Tratcher
Copy link
Member

Feel free to send a PR.

@jinek
Copy link
Contributor Author

jinek commented Mar 20, 2019

I see you did it for some reason 6 years ago, you also introduced
Owin.Loader.Tests.OwinStartupAttribute with a comment // Alternate definition, used to confirm that there is not a direct type dependency.
But I can't find the reason, do we still want to be independent from type Microsoft.Owin.OwinStartupAttribute ?
Here: 9a14082

Because logic here seems strange for me: if I introduced my own attribute with name OwinStartupAttribute it will work as a startup attribute.

@Tratcher
Copy link
Member

I'd forgotten about that. Yes it was intentionally type decoupled but I don't remember the reasoning. Best not to break that at this point though.

What was your issue with loading the attributes?

@jinek
Copy link
Contributor Author

jinek commented Mar 20, 2019

That is fine, this still can be used: https://docs.microsoft.com/en-us/dotnet/api/System.Reflection.Assembly.GetCustomAttributesData?view=netframework-4.5
It should not break anything and won't instantiate all attributes.

My issue was that one assembly happened to be in bin folder does not have all dependencies, some of them were referenced in assembly level attributes. Thus trying to instantiate such an attribute will lead to AssemblyLoadException.

jinek added a commit to jinek/AspNetKatana that referenced this issue Mar 20, 2019
jinek added a commit to jinek/AspNetKatana that referenced this issue Mar 21, 2019
jinek added a commit to jinek/AspNetKatana that referenced this issue Mar 26, 2019
@Tratcher Tratcher added this to the 4.0.2 milestone Jun 26, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Jan 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
3 - Done enhancement up-for-grabs We will consider contributions
Projects
None yet
Development

No branches or pull requests

2 participants