Prior to coding modules for DNN I never used ArrayLists for DataGrid databinding. So that's when I ran into the 'no default member found for type' runtime error when trying to code a template column. As you know, when you bind to a DataSet and you need a field from the current record you use 'Container.DataItem('FieldName')'. I thought that in the DNN world with ArrayLists of Info objects the same would work but it does not. Turns out that Container.DataItem returns the object so you need to specify the property if there is no default one. For my http://www.ammotracker.com site I use it as follows:

<asp:TemplateColumn headertext="Gun"%>
<ItemTemplate%>
<asp:Label runat="server"%> <%# GetGunForSession(Container.dataitem().GT_OwnerGuns_ID) %></asp:Label%>
</ItemTemplate%>
</asp:TemplateColumn%>

Enjoy!

If you develop modules for DotNetNuke you are probably aware of Speerio's My Modules . This is a great package but for me the problem was the I could no longer debug properly with it. The issue was that objects in the watch window would no longer expand when clicking on the 'plus sign' to the left of it. I contacted Nik and he said I was the first one to run into this and suggested a few things I could try. None worked. Oddly I was seeing the same behavior at home and at work, both DNN 3.0.13 installs but with different custom modules.

I did some Googling but the problem was finding the right search term. Eventually I used VS.NET watch window problem "plus sign"  and that brought me here: http://www.dotnet247.com/247reference/msgs/37/185102.aspx . I added a new AssemblyInfo.vb file to the _DDNStub project. This resulted in a number of compilation errors. These can apparently safely be ignored but it's annoying so I removed the offending imports from the _DDNStub project. This didn't seem to have any adverse effects and the solution compiles fine now.

Bottom line:

Pros: I can now effectively debug my DNN modules without the overhead of checking all DNN modules. This is the big plus of My Modules over the standard DNN solution.
Cons: there is an additional DNNStub.dll assembly that gets generated as part of the solution. Given how hulking big DNN already is this isn't a problem for me (debug size is 6 KB).

As I'm the only one with this problem and the solution isn't particularly neat (see Cons) Nik didn't want to include this tip in his release package. I hope that Google will find this article for the next person who runs into this issue.

If someone has a better solution that doesnt' require DNNStub to be compiled I'd like to hear about it, please.

In closing I want to thank Nik for also providing the DNNDebug.aspx page which has indeed already saved me a lot of time figuring out an ascx problem. To use it simply navigate to <DNNSITE>/DNNDebug.aspx and follow the instructions.