I got mojoPortal loading its content using MasterPages on Mono tonight at http://dev.mojoportal.com
On Windows it was working with AutoEventWireup=true but it was not firing the events on mono so tonight I set it to false on Windows and hooked up the events manually and it worked both on Windows and when I deployed it on mono.

Sweet! I'll merge this into the 2.0 bnranch after I get the rest of the pages and skins converted.

So the current 2.0 runtime status of mojoPortal on mono (r54948 compiled 1/1/2006) is illustrated as follows:

http://demo.mojoportal.com = 1.1 framework version

http://demo2.mojoportal.com =  2.0 framework version not using any 2.0 features  with 1 outstanding mono bug

http://dev.mojoportal.com = 2.0 framework with main pages using MasterPages

progress...

Update 1/5/2006: After another evening of struggle trying to find a way to get other pages than the main Default.aspx page to load their content I have to say something is either broken or not implemented yet in mono that is preventing the other pages from loading their content inside the ContentPlaceHolder controls within the master pages. The Default.aspx page is the main CMS page and loads its controls all dynamically based on database settings but other supporting pages have controls nested within the markup of the place holders like this:

<asp:content runat="server" id="MPContent"contentplaceholderid="mainContent">  

<asp:panel runat="server" id="pnlLogin">  

Hello World

 </asp:panel>  </asp:content>  

on windows it works but on mono you don't see the controls nested within the Content regions and if you try to access them in code you get NullReferenceExceptions

Currently on http://dev.mojoportal.com the Register page is throwing the NullReferenceException and the login page is not showing the login controls due to this. I'm going to try and produce a small test case this weekend.

Update 1/10/2006: I was able to make a little test case this past weekend with this issue on mono. The null reference exception is occuring when trying to hookup button click events and such. If you set the MasterPage for the page programmatically in OnPreInit it somehow loses its reference to controls nested within the ContentRegions on the page.

I made some progress tonight converting from Paul Wilson's MasterPages to the built in ASP.NET 2.0 MasterPages. I got the Default.aspx page converted and working on Windows, it was pretty straightforward given that Paul modelled his version from early specs for the real thing. Now it will just be a machanical repetitious task to update the remaining pages and skins, but not tonight, I'm spent.  I tested on mono at demo2.mojoportal.com, it did load the MasterPage but something went wrong loading the rest of the page content as you can see. I'll follow up with that and see if I can pin down the problem.

I've been getting very excited learning about the Web Part framework. I know I said I would pace my changes with mono support but I think what I will do is keep a separate branch in step with mono support until the mono support catches up so I can move forward taking advantage of 2.0 ASP.NET features. Some of them are just too compelling to wait and besides it will take some time to make the changes and figure out exactly how I want to do it. Right now I'm thinking the Web Part model will replace the existing implementation for Feature Modules.

I definitely will try and help implement some of the missing mono features if I can, or at least provide testing and feedback for the guys who are doing it.

I just put up some release files compiled against the 2.0 .NET framework for those eager to play in the 2.0 space.

Unfortuantely I found another bug today in the mono 2.0 runtime that I haven't been able to work around and will probably have to wait for a bug fix in mono to get it working correctly. The site does run under mono using the 2.0 runtime as you can see at http://demo2.mojoportal.com but when posting back updates on pages using a CheckBoxList like the Module Settings page and the Page Settings page, I'm seeing this error:

System.Exception: Unhandled Exception while processing NeatUpload child request ---> System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count.
Parameter name: index
2
in <0x00096> System.Collections.ArrayList:get_Item (Int32 index)
in <0x00012> System.Web.UI.WebControls.ListItemCollection:get_Item (Int32 index)
in <0x0010f> System.Web.UI.WebControls.ListControl:LoadControlState (System.Object savedState)
in <0x00141> System.Web.UI.Page:LoadPageControlState (System.Object data)
in <0x0004d> System.Web.UI.Page:LoadPageViewState ()
in <0x0012f> System.Web.UI.Page:InternalProcessRequest ()
in <0x000aa> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)--- End of inner exception stack trace ---

in <0x004a3> Brettle.Web.NeatUpload.UploadHttpModule:Application_BeginRequest (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x0046f> System.Web.HttpApplication+<RunHooks>__0:MoveNext ()

I posted to the mono dev list and will follow up when I hear something but figured I would go ahead and make the files available to those who want them.

Things are shaping up on the VS 2005/ASP.NET 2.0 branch of mojoPortal. I am shooting for a release of that branch this weekend to ring in the new year.

It seems to be working very well on Windows and on mono with a few tweaks. There is really not much holding us back from just going forward with the vs 2005/ASP.NET 2.0 version.

So now I'm trying to figure out at what point we fully transition to 2.0 and how long we keep making releases for the 1.1 framework.

Most Windows developers I know already have VS 2005 and of course those of us who have it would rather work with the new version than the old version. But I get a lot of downloads of the release files so I'm not sure its only developers I need to consider. I would love to hear feedback on that question if you have a point of view.

This decision I think will have to factor into my versioning scheme. If we are going to support 2 release branches for a while I might bump the version for the vs 2005 branch of mojoPortal to 2.0 to distinguish it clearly from the 1.x branch but if we are just going to drop development on the vs 2003/1.1 framework version I'd be more likely to version the next release 1.x and from thence forward its not for ASP.NET 1.1/vs 2003 but for vs 2005. Obviously the second choice requires less effort than maintaining 2 branches, but will anyone be left behind? Speak up if you will be negativley impacted by a quick transition to 2.0

Using the new preview of VS 2005 Web Projects which allows you to implement web projects in a way more similar to VS 2003, I was able to convert mojoPortal to VS 2005 and get it running on mono at http://demo2.mojoportal.com/

It runs great on Windows, there are still some errors on mono if you click around in the administration section but that's major progress! Now I can start figuring out exactly what is broken and see if I can't get them fixed either by reporting bugs or maybe even trying to fix it in the mono sources myself.

I've committed the vs 2005 version of mojoportal source code to svn, you can get it here:
svn+ssh://anonymous@forgesvn1.novell.com/svn/mojoportal/branches/vs2005

use anonymous for the password, you'll be prompted about 3 times on the first checkout. Its configured to use PostgreSQL, if you want to use a different db you'll have to drop the reference to the PostgreSQLData project and add a project reference to the data layer of your choice, MSSQLData or MySQLData.

Before you open it in VS 2005, make sure you have installed the new project type for VS from here: http://webproject.scottgu.com/
Configure IIS so that http://localhost/mojo2005 maps to the Web folder and build the solution

Let me know how it goes.

Joe

Update 12/26/2005:
Managed to find workarounds for most of the issues running under mono using the vs2005 branch of mojoPortal. I haven't tested everything thoroughly but mostly it is working well now at http://demo2.mojoportal.com
There is a problem with the Event Calendar but that problem also manifests under Windows so its not a mono bug but an ASP.NET 2.0 breaking change. Overall, this is very encouraging progress. There are some major issues still remaining in mono but I have found non-horrible workarounds for them at least for mojoPortal.
The 2 biggest problems were

1. System.NotImplemented exceptions when data binding a DropDownList or anything that inherits from ListControl. I worked around this by creating a helper function to add ListItems instead of calling the built in DataBind()
2. System.NotImplemented exceptions anywhere a DataSet is used, it would break at System.Data.Common.DbDataAdapter:Fill. This is probably a big problem for a lot of projects but in mojoPortal I mostly use IDataReader so there were only a few places I was using DataSets and all I really needed was a DataTable so I created and populated one using an IDataReader instead of letting it come from a DataSet

I've commited the workarounds on the vs2005 branch for anyone who wants to play on the cutting edge. To make mod_mono use the 2.0 stuff see my tutorial on Virtual Host configuration, especially the part about the MonoServerPath setting. Of course those working on Windows have surely discovered the new ASP.NET tab in IIS settings where you can choose either the 1.1 or 2.0 framework