4.11.3 - Tests II

478 / 499 (the 500th test does not contain any active tests) tests are passing. Of the remaining 21 tests, cause of failures are:

• 
  Partial Trust: ...(ReportsFailure) - I have not been able to get these to work. Apparently in mono CAS (Code Access Security) is experimental and unsupported. I have not been able to enforce Reflection Access restrictions in test code, nor have I been able to debug it in an NUnit test instance. Please see here for details.
  
  In mono it appears that,
  

  
  SecurityManager.SecurityEnable returns false unless 
  mono is run with the --security option. 
  

  
  


• 
  Published Content: DynamicNode, DynamicPublishedContent, DynamiXml, StronglyTypedQuery tests - Not sure yet if failure is because of test set-up differences or a genuine implementation difference in the .NET mono implementation.
  


• 
  Published Content: DynamicNode Get_Member_Property fails because it needs some additional test database initialisation, namely the alias of the parent document type. (TO DO)
  

Summary: All is looking good but both the Partial trust and DynamicNode / PublishedContent / Xml tests indicate that there may be some issues due to implementation differences. This will need further clarification and testing.

Git commit hash a1f5565762

4.11.3 - Tests

The Umbraco HQ team has done a great job with the tests, and the testing architecture. I have done a few small changes, e.g. moving the test database over to MySql by way of an MySqlTestHelper.

At present about 269 /500 tests are passing. Some of the failing tests pass when run individually. This has been a slow laborious process, and Monodevelop has been frequently freezing after failing tests.

I will need to update my own test (4.7.2) code at some point. I am using it here but it is not a good architectural match, and will need to be refactored.

For compatibility it might be good in the future to move the test database to SqlLite - or another db that can be used in Windows and non-Windows environments.

4.11.3 - Of Razor, Mvc, and More

I have started testing Razor and Mvc features. Here are the important bits:

• XPathNodeIterator MoveNext issues revisited:
  

  Example:
  if (media != null && media.Current != null) 
  {
      media.MoveNext();
      ...
  }
  

  
  Does not work in mono, as until MoveNext() is called Current is always null.
  


• 'Could not locate Razor Host Factory type: umbraco.MacroEngines.RazorUmbracoFactory, umbraco.MacroEngines' error message - this stems from a bug in mono. The quick resolution is to use either one of the two below:
  

  
  In web.config use:
    <system.web.webPages.razor>
      <host factoryType="umbraco.MacroEngines.RazorUmbracoFactory" />
      
  or use
    <system.web.webPages.razor>
      <host factoryType="umbraco.MacroEngines.RazorUmbracoFactory, umbraco.MacroEngines, Version=1.0.4832.22841, Culture=neutral, PublicKeyToken=null" />
  

  
  The 'bug' is in the mono type enumerator:
  

  
  In mono System.Web.Compilation > BuildManager > public static Type GetType (string typeName, bool throwOnError, bool ignoreCase)
  
  ...
  	var aname = new AssemblyName (typeName.Substring (comma + 1));
  	wantedAsmName = aname.ToString ();
  ...
  	if (String.Compare (wantedAsmName, asm.GetName ().ToString (), StringComparison.Ordinal) == 0) { 
  ...
  

  
  Looks for an exact match in assembly name if one is supplied
  


• Some razor logic seems to produce a compiler error:
  

  
  @inherits umbraco.MacroEngines.DynamicNodeContext
  @{ 
  	var level = String.IsNullOrEmpty(Parameter.Level) ? 1 : int.Parse(Parameter.Level); 
  	var ulClass = String.IsNullOrEmpty(Parameter.UlClass) ? "" : String.Format(" class=\"{0}\"", Parameter.UlClass); 
  	var parent = @Model.AncestorOrSelf(level);
  	if (parent != null) { ** fails here **
           ....
  	}
  }
  

  
  Produces 'single file build failed,' and this can be traced back to a lock in the mono System.Web.Compilation > BuildManager.cs > static void Build (VirtualPath vp) > line 404.
  

  
  ...
          static readonly object bigCompilationLock = new object ();  
  ...
  	CompilationSection cs = CompilationConfig;
  	lock (bigCompilationLock) {
  

  
  This is the most serious error so far, and needs some investigation. However, in this case, removing the null check is sufficient to make the compilation succeed, and workarounds therefore, may exist.
  


• Summary 1: in addition to casing issues, the XPathNodeIterator MoveNext issue is emerging as a key issue.
  


• Summary 2: Razor and MVC functionality will need further testing.
  

4.11.3 - Content Area

OK, the Content area is now finished as well. All superficial UI functions have now been fixed. The latest round of fixes address some important mono differences:

• 1f54a0c35f - Our good friend: To initialise an XPathNode Iterator, call MoveNext() first. Content > Public Access was throwing errors, which were fixed with MoveNext calls (via the introduction of an XmlHelper method).


• 7ee981a56b - The mono multiline text box control tab injection bug was fixed by some jQuery


• 3b7f42c97b - The false positive in the xss check when first logging in was fixed as well. This error originated because mono treats absolute paths starting with '/' as a file system path (in the Uri class), and sets the Host name to an empty string.

4.11.3 Users Area

The users area is now completed as well. Again, this was pretty much smooth sailing, except that in the edit user type section, the dynamic checkbox list was losing its state. Again, I applied a local fix. So the dynamic checkbox state issue is revealing itself to be quite significant.

I have also started on the Content area. More on that in the next post.

4.11.3 - Update

Well, I have now also cleared the Developer > Packages area, and also the Media, and Member areas, which are in working order for all basic tasks.

There were mostly casing changes, but there are a couple of important points to report - both on the Developer > Packages section:

• During the package uninstall dialog, the dynamically created checkboxes lose state, and this needed fixing. This is a well known mono issue and I have applied the same fix for it in three different places - a bit of repetition, I know. These will be merged at some point. Probably with the 6.0 port.
• The packages callback from umbraco.org returns an all lower-case url, and I changed the casing of the umbraco\developer\Packages\ folder the 'packages'. I generally try to avoid file system changes. But in this case, it was needed.

The packages area functionality will be a difficult to get working - it looks like this area will be most sensitive to platform specific changes such as casing, the directory separator, and also the issue of the casing of xml nodes names (which I have yet to address).

4.11.3 Developer area - UI load errors fixed

OK I have fixed up all the errors experienced during superficial load, and item creation (except Packages). Again this was mostly smooth sailing.

git commit hash f61901a0cc

4.11.3 Settings area cleared

Yes, I cleared the 'Settings' area today. Most of it was smooth sailing: the majority of the changes were casing related, and a few other issues, that I had already fixed in 4.7.2, and now ported over into the new codebase.

There was one small issue of note - that was a new addition: Mono does not implement

AllInternalsVisible=true

And, using this in the attribute declaration will actually make the friend assembly not see the desired internal assembly.

One exception: mono tab bug fix has been deferred for now.

That's it for now.

git commit hash b0b7d974