Manually specifying which projects are XAP modules
This document describes steps required for customizing the migration of a project using PRISM and XAP module loading
Classifying projects manually
Currently the main challenge with this approach is how to identify projects that will be loaded dynamically.
We can use a heuristic like:
A module project is Silverlight application project that references PRISM (MIcrosoft.Practices.Prism) and does not have a SilverlightAppEntry .
However, this is not 100% accurate. There may be several scenarios like:
A project that has a "SilverlightAppEntry" referencing a class that doesn't exist.
A project that has a "SilverlightAppEntry" referencing a class that doesn't exist.
A project that is both an application and a module.
Also, Silverlight application projects that are used as XAP modules (not actual applications) need to be processed by the conversion tool in a peculiar way. In summary the conversion tool tries to identify Silverlight application projects used as XAP modules by using this meets the criteria:
The project is a Silverlight Application project.
The project references PRISM.
The project does not have a Startup object.
These criteria help identifying some scenarios; however, it is possible that some projects to be converted need to be treated as XAP modules. The user can:
User a project as a XAP module or as a test application.
The project may specify an empty or non-existing class for a startup.
For these scenarios, the user can specify which Silverlight Application project must be converted as XAP modules.
Specifying which application projects are XAP modules
The projects that will be forced to be converted as XAP files can be specified using the conversion tool extended settings file:
This configuration file can be specified in the command line of the conversion tool as:
Last updated
Was this helpful?