Since Microsoft has released Visual Studio 2008 and the .NET framework 3.5, I like most passionate geek developers could not wait to try it out. I was under the impression that projects and solutions from VS 2005 would be compatible so I figured great I can benefit from the new javascript debugging features and over time tiptoe into using Silverlight and some other new things in the 3.5 framework.

However, when I tried to open the mojoPortal solution in VS 2008 the first thing that happens is the project conversion wizard starts, so apparently the projects and solutions are not backward compatible. I of course immediately cancelled the operation because it said the projects and solution would no longer work with VS 2005 so if I do this that means that no-one can work with the solution unless they have VS 2008.

So we face a hurdle for the project that I'm sure other open source .NET projects will also face. Obviously at some point we must move forward but the question is how long should we wait?

I invite your feedback if you are actively using mojoPortal in your development, how soon will you be getting VS 2008? How long do you think we should wait before making the change and leaving behind VS 2005?

UPDATE: I stand happily corrected!

Thanks to the readers who pointed out that only the solution files changed. This is great news! I'm in the process now of making bakup solution files for VS 2005 and upgrading the solutions for VS 2008. Should have this in svn trunk in the next few hours.

Note for those who don't have VS 2008 you will need to use the alternte solution files which have been renamed like mojoportal-complete-vs2005.sln
mojoportal-core-vs2005.sln
... etc

This means that those of us with VS 2008 can move forward without leaving behind the VS 2005 developers. Though at some point we will need to make the decision to target the 3.5 framework instead of the 2.0 framework I think we can potentially add projects to the solution that do target 3.5, we just can't change the target on projects that are shared in he VS 2005 solution files.

Happy Day! Go get your free 90 day trial of VS 2008 or if you are an msdn subscriber you can get it there.

Hey mojoPortal community, as you can imagine it takes a lot of work to keep the mojoPortal project moving and I can't do everything myself so I thought I would mention something I could use some help with in case anyone out there has the time and interest.

This request is especially directed at those who are using mojoPortal on Linux with Mono. The Mono project is getting ready for the 1.2.6 release and needs people to help test the release before they ship it. mojoPortal being a complex application is a good thing to test to make sure there aren't major regressions in Mono. I may test it myself but I am pretty swamped and not sure I will get to it in time so if anyone else could help it would be great and would help ensure that mojoPortal works with the next Mono release.

Please, if you can test the mojoPortal 2.2.3.6 release using the Mono pre-release from here:

http://mono.ximian.com/monobuild/preview/download-preview/

Your help would be a great contribution to both mojoPortal and Mono

Thanks,

Joe

Just a quick heads up to users of mojoPortal who may have custom features that use the mojoPortal.Controls.DatePicker

In order to make it possible to use different date pickers in mojoPortal I have now implemented a provider model and now the control is just a wrapper around a provider specific control.

I had to rename the control becuase of a namespace clash when I built the provider model under the namespace mojoPortal.Controls.DatePicker I got an error because you can't have a class named DatePicker and namespace named DatePicker.

Renaming the control is a breaking change but is easy to fix. The new control class name is DatePickerControl instead of DatePicker so anywhere you have used DatePicker you will need to change it to DatePickerControl.

For example <mp:DatePicker... becomes <mp:DatePickerControl...

I have fixed these in all the projects included in mojoportal-complete.sln and will be committing this change to trunk tonight.

Those of you who have custom projects using this control will need to change your code after you get this update. If you have any trouble post in the Developer Forum and I'll try to help.

We've used a .NET control that wraps the jsCalendar javscript date picker for a long time but there are other nice ones available now. Specifically I plan to implement one using the ExtJs toolkit but needed to get this provider model in place first.

As I mentioned in my previous post, I've started implementing some .NET wrapper controls around the ExtJs javascript toolkit to make it easy to use in ASP.NET and especially in mojoPortal.

So far I've implemented ExtPanel, TabPanel, Tab, SplitPanel, and Viewport server controls. I just updated this site  with my latest code and created a ExtJs Complex Layout Demo page using my controls. I spent some hours thrashing before I got it working but its very fun implementing these widgets once you do get them working it seems like magic. The layout possibilities are just awesome. I love the way you can collapse any panel to hide it and can resize them by dragging the borders.

Of course I'm sure I will continue improving these controls and will undoubtedly find bugs when I start trying to use them for real applications but they will get polished up as I use them for real features. I'm just trying to get some useful baseline proof of concept implementations working now.

I found a .NET project for ExtJS this morning but it depends on the MS AJAX framework. Although we can use the MS AJAX framework in mojoPortal, I'm choosing to implement mine without that dependency. I'm also choosing not to embed the javascript in the dll but instead just have a setting to the base path for the ext javascript files. I do see the convenience of embedding but I also see that putting a lot of javascript inside a dll increases its size and dlls have to be loaded into memory on the server which is probably not a problem on beefy machines but in shared hosting with limited resources its more optimal in my opinion not to have it in the dll.

I'll be posting more demo pages as I complete the wrappers for more ExtJs widgets.

Those of you who subscribe to svn commit notification may have noticed the new Survey feature by Rob Henry landing in there recently. Rob has been working on this feature for a while and the feature is ready for some testing and feedback so that he can put the final polish on it. You can test using his demo site at http://www.justsome.net/surveydemo/

You can login using admin@admin.com and password admin

The feature allows creation of complex multi page surveys and supports a variety of question formats. Currently its only implemented in MS SQL but we plan to add the other data layers after its finished.

Those working with svn trunk can just do svn update, rebuild the mojoportal-survey.sln or mojoportal-complete.sln in VS and then visit the siteroot/Setup/Default.aspx page and the feature will install automatically.

Post any feedback in the Developer Forums

Thanks Rob for your work on this! It will be a valuable feature for the mojoPortal community.