Silverlight limitations on reflection
In Silverlight, reflection is subject to many restrictions. The maximum two restrictions are:
- Only public members can be accessed through reflection, and other Members (private, protected, internal) cannot be accessed: there is no good solution for the moment.
- Unable to obtainProgramReference Information of the set: Fortunately, mono. Cecil can bypass Silverlight's reflection restrictions through mono. Cecil to obtain reference information of the program and.
Silverlight limitations on Dynamic Loading
Silverlight has poor support for the dynamic loading mechanism, mainly manifested in:
- Developers need to implement the built-in dynamic assembly loading solution. Of course, it is easy to load an assembly from the server, but there is no good way to obtain the program and reference information, other Assembly referenced by the Assembly cannot be automatically loaded;
- The dynamically loaded assembly cannot be added to the current Silverlight deployment Assembly Cache (deployment. Current. Parts). Developers must cache the loaded programs and programs themselves;
- Appdomain. Current cannot add Dynamically Loaded assembly information.
Restrictions on the built-in Silverlight navigation mechanism
Silverlight has a built-in navigation mechanism that can be seamlessly integrated with the browser navigation bar, but there are also many restrictions, such:
- The navigation address must be the XAML file corresponding to the user control or page, rather than other user controls;
- Due to Silverlight's limitations on reflection and dynamic loading, the built-in navigation mechanism cannot automatically load controls in the Dynamically Loaded assembly;
However, the built-in navigation can be completed by implementing the inavigationcontentloader interface. The frame control has a contentloader attribute. The default value of this attribute is pageresourcecontentloader.
Ideal solution
The ideal solution is to combine the navigation mechanism with the dynamic loading assembly. The goals to be achieved are as follows:
- The Silverlight assembly is not packaged and directly copied to the clientbin directory. Of course, the main assembly must be packaged; otherwise, the client Silverlight cannot be loaded and loaded;
- Based on the user's choice, the corresponding assembly is loaded from the server on demand, and the referenced assembly is automatically analyzed and loaded from the server;
- Extends the built-in navigation mechanism so that it can load Dynamically Loaded assembly.
I believe many people have already understood this solution and even have a clear idea to implement it. In the next blog, I will post my implementation, I hope you will continue to pay attention to it.
