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
