Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Create Module Package and [App_Code] folderCreate Module Package and [App_Code] folder
Previous
 
Next
New Post
4/7/2007 12:09 AM
 

In the past I've usually packaged modules manually including creating the .dnn file. Because of the large number of controls and files in this particular module I thought I'd try the Create Module Package (in DNN v 4.4.1). The module has been developed using the WSP or dynamicaly compiled approach not WAP.

Problem - while Create Module Package did a great job in packing all of the controls, images, resourse files, etc and building a well-structured .dnn file, it fails to include any of the .vb class files in a folder under the [App_Code] directory both in not saving the files to the .zip that is created and in not creating any <file> nodes for the [App_Code] files.  This folder is properly referenced in the <codeSubDirectories> node of web.config. Even the business controller class file is left out of the package. It is properly referenced in the <businesscontroller> node of the .dnn file but not referenced in a <file> node. All class files in [App_Code] share the same namespace with the module controls.

Questions -

1. Is this normal behavior for Create Module Package to not handle any of the [App_Code] class files or am I missing some step?

2. If it is true that [App_Code] class files should be properly handled by Create Module Package, could the problem stem from my use of the following folder structure for the module: '/DesktopModules/WESNet/EPrayer' while the class files are contained in the folder 'App_Code/EPrayer'  ? Unfortunately, sub-sub folders are not permitted under the App_Code folder. The module definition uses 'WESNet/EPrayer for the folder name. This is properly recognized and referenced in the <folder> node of the created .dnn file.

 


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
4/7/2007 5:43 PM
 

A lot of upgrades to the Create module packager were made with DNN 4.5. Can you give it another try?



Michael Washington
http://ADefWebserver.com
www.ADefHelpDesk.com
A Free Open Source DotNetNuke Help Desk Module
 
New Post
4/7/2007 10:56 PM
 

After upgrading two test sites and five live sites to 4.5 today I finally had time to update version 4.4.1 (source) on my development system to 4.5.  All upgrades went without problems thus far - congratulations to all.

Unfortunately, even under version 4.5, the Create Module Package does not package vb class files located under the App_Code folder nor reference them in <file> nodes of the .dnn file. This is true even for the business controller class file  though it is properly referenced in the <businesscontrollerclass> node.  I also renamed/revised my folder structure under App_Code so that the module's codeSubDirectories directory name (in web.config) matches that given for the module name. No change in the packaging.

Also a new problem has appeared in 4.5.  All of the <path> nodes for each file referenced in the .dnn mannifest now have been given absolute paths (i.e. E:\DotNetNuke4\Website\DesktopModules\WESNet\EPrayer) rather than paths relative to DesktopModules. This is surely incorrect. The <src> nodes for each control properly contain a relative path.


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
4/9/2007 8:56 PM
 

I took a quick look at the code in DotNetNuke.Entities.Modules.PaWriter.vb to determin where in the code the failure to process vb class files in a folder under App_Code was occuring.  As I suspected, the problem stems from my mismatched folder structures being \DesktopModules\WESNet\EPrayer\ vs \App_Code\WESNet_EPrayer. In the method PaWriter.CreatePrivateAssembly, the module folder and App_Code folder are determined from the modules FolderName field as follows:

_Folder = Common.Globals.ApplicationMapPath & "\DesktopModules\" & objModule.FolderName
 _AppCodeFolder = Common.Globals.ApplicationMapPath & "\App_Code\" & objModule.FolderName

Both folder structures must match. In my case, \App_Code\WESNet\EPrayer\ did not exist so none of the vb class files were being processed. Since the web.config node <codeSubDirectories> will not accept directories more than one directory beneath App_Code, I was under the mistaken understanding that it was invalid to have a folder structure of \App_Code\WESNet\EPrayer\.  I have found that this folder structure is permitted but cannot be added as a DirectoryName to the <codeSubDirectories> node.  This should not be necessary anyway as both my module and DNN use VB. I'm not sure how one would handle it for a C# module in which case an entry in <codeSubDirectories> would be required.

After changing my App_Code folder structure to match that of the module, all vb class files were processed and added to the .zip and there corresponding <file> nodes added to the .dnn manifest.

I'm wondering if it might be well for the PaWriter to "discover" the appropriate App_Code folder based first on FolderName and then (if the path does not exist) on the ModuleName property. This possibility would, of course, have to also be accounted for when writing the .dnn manifest.

The second and major problem is that all <file><path> nodes of the manifest include the absolute path as follows for example (extra spaces added to prevent filtering out of the xml tags in this forum post:

< file >
   < path>C:\DotNetNuke4\Website\DesktopModules\WESNet\EPrayer< /path >
   < name >Settings.ascx.vb< /name >
< /file >
< file >
   < path >C:\DotNetNuke4\Website\DesktopModules\WESNet\EPrayer< /path >
   < name >Uninstall.SqlDataProvider< /name >
< /file >
< file >
   < path >[app_code]C:\DotNetNuke4\Website\App_Code\WESNet\EPrayer< /path >
   < name >CategoryInfo.vb< /name >
< /file >

This can't be correct - at least I've never seen a .dnn manifest with other than relative paths and would be expected to cause problems on installation of the module.  The PaWriter code makes not attempt to output only the relative path:

'Add the files
  For Each file As PaFileInfo In _Files
        Dim nodeFile As XmlNode = xmlManifest.CreateElement("file")
        'Add file properties
           XmlUtils.AppendElement(xmlManifest, nodeFile, "path", file.Path, False)
           XmlUtils.AppendElement(xmlManifest, nodeFile, "name", file.Name, False)

        'Add file Node to files
           nodeFiles.AppendChild(nodeFile)
  Next

I'll do some more testing, but any comments would be appreciated in the meantime.

 


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
4/9/2007 10:01 PM
 

After further study of the PaWriter code, I've found the reason for absolute paths to be written into the <path> nodes of the .dnn manifest. In the method ParseFolder we see the following (very common) technique is used to to strip out the rootpath:

Dim path As String = folder.FullName.Replace(rootPath, "")

Unfortunately, when I had created the Module Definition manually several months ago, I used a forward slash in the folder name i.e. WESNet/EPrayer rather than a back slash i.e. WESNet\EPrayer. This had never caused a problem until now and had not been converted to a back slash when the Module Definition was written to the database. As a back slash will not match a forward slash in a string replace operation, the replacement fails with the full, absolute path returned. When I've written similar code, I have usually first done a replacement of forward slashes with backslashes to avoid this problem.  Perhaps this should be logged in the support tracker as it's all to common to mix up the two slashes when entering them in a field.  Or, perhaps the Module Definition edit page should do the conversion before writing the Folder field to the database.

At any rate, when I changed my Module Definition to use a back slash, all was well. Relative paths were properly written to the .dnn manifest.


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Create Module Package and [App_Code] folderCreate Module Package and [App_Code] folder


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out