One of my biggest frustrations with using most APIs is that the use cases and/or user stories for the API are not documented anywhere. While the .NET Framework Design Guidelines preaches Scenario-Driven Design, MSDN typically does not explain real-world scenarios. If they provide programming examples, it is entirely explained in terms of functionality and not tied to anything practical.
The notion of an AssemblyPart has been in Silverlight since version 3, and I don't even understand why it is there.
I tried searching for code online that demonstrated practical utility of making an Assembly support dependency propagation, but I don't see any. AssemblyPart inherits Dispatcher dependency property and adds a Source (Uri backed) dependency property, but there is no rationale given as to why these must be dependency properties. Why would I ever want to update the value of Source
I also don't like the Responsibility definition MSDN provides for AssemblyPart: "An assembly part is an assembly that is to be included in a Silverlight-based application package (.xap)." To me, that seems gross.
Moreover, AssemblyPart.Load() is identified by Nick Kramer and the Silverlight Security Team as a potential XSS vulnerability: You can't tell just from passing in the string to Load() that AssemblyPart will securely retrieve the assembly for you, since you are responsible for giving it the Stream. Moreover, as I mentioned above, you can't enforce that the Source property should never change. Once I define an AssemblyPart, why on earth would I want to redefine any of its properties? Shouldn't it be immutable? Peering at the Mono source code, all that happens is it loads the Assembly into memory and adds it to the Deployment's Current Assemblies.
In addition, all samples I've seen show the programmer doing something to the user interface immediately after the assembly loads, rather than separating assembly resource acquisition from assembly resource usage - the idea of prefetching an assembly is never considered. Wintellect's Jeff Prosise covers some of the issues with loading remote assemblies in a blog post on how to recapture static typing and avoid reflection, but he doesn't provide a full abstraction for dynamically linking code. Rob Tuit came up with some solution, but it is not ideal.
I guess, given all this, would I be better off asking, does anybody here actually understand why AssemblyPart is the way it is, and if so, why?