Creating Assembly Plugins via Reflection
advTHANKSance
Creating Assembly Plugins via Reflection
Hot Topic
- How to start workflow, designed in Sharepoint Designer, by adding/changing folder (not document)?
- Problems with Office SharePoint Server Search, SharePoint Services Search and SharePoint Services Application services starting
- Modify Navigation Error
- DOM Reference
- SHAREPOINT INSTALLATION ISSUE
- Cell Formatting Task Pane
- Message visualizer
- User Interface Oriented Application Development
- CSF vs. WCF ("Indigo")
- Re-Parenting
SharePoint Products
- Data Access Architecture
- Any News on the new bits ?
- Any good Ntier real world (architecture)examples available for download?
- critique requested on thin Data Access Layer
- A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site a
- SOA - Transaction/compensation/cordination
- Any way to retrieve original SOAP action?
- use of snk file
- When and Where to use Interface
- Design Question about an "actor" in a use case
advTHANKSance
Creating Assembly Plugins via Reflection
EvilOneSD
Here's a few pointers based on plugin experience
1. If possible avoid iterating through all the types in your assembly to find the one's you want (foreach on Type.GetMethods()).
2. If you are constructing many instances for your plugin classes over and over again, then save ConstructorInfo references and use those to activate rather than just Activator.CreateInstance. This will save on the hit of matching the signature.
3. Load when you need to. If you load all your classes at initialization time this can have a signficant hit. Instead you can load assemblies the first time they are needed. Keep a string dictionary / generic hashtable of what has been loaded. This will be less costly then having to use reflection to see if the assembly is loaded.
4. If you are iterating through many assemblies to search for classes to load, then create a seperate AppDomain to do the searching. Build a list of all the assemblies you've found that you need to load, and then unload the AppDomain. Next load the assemblies in your list into your main AppDomain.
5. Look at the inner exception during invocation exceptions. Whenever you get an exception via an invocation the outer exception is a generic TargetInvocationException, look in at the inner exception to find what happened. When constructing your objects, use a try-catch and log the inner exception.
6. USE LOGGING. It's critical to have a log that you can use to trace the execution while your assemblies are loaded, etc. Set logging at different log-levels so you can turn up or down the detail in production environments.
7. Use Exception handling. Create your own friendly verbose exception wrappers for things like LoadAssemblyException, PluginNotFoundException etc and give contextual meaningful messages when they occur. For example give in the message the pathname of the assembly that you were looking for. The more information the better. Although this is a general practice, it's really important with plugins.
Check here for more detailed guidelines.