error 0040: The Type … is not qualified with a namespace or alias. Only PrimitiveTypes can be used without qualification.

This is caused by Npgsql mapping a very sparse selection of type-names to the underlying Entity Framework type structures.

As of 2.0.9, the following type names are recognized:

• bool
• int2
• int4
• float4
• float8
• uuid
• numeric
• bpchar
• varchar
• text
• xml
• timestamp
• date
• bytea

Today I want to write about the work I’m currently commisioned for by puppetlabs, porting puppet to Microsoft Windows.

Current Status

After disabling some minor pieces (color, conf file watching) and fixing a few bugs (see the tree on github) and a little bit hacking various parts to pass through paths with a drive letter, I was able to create the first file on windows with puppet. On the downside a few technical problems with the code surfaced, the most daunting were approximately 600 spec failures (out of 8.500 examples).

The Plan

Markus Roberts and myself used some of the breaks and sessions to hash out solutions for the various hurdles that I identified. After fixing those, we can move on to pushing the actual basic Microsoft Windows support to master without breaking hell loose and start implementing providers on a larger scale, while people have something in hand to start playing with.

Unit Testing

This one was easy. Most of the test failures are caused by examples that use Puppet::Type.type(:file) when they need a type to test the “other” functionality they’re testing. This legacy is a result of bad experiences with examples that did not fail after removing the “tested” code, because they were stubbing away too much. As a next step in the evolution of such examples, puppetlabs will create an simple, instrumentable type specifically to be used in tests. That way it’ll be a “real” type for the examples, without any of the complex functionality needs of “real” types.

File is lacking providers

In my git tree is already a start of a POSIX and a Microsoft Windows provider for file handling. This is currently only a spike implementation and will have to be seriously expanded once the unit tests don’t blow up when touching this area.

Moving to multi-valued titles

I’ve started a discussion about the design of multi-valued titles on the puppet-dev mailing list. This should make implementing the various path syntaxes much more convenient and easier to handle in the file type. Markus promised me a prototype to play with.

Providing actual functionality

There was discussion at the puppetcamp whether or not to use the command line tools from the resource kit to manipulate users, groups, services and what-not. While I have not looked deeply into this, as my focus until now was getting puppet to run at all, I believe those tools will be a good source of what should be possible, but no good for implementing the providers. One, the tools are another external dependency, they have localized output which will make parsing them very hard, and the output can differ from one release to the next. On the other hand, MRI has quite flexible ways to access the underlying C APIs of Microsoft Windows and those functions are documented and should be quite stable.

R: Gendarme.Rules.Exceptions.ExceptionShouldBeVisibleRule
T: System.Diagnostics.Contracts.__ContractsRuntime/ContractException

R: Gendarme.Rules.Exceptions.MissingExceptionConstructorsRule
T: System.Diagnostics.Contracts.__ContractsRuntime/ContractException

R: Gendarme.Rules.Serialization.MissingSerializableAttributeOnISerializableTypeRule
T: System.Diagnostics.Contracts.__ContractsRuntime/ContractException

R: Gendarme.Rules.Serialization.MissingSerializationConstructorRule
T: System.Diagnostics.Contracts.__ContractsRuntime/ContractException

Since this is a tool-generated class we cannot do anything about it anyways and should not access or need the missing features.

You can find the packages on the download pages of the Kolab Sync for Outlook und Kolab Sync for Android projects.

Please use the issue trackers there for feedback.

Using this software you will be able synchronize your contacts and calendar to any IMAP folder. Every item is saved in a separate Email using the Kolab Storage Format. This allows for interoperability with other Kolab Clients.

Please join us on the Google code projects for the Android and the Outlook connectors.

Since there are still quite a few rough edges, this is only a developer preview to publish the already done work. Read on for a more detailed status of the development so far.

Status

• Sync Infrastructure: although the two projects are written in Java and C#, they share the basic algorithms and principles of operation. This groundwork is also shared between the addressbook and contacts synchronizers of each project. This is already stable. Some edge cases still require a second synchronization run to converge.
• Addressbook Synchronization: being the easier part of the two, this is mostly finished and working.
• Calendar Synchronization: Arthur is currently implementing the last piece here: reading and writing of recurrences.
• Managing Edit Collisions: If two copies of the same item are edited and then synchronized, there is no easy way to automatically manage the merge. On the Android the server item always wins. For the Outlook plugin we plan on implementing a conflict resolution dialog where the user can pick and choose from the conflicting items.
• Managing Duplicates: When starting to use synchronization tools, users often end up with multiple copies of the same entries (especially in the addressbook) when multiple data sources are added. Currently the only way to work around this problem is to use a third-party duplicate-detector or wipe all but one device clean before synchronizing. A way to handle this could be added similar to a edit conflict resolver.
• Multiple Calendars, multiple IMAP Folders: planned.
• Testing: Currently there are only manual test routines.

    using Microsoft.Build.Framework;
    using Microsoft.Build.Utilities;

    public class ArebisGenTask
        : Task
    {
        [Required]
        public ITaskItem[] Templates { get; set; }

        [Output]
        public ITaskItem[] GeneratedFiles { get; set; }

        public override bool Execute()
        {
            var generatedFileNames = new List<string>();
            foreach (var task in this.Templates)
            {
                string inputFileName = task.ItemSpec;
                string outputFileName = Path.ChangeExtension(inputFileName, ".Designer.cs");
                string result;

                try
                {
                    // Build code string
                    result = Builder.CreateCode(inputFileName);

                    using (var destination = new FileStream(outputFileName, FileMode.Create))
                    {
                        var bytes = Encoding.UTF8.GetBytes(result);
                        destination.Write(bytes, 0, bytes.Length);
                    }
                    generatedFileNames.Add(outputFileName);
                }
                catch (Exception ex)
                {
                    Log.LogError("Error while compiling [{0}]", inputFileName);
                    Log.LogErrorFromException(ex, true, true, inputFileName);
                }
            }
            GeneratedFiles = generatedFileNames.Select(name => new TaskItem(name)).ToArray();
            Log.LogMessage("Finished Generation");
            return !Log.HasLoggedErrors;
        }
    }

Now that I finally found some tuits to do it, the next problem became obvious: doing a quick commit often lead to a quick build fail. Gendarme would have no use if it didn’t find anything, no? So the missing piece was integration into Visual Studio. Arthur hacked together a little XSLT+PowerShell and voila, Gendarme now runs on every build right from the studio and populates the “Error List” window with properly linked entries. Yay!

Read on for the details of the implementation. The complete source is downloadable at the end of the article.

First, the XSLT (“gendarme.xslt”), transforming Gendarme’s XML to properly formatted text.

<?xml version="1.0"?>
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="2.0">
  <xsl:output method="text"/>

  <xsl:template match="/">
    <xsl:call-template name="rules">
      <xsl:with-param name="detailnodes" select="//results/rule"/>
    </xsl:call-template>
  </xsl:template>

  <xsl:template name="rules">
    <xsl:param name="detailnodes"/>
    <xsl:for-each select="$detailnodes">
      <xsl:call-template name="defects">
        <xsl:with-param name="detailnodes" select="target/defect"/>
      </xsl:call-template>
    </xsl:for-each>
  </xsl:template>

  <xsl:template name="defects">
    <xsl:param name="detailnodes"/>
    <xsl:for-each select="$detailnodes">
      <xsl:value-of select="@Source"/>: error :[gendarme] <xsl:value-of select="../../problem"/> Target: <xsl:value-of select="../@Name"/>.
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

Second, the powershell fragment to execute gendarme and transform the output (“gendarme.ps1″).

param($SolutionDir)

function Convert-WithXslt($xmlFilePath, $xsltFilePath, $outputFilePath)
{
    $xsltFilePath = resolve-path $xsltFilePath
    $xmlFilePath = resolve-path $xmlFilePath
    $outputFilePath = resolve-path $outputFilePath

    $xslt = new-object system.xml.xsl.xslcompiledtransform
    $xslt.load( $xsltFilePath )
    $xslt.Transform( $xmlFilePath, $outputFilePath )
}

if(-not $SolutionDir)
{
	$SolutionDir = ".";
}

"." > $SolutionDir\bin\gendarme.txt
gendarme.exe -config $SolutionDir\gendarmerules.xml --xml $SolutionDir\bin\gendarme.xml $SolutionDir\bin\Debug\blahblah.exe
convert-withxslt $SolutionDir\bin\gendarme.xml $SolutionDir\gendarme.xslt $SolutionDir\bin\gendarme.txt
(get-content $SolutionDir\bin\gendarme.txt) -replace '\(\D?(\d+)\)', ' ($1,1)' | set-content $SolutionDir\bin\gendarme.txt
exit 0

Instead of blahblah.exe, put your own assemblies you want to check.

And last but not least, the post build step to actually run the whole thing.

powershell -command $(SolutionDir)gendarme.ps1 -SolutionDir:$(SolutionDir)
type $(SolutionDir)bin\gendarme.txt


This can be added in your project properties on the “Build Events” tab, as “Post-build event command line”. In our project this is executed in one of the unit-test projects which has dependencies on all other projects and thus builds last.

Don’t forget to enable the RemoteSigned execution policy of the powershell; either by running

set-executionpolicy -executionPolicy RemoteSigned


from a Administrator’s shell or by adding one or both of the powershell.executionpolicy.reg and powershell.executionpolicy.wow6432.reg files to your registry.

You can find all files in this ZIP archive.

Seeing unexplicable “System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.” errors?

You might be a victim of nunit’s bug #423611.

See also here, here and here.

A typical error message looks like this:

Unhandled exceptions:
1) : System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.

I’ve uploaded a minimal solution exhibiting the problem to the bugreport and I hope that’ll help clearing the issue up.

To improve response times of the server running CC.Net while integrating, I’ve applied the ProcessPriority patch from CCNET-504 and now run all processes at BelowNormal. Now there is no noticeable impact on other services on the server while a build is running. Since the patch didn’t apply cleanly to the newest CC.Net version, I updated the patch to current HEAD and posted it in the bugtracker. Thanks to Craig Sutherland the patch is now applied in the HEAD and will be released with 1.5. Having already wet my feet, I proposed a refactoring for the Tasks to move all common properties to the BaseExecutableTask class, thereby removing ~300 lines of code and unifying the diverse set of properties currently in the wild. This will have to wait for the next release in order to not interfere with a timely 1.5 release.

Currently CC.Net builds the projects from subversion, runs all unit tests with NUnit and checks code quality with Gendarme.

While integrating Gendarme in our build process, I found and reported two bugs in the rules, which triggered false positives on our code. Thanks to Sebastien Pouliot both appear to be already fixed and slated for release with the next Gendarme (2.8).

The behavior of float and real follows the IEEE 754 specification on approximate numeric data types.

[emphasis mine]

The XPath article states it clearly:

However, float(53) is not exactly IEEE 754. For example, neither NaN (Not-a-Number) nor infinity is used.

.

For completeness, here’s a little review about other DMBS’ support for NaNs and Infinity:

• MySQL does what it always does if it encounters “strange” values: according to this comment by Carl Fischer (bottom of the page), MySQL transforms the special values quietly to zero when writing them into the table.
• Oracle (starting at version 10g) supports all IEEE754 single and double precision values and provides constants for NaN and Infinity in its SQL implementation. This is implemented using the BINARY_FLOAT and BINARY_DOUBLE data types.
• PostgreSQL uses the underlying system’s float representation and allows input of NaN and infinite values.