I'm happy to announce the release of mojoPortal 2.3.4.4, available now on our download page.

What's New?

• This is the first release where we have separate release packages for .NET 3.5 and .NET 4.0.
• New Facebook like button available in the Blog and in the HTML feature. This makes it easy for people to "Like" pages on your site on Facebook.
• Upgrade from TinyMCE 3.2.7 to 3.3.6
• Upgrade from CKeditor 3.2.1 to 3.3
• Upgrade to the latest version of NeatUpload
• We removed 7 skins from the main release packages to reduce the file size of the main packages and made them available in a separate download extra-skins.zip. Don't worry there are still a lot of skins included in the main packages.
• Various bug fixes and enhancements for things reported or requested in the forums.

There are also corresponding releases of Form Wizard Pro and Event Calendar Pro. Users who have purchased these add-on products should upgrade them at the same time or right after upgrading mojoPortal.

Form Wizard Pro 0.0.1.7

• compatibility updates for mojoPortal 2.3.4.4
• includes a build for both .NET 3.5 and .NET 4.0
• fixed bug where an incorrect redirect would happen after importing a form definition if the site was running in a virtual directory instead of a root site
• added option to use regular expression validation of date questions
• added a setting for a custom CSS class so forms can be styled differently

Event Calendar Pro 0.0.2.8

• compatibility update for mojoPortal 2.3.4.4
• includes a build for .NET 3.5 and .NET 4.0

Follow us on twitter or become a fan on Facebook

This post will outline the transition plan for moving forward with .NET 4.0 in mojoPortal while still maintaining support for .NET 3.5 and how this plan will impact developers working with the mojoPortal source code.

Beginning with the coming release, we will be making a separate set of compiled deployment packages for .NET 3.5 and for .NET 4.  For those who are not working with the mojoPortal source code, you don't need to read the rest of the post, the only part you really need to know is that when you upgrade to the next and future versions of mojoPortal you need to choose the correct download package for your hosting environment. If you are hosted in 3.5 .NET you will need to choose the appropriate package for 3.5 and if you are hosted in .NET 4 you will want the package for .NET 4.

Transition Duration

We will continue to produce deployment packages for .NET 3.5 for at least the next year and possibly longer depending on community feedback.

What Changes Will Be Required?

The target framework is a project level setting, so we will be changing the 3 web UI projects (mojoPortal.Web.csproj, mojoPortal.Features.UI.csproj, and WebStore.UI.csproj) to have a target of .NET 4. To the extent possible we will try to keep the target for all other supporting projects as 3.5 during the transition period.

To make it possible to be able to produce a build for 3.5 .NET I have made copies of the above project files and named them as mojoPortal.Web.net35.csproj, mojoPortal.Features.UI.net35.csproj, and WebStore.UI.net35.csproj and I have set them up in a separate set of solution files.  

mojoportal.net35.sln is the complete solution configured for .NET 3.5.
mojoportal.core.net35.sln is just the core without all the features like blog, forums and WebStore etc.
mojoportal.mssqlonly.net35.sln is the full set of features but leaving out the data projects for alternate databases.

The main solutions which will be used for .NET 4 development have the same name except for the .net35 segment.

The new projects for .NET 3.5 are already available in the repository, but I have not yet changed the target on the main projects to 4.0, this will probably be done tomorrow. I did a test conversion on a copy already to make sure I will have no problems with the conversion.

We also have mojoportal.mono.sln which is for use in MonoDevelop on Linux.

How Will This Impact Developers?

For some developers this will be great because they are wanting to use .NET 4 and the main solution and project files will be setup for .NET 4 development.

Developers who need to continue working with .NET 3.5 for their own custom features will need to remove the 4.0 version projects and add the new net35 projects in their custom solution files and then may need to re-create project references to the new projects since references may be lost when the projects are removed.

There will also be one other inconvenience for those who need to stay on .NET 3.5 development. When we convert the main Web project to .NET 4 it will change the Web.config file to be compatible with .NET 4 and it will no longer be compatible with .NET 3.5. I have created an alternate Web.net35.config file, so you will have to copy the contents of that file into the Web.config file after getting the code. To avoid merge conflicts when getting code updates from the Mercurial repository, you may also need to revert the Web.config file before getting updates from the repository and then change it back again afterwards. 

Since the 4.0 and 3.5 versions of the projects will share the same files, I have added a conditional compilation symbol NET35 on the 3.5 versions of the projects. So in code that uses new properties or methods available only in .NET 4 we will have to wrap the code with checks for the conditional symbol like this:

#if !NET35

// some .NET 4 specific code

#else

//some alternate .NET 3.5 code if needed

#endif

This way when we compile the 3.5 versions it will leave out the 4.0 only stuff.

Of course this means that whenever I add a new file to one of the 4.0 projects I have to remember to also add the file in the 3.5 version of the project, so there will be some extra tedium for me also during this transition period. Once the transition period is over and we feel it is safe to drop support for .NET 3.5, then we will remove the extra project and solution files and we will then be able to change the target on all the projects in the solution to .NET 4. There may be a few bumps along the way in a transition such as this, it is similar to what we went through in the transition from 1.1 .NET to 2.0 back around 2005.

So that is the go forward plan that will allow us to begin using some .NET 4 features while maintaining the ability to produce builds for 3.5 .NET for at least the next year. If anyone has any concerns or opinions or other feedback about this plan, please post in the comments. The main projects will be converted to .NET 4 possibly as soon as tomorrow. If that worriess you, you might want to go ahead and get a fresh update from the repository today.

UPDATE 2010-05-24: I've completed the conversion of the main projects to 4.0 .NET in the repository and verified that it is still very easy to make a build for 3.5 .NET.

www.mojoportal.com has been running on .NET 4 for several days now and all seems well. I did encounter a few little menu rendering issues at first but was able to solve them in code (already updated in the repository). So far the only significant issue I've found is that under .NET 4 Medium Trust configuration we get errors on any page that has NeatUpload on it. I've passed the information about the error on to Dean Brettle, the developer of NeatUpload so hopefully it can be resolved soon. In the mean time I would not recommend using mojoPortal under .NET 4 with medium trust. It does works fine in Full Trust and hopefully the Medium Trust issue can be solved in the near future.

UPDATE 2010-05-25: Thanks to assistance from Dean Brettle, the latest version of mojoPortal in the repository now works with no errors under .NET 4 Medium Trust.

Follow us on twitter or become a fan on Facebook

Hi All,

This is a heads up to anyone working from our svn repository. Yesterday afternoon as I tried to do an svn commit I got an error that it could not connect to the server. I figured it was a temporary issue but it was down still this morning so I did a quick google for "novell forge svn is down" and what I found totally caught me off guard. Apparently the service is shut down completely and I was never notified it was coming and did not see the announcement about it. So I had no time to prepare and migrate to another project hosting. Of course I still have the latest version of the code on my machine but all the history of changes is lost as far as I know.

It sure would have been nice if this had been communicated through more channels like an email to project administrators or to the novell forge mailing list.

So, today I have to figure out the go forward plan and execute it as quickly as possible so I can get back to normal development tasks.

The 2 viable choices as I see them are either hosting the code at SourceForge where we can continue using svn and TortoiseSVN for all source control operations or hosting the code at Codeplex. The advantage of Codeplex would be that source code activities would now be captured as project activity and possibly help us get recognized on Codeplex as being a very active project whereas in the past we never got on the list of most active projects partly because they had no tracking of our source code activity when we were hosted on Novell Forge. The downside would be that we would no longer be able to do all source control operations with TortoiseSVN. There is an svn bridge built into the Codeplex service so it would still be possible to do svn checkout and svn update and probably commit would also work, but it does not support merge which is a very important function when you maintain different branches of code and want to merge changes from one branch to another. But the real source code control system behind Codeplex is Team Foundation Server and we would have the option of using Visual Studio Team Explorer. My perception is that branching and merging is a lot different in TFS so there would be a learning curve to get up to speed as compared with continuing to use svn at SourceForge. This would only affect those with commit access though, users just doing checkout and update could use TortoiseSVN to get the code from Codeplex.

Github would also be a possibility but would require a learning curve and different tools for working with source control. I would love to have been able to consider Google Code but they don't support our use of the Common Public License and I don't think we should have to change our license to make Google happy.

At the moment I'm leaning towards using Codeplex. It is the go to place for Microsoft centric open source projects and we already host our download files there and it seems advantageous to consolidate our source code repository there. If anyone has an opinion, feel free to weigh in with comments.

UPDATE: I've completed the initial checkin at Codeplex, you can now get the latest code again, using TortoiseSVN, the url is https://mojoportal.svn.codeplex.com/svn/trunk

It was a fairly smooth migration to Codeplex and it all seems to be working ok and back to business as usual.

UPDATE 2010-05-19: We had some issues where some client machines could not get all the files using TortoiseSVN while other machines had no problems. After trying for several days to figure out why it didn't work on a problem machine we had no success in finding the cause or solution. So yesterday we reset the repository and are now using Mercurial instead of TFS. New instructions for getting the code with TortoiseAG can be found here. At first I was a little hesitant to switch to Mercurial but after reading up on it, it seemed like it might have some advantages. So far I'm really liking it better than svn.

Follow us on twitter or become a fan on Facebook

Just a quick post to mention that 5 more videos have been completed in the developer series of videos. Here is the full list of videos so far and more are on the way soon. The newest videos are at the bottom of the list. The series is aimed at teaching how to build custom features that plug into mojoPortal by demonstrating step by step how to implement a guest book feature. Once the series is completed I will also make the source code available.

1. Getting the code with TortoiseSVN
2. Source Code Overview Part 1
3. Source Code Overview Part 2
4. Custom Solution
5. Hello Web
6. Hello Web Part 2
7. Hello Guest Book
8. Concepts Part 1
9. Concepts Part 2
10. Debugging in IIS
11. Create a Table Using the Setup System
12. Using The Setup System to Run Upgrade Scripts
13. Generating a Data Access Class
14. Generate the Business Layer
15. First Guestbook Submission
16. Form Layout
17. Form Layout and Data Binding
18. Upgrading from svn and Converting to VS 2010
19. CSS Layout
20. Using a WYSIWYG Editor and Captcha
21. Default Button and Input Validation
22. Protecting Against Untrusted Content
23. Supporting Pages Part 1
24. Supporting Pages Part 2
25. Supporting Pages Part 3
26. Enforcing Security Part 1
27. Enforcing Security Part 2
28. Implementing the update method

UPDATED 2010-05-11: added 3 more videos 26, 27, and 28

Also don't forget the mojoPortal online user group meeting is coming up on May 18, 2010 at 8PM EDT.

Follow us on twitter or become a fan on Facebook

I'm happy to announce the release of Event Calendar Pro 0.0.2.7. This is a free upgrade for existing customers, though you should first upgrade to mojoPortal 2.3.4.3. It "probably" works with mojoPortal 2.3.3.9 or higher but has only been tested with mojoPortal 2.3.4.3. Customers who already purchased Event Calendar Pro can download the new version by signing into the site and then click the "My Account" link at the top of the page, and then click the Order History tab.

Whats New?

• Better support for time zones with automatic adjustment for Daylight Savings when creating future events.
• It is now possible to accept will pay later ticket orders without configuring any ecommerce provider.
• There is a new setting to allow ticket purchases/registration without having to register or sign into the site.
• There is a new recurrence option for Bi-weekly (every 14 days) events.
• When making recurring events that require registration, it is now possible to use the same begin date for ticket sales/registration for all recurrences.
• Fixed a bug in the RSS feed where the urls for events were not correct if the site was hosted in a virtual directory sub folder.

Important: Since we removed the previous time zone offset setting and added a new Time Zone setting, after upgrading you should immediately go to the settings for any existing instances of the Event Calendar and set the time zone.

Follow us on twitter or become a fan on Facebook