Closed kcragin closed 8 years ago
Sounds like a reasonable idea. Where would you like to see this filtering specified? e.g. in web.config?
Feel free to drive the change and send a PR :)
I've forked the repo and started some code. I'm thinking it will have to come from web.config as the ASP.NET infrastructure calls into WebActivator very early on in the processing. Even then, the web app is not even instantiated before WebActivator. Do you have any suggestions?
I just checked, and calling System.Configuration.ConfigurationManager.AppSettings
from the beginning of ActivationManager.Run
works fine. We could go with a simple design of having a single appsetting that has a comma separated list of file names in bin. Or if you want to go fancier, you can have a custom config section, but that's more work.
So are you thinking more about an exclusion list than an inclusion list? I think that would make sense. i.e. load all except those few. e.g.
<appSettings>
<add key="webactivator:excludedAssemblies" value="System.Web.Mvc,Foo"/>
</appSettings>
Exclusion. I like the simplicity of what you propose, but I need a bit more. Perhaps we keep what you have and allow this as well:
<add key="webactivator:excludedFilesExpression" value="System\..*"/>
I want to filter at the file-level first. In my case, there are a number of legacy unmanaged DLLs that I want to skip scanning, not to mention dozens of third-party assemblies.
When I first approached this my thought was to pass WebActivator a Func<Assembly, bool>
predicate (not knowing at the time imperative code wouldn't have worked). In my predicate I had planned to use regexes anyway.
It only loads files that are directly in the bin folder, so I don't think we need any folder specification. I would think that a simple list of file names (with RegEx) would do.
Fixed per #29
The list of files WebActivator scans is private and there is no way to filter them. Filtering would be useful; the most obvious case is to improve startup performance of the web app by filtering out assemblies known to be irrelevant and dlls known to be unmanaged dlls.