While experimenting with creating DNN 5 module packages to include the new v 5.0 package manifest (Host-->Module Definitions-->Create Package), I have found that when creating a package for a dynamically-compiled (WSP) module the files located in App_Code/<ModuleFolderName> are NOT being included in the zip archive that is produced. Here are the steps to reproduce the issue and what I have discovered so far . . .
1. Start with a new or installed (using v 3.0 manifest) dynamically-compiled (WSP) module with code files located in App_Code/<ModuleFolderName> then attempt to use Host --> Module Definitions --> Create Package with "Use Existing Manifest" not checked.
2. Step 1 of the Create Package wizzard properly identifies the module as dynamically-compiled and displays all the files in the App_Code/<ModuleFolderName> folder with each filename having the prefix "[app_code]".
3. The v 5.0 manifest appears to be correctly built to include the correct <codeSubDirectory> node and a file installer component for the App_Code files. Here is that segment of the created manifest:
<component type="File">
<files>
<basePath>App_Code\WESNet_ContentDejour</basePath>
<file>
<name>categoryinfo.vb</name>
</file>
<file>
<name>configuration.vb</name>
</file>
<file>
<name>contentdejourcontroller.vb</name>
</file>
. . .
<file>
<name>utilities.vb</name>
</file>
</files>
</component>
4. In the above, the <basePath> is correcly written. However, there is no <path>[app_code]</path> subnode written within each <file> node. As I have not seen a properly constructed v 5.0 manifest for a WSP module, I am not sure if there should or should not be <path>[app_code]</path> subnodes for each file.
5. The zip archive is then created to include the v 5.0 manifest and all files EXCEPT those in the App_Code folder.
6. In starting to debug the DNN 5 RC2 source code last evening, the failure to properly process the App_Code folder files occurs when the newly-created v 5.0 manifest is read and an instance of a the FileInsatller class is created to process this <component> node. While the <basePath> node is read, its value is never used during the following ProcessFiles operation. Since there is no <path>[app_code]</path> sub node within each <file> node, the file installer does not recognize that the files are of InstallFileType.AppCode instead assigning them as InstallFileType.Other.
7. When I add the App_Code files manually to the created package, a later install of the package is successful. In that case, the <basePath> node value is used to recognize that the files should be installed in the App_Code/<ModuleFolderName> folder even though there are no <path>[app_code]</path> subnodes in the manifest.
I have not entered this as a Gemini issue as I first wanted feedback on
1. Has this behavior been noted previously and an issue already created? A Gemini search did not show an already entered isuue but I might have missed it.
2. Should each <file> node in the created manifest segment include a <path>[app_code]</path> subnode? It would seem that the <basePath> node value should be used to determine that these are code files and that <path> subnodes would be redundant.