DNN Version 5.2.x changes how you create new modules. From the modules screen, scroll down to the bottom and click the 'create new module' link (this link may appear in additional locations on the form as well). Choose 'from manifest'. Leave the owner folder blank. Change the module folder to your folder (the dropdown is prepopulated for you). You .dnn file should appear automatically in the text box. Submit the form and continue with the next steps, which deal with running the SQL script.

Here is a link to the version's feature change.

http://www.dotnetnuke.com/Community/...-Released.aspx

I'm relatively new to dnn and am finding out that you have to hunt to get any detail on these types of things. The dnn site does not post a lot of documentation.

You want it to be ..\..\bin, this will ensure that it goes out to the root, then into the \bin folder within DNN. If it was set to \bin, your dll would go in \DesktopModules\YourModule\Bin, where DNN would not pick it up.

The value here should match what your DLL name is when it is compiled. This is so that DNN can copy and retain information on the dll. If the dll listed is not found, it will fail to install the module.

Thanks for this, I'll try to get with Wrox to see about getting a notice of the typo.

Either way it works, I apologize for the inconsistency in the book examples. (I still flip flop on it daily with most of my projects......)

I do not believe that the file names are case sensitive, but I'll be honest, I have not tested that, but it shouldn't be as by default windows is NOT case sensitive.

Yes, the moduleControls element is the root node that contains the children control elements. For full validation of this, you can use Appendix D to confirm any semantics of the manifest.

Yes, you are correct, you can do "Build -> Build GuestbookVB", or if you like keyboard shortcuts you can do CTRL+SHIFT+b to do a build as well.

If everything worked correctly you will find the DLL in the DNN bin folder, there will also be copies inside of the /obj folder that is created within your module.

You only need the \bin folder when you go to package, that is it. You COULD create it in the module folder, but it is not needed.

__________________
Mitchel Sellers
Microsoft C# MVP, MCITP
Director of Development
IowaComputerGurus Inc.

My blog for .NET and DotNetNuke info

Author of "Professional DotNetNuke Module Programming"

Tech Editor on "Visual Studio 2010 six-in-one" and "Pro C# 4.0"

Wayne,

Follow this process to import in 5.2.x.

1. Host => Module Definitions
2. From dropdown menu, 'Create New Module'
3. Create Module From: Manifest
4. Owner Folder: <Not Specified>
5. Module Folder: GuestbookVB
6. Resource: GuestbookVB.dnn
7. Add Test Page? Unchecked
8. CLICK Create Module

I'm blogging about this now.

__________________
Mitchel Sellers
Microsoft C# MVP, MCITP
Director of Development
IowaComputerGurus Inc.

My blog for .NET and DotNetNuke info

Author of "Professional DotNetNuke Module Programming"

Tech Editor on "Visual Studio 2010 six-in-one" and "Pro C# 4.0"

Thanks Mitch, you should become a prof :)

If you are contacting Wrox about the typo, consider adding all 3 of these things to the list.


The typo on page 71

Page 70 - removing the period from <name>Wrox.Modules.GuestbookCS.dll<name> so it becomes [<name>WroxModules.GuestbookCS.dll<name> (and matches the actual file)

Page 143, Listing 8-20 - Wrap the group of child <moduleControl> elements with a <moduleControls> parent.

I finally figured out my problem. (When creating the module, I submitted the form, and the screen did a quick postback but didn't change anything. No errors, logs, etc... But the module was created and I could see it in my listing. However it didn't actually work.)

I examined my module's settings (in my DNN website). I noticed that all of the fields from my .dnn manifest were showing up on the settings creen until I got to the Business Controller Class element. After reviewing my dnn file, I saw I spelled "Business" wrong.

Apparently the Create Module Definition parses the .dnn file from top to bottom and there isn't any (or enough) error trapping during this process to handle an invalid element and display the information on the user's screen. Instead, it reloads the 'create module definition' form without displaying any sign of success or failure.

From a developer standpoint, a schema file would also help catch these problems during the coding.

I have some notes and a question on Appendix D.

Listing D-1, page 271: version should be 5.0 (not 4.0). The paragraph below it emphasizes using 4.0.

Listing D-2, page 272: <vendor></vendor> should be <owner></owner> I tried using the vendor type and it didn't show up on the settings page after creating the module definition. Also, the "version" attribute format is different than what's used in the exersize.

Question on page 278: When do you specify the <businessControllerClass> in the dnn file? In what cases should you leave it blank, and when should you fill it in?

Argh, that's right, those are part of my changes that I need to get off to Wrox, they made a few last minute changes with 5.x

The businessControllerClass should only be specified if you are implementing an interface such as IPortable or ISearchable.

__________________
Mitchel Sellers
Microsoft C# MVP, MCITP
Director of Development
IowaComputerGurus Inc.

My blog for .NET and DotNetNuke info

Author of "Professional DotNetNuke Module Programming"

Tech Editor on "Visual Studio 2010 six-in-one" and "Pro C# 4.0"