Just a quick update, I have been merging in the 6.0.3 changes to 6.0.6. At present, 867 / 1086 tests are passing.
Sunday, 30 June 2013
Thursday, 20 June 2013
6.0.6 now compiles in mono - it only needed a few casing changes in resource files, and some changes to the SQLCE project (which we do not use in mono - but for safety I am making sure it compiles). I also had to remove comments from some auto generated designer.cs files.
On an unrelated note - if you get this:
No access to the given key
It means that the MS .NET version of Microsoft.Web.Infrastructure.dll is present. Removing the MS .NET dll is sufficient to clear this error.
Monday, 17 June 2013
Codegarden was a great event as usual. We got a glimpse into the changes that are going on with Umbraco version 7 - the big topic was Angular JS.
My mono / Linux presentation proceeded as planned. And I also had a chance to catch up with the core team to discuss how we can bring the mono changes into the Umbraco project.
On other very good news, Umbraco is now hosted on git hub, and this makes life a whole lot easier!
I will continue with the mono development on my git hub project and deliver production ready distributions for 4.7.2, 4.11.x, and 6.0.6. After this is done, there will be no further development in this repo. I anticipate that in 2 - 3 months, this should all be completed.
For those who want a head start, I have already created a sample Linux web site with sample configuration files here. However, this sample uses Umbraco 6.0.3, and therefore is not production ready. It also has a Lucene bug and an intermittent Xml Cache issue, which remain to be fixed. But it is great for a head start.
I also intend to release an ISP guide, which will make it easier for ISPs and hosting providers to create and set-up mono / Linux based Umbraco hosting environments.
Happy computing everyone!
Wednesday, 12 June 2013
Saturday, 8 June 2013
With, Codegarden 2013 happening in a few days time, I will be demonstrating an alpha version of the 6.0.3 code. As we know, 6.0.3 suffers from a security flaw, and is not suitable for production systems.
There are two additional caveats:
- Lucene searches report incorrect nesting levels (1 less than the actual)
- Some content service tests are also failing and I do not yet know why
But overall 878 test are passing now.
Sunday, 2 June 2013
Yay, 840 tests are passing...
Let,s look at the highlights for the passing tests:
- Majority of pass results due to test set-up changes - in particular the Mysql db set-up.
- The stock NUnit dll pulled in by NuGet Restore (2.6.2) has isues in mono, and the NUnit introspection code will not work. Resolved by using NUnit 2.6.1 from ArchLinux AUR (required edit of AUR package file). NuGet 2.6.1 should work, but I have not tried it.
Does not appear to work. Replaced with:
for (var i = RouteTable.Routes.Count - 1; i > -1; i--)
- DbProvider issue...
Goes to the machine.config file - so the dbProvider must exist there. Resolved by adding the MySql dbProvider to machine.config. Cause: This is b/c in tests HttpRequest is not defined and in mono this leads to a loss of the path (GetCurrentPath) to the nunit test config file.
- Case insensitive Linq style query tests, e.g. (...).level will fail because the existing 'rescue' code fails in mono. To fix this I added:
public class ReflectionHelper
public static BindingFlags GetBindingFlagsCasingSafe(BindingFlags bindingFlags)
return bindingFlags | BindingFlags.IgnoreCase;
And, let's look at the highlights for the failing tests:
Majority in Persistence.Repositories and Service.ContentService tests - may be due to database set-up issues.
- PartialTrust...WhenMethodShouldNotSucceed - fail due to CAS implementation issues in mono.
- String Extension Tests - encrypt / decrypt fail b/c of mono implementation differences. In particular, the HttpRuntime class is implemented very differently in mono, and I have not yet found a way to mock it. The encryption code leads to a direct call involving the HttpRuntime, and fails whenAppDomainVirtualPath is null. Easiest way to fix this would be to wrap the encryption code to make it mockable. In particular,