I mentioned in my last blog that I planned on publishing a video that would give an overview of how the Silverlight module template works.  I have updated the download page to include a reference to it.

Please note the updating of a module through the install.aspx?mode=installresources link will not work for 5.01 due to a bug.  The original installation does work.  Updates can use the normal install wizard or can be patched by downloading the source and opening up Library\Services\Installer\Installer.vb file and adding the following line at around line #236.  Please note that this is not an official patch.

If kvp.Value.Package.IsValid Then
  InstallerInfo.RepairInstall = True  'quick fix to allow install packages to repair

I finally was able to get the multi-project template functionality working to enable the easy creation of a DotNetNuke Silverlight module.  The sample demonstrates how easy it is to have Silverlight interact with javascript, which in turn can talk directly to your server-side module code.  Unlike the other module templates, this one requires the creation two projects, one for your DNN module and one to host your Silverlight code.  Upon compilation, the Silverlight code gets zipped up into a file with a XAP extension.  This then gets packaged into the DNN module installation package and a source package. 

The diagram above shows the basic interactions with the server-side code and the client.  The DotNetNuke Framework box should be straight forward, as the previous AJAX templates work this way.  The server-side gray box simply denotes static files served up by IIS.  However, when the client loads them, you end up with managed C# or VB.NET code running on the client.  The interaction between our client-side module and the rest of the framework is quite cool.  When I was writing this code, I found myself saying, Wow!  It just works as I would expect!  I plan on creating a video explaining this soon. 

Since the Silverlight code can interact with javascript, it can easily call the dnn.xmlhttp methods to initiate a Control Method call to the server.  Those familiar with the edit-in-place capabilities in the Text/HTML module should know the Control Method calls work with the standard ASP.NET forms authentication scheme, which means we can easily verify the rights of a user.  The module generated from the template prove this point.

Finally, I wanted to note how cool it is that Blend can open up a sln file directly and even compile it!  This means that you can open the same template solution, edit the XAML (UI) and compile directly in Blend.  Then simply refresh your dnn/install/install.aspx?mode=installresources link to re-install the module, and refresh your page with the module to instantly see your modifications.

Excited?  Go grab it now from CodePlex!

I am pleased to announce the availability of a new DotNetNuke skin template on CodePlex.  I decided to add two additional templates (DotNetNuke Skin (VB) and DotNetNuke Skin (C#)).  Like the AJAX Module templates, these templates will provide all the MSBuild goodness to automatically create a source and installation package using the information collected in the wizard upon project creation.  The default skin that is created demonstrates some of the new functionality now possible with the DNNMenu v2.x like

• Rounded glossy corners
• Animation (requires updated navigation provider)
• Substitution of items for images
• Control over nearly every aspect of the menu via CSS Selectors

To get started simply

• Download the msi setup package and install it
• Start Visual Studio, Choose New Project... and Select DotNetNuke Skin

• Fill out the wizard

• Choose Load project normally when the Security Warning shows

• Read documentation for pointers

• Compile the skin (You are not actually compiling a dll, this is simply running the custom MSBuild script to package your skin)
• Install the skin like any other through DotNetNuke.  Note:  the ability to install via install.aspx?mode=installresources is not possible at this time due to a bug in DNN5.

For those of you who wish to simply learn from an already created skin, simply download the Sample installation package directly.

The sample skin has two kinds: index and animated.  This demonstrates both flavors of skin development (ascx and html using the new object tag syntax).  The animated uses ascx due to the lack of support for custom attributes in the html token replacement engine in dnn.  (I am still trying to get this added- please don't direct your annoyances at me).  It also has a packaged container which demonstrates a few more css tweaks.

Finally, I want to encourage people to download the latest version of the WebControls on CodePlex.  It is not required for this skin/template, but there was one minor fix I added to address the animation triggering multiple times.

Last post in this series we learned some basics of MSBuild, including the use of 3rd party tasks.  We saw that by simply importing some other targets file we can extend the functionality available to our scripting language.  The last two pieces to this puzzle happen to be solved by use of 3rd party plugins available on CodePlex:  Deployment and Automating our Build.

Deployment

Every build we wish to publish can easily be published to our project page via the CodePlex MSBuild tasks.  The first step is to import the CodePlex targets file into our script.

<Import Project="$(RootDir)\lib\MSBuildCodePlexTasks\CodePlex.WebServices.Client.Targets" Condition="'$(DeployToCodePlex)' == '1'" />

With our custom tasks imported, creating a new release is as simple as defining a new target and setting a bunch of properties.

<Target Name="DeployToCodePlex" Condition="$(DeployToCodePlex) == '1' and $(ConfigurationName)=='Release'" >
    <CreateRelease
        ProjectName="$(ProjectName)"
        ReleaseName="v$(Major).$(Minor).$(Build).$(Revision) - Nightly"
        IsDefaultRelease="$(IsDefaultRelease)"
        ShowToPublic="$(ShowToPublic)"
        ShowOnHomePage="$(ShowOnHomePage)"
        Description="$(Description)"
        ReleaseDate="$(ReleaseDate)"
        ReleaseStatus="$(ReleaseStatus)"
        Username="$(User)"
        Password="$(Password)" />

Most of the properties mentioned here are pretty self-evident.  What may not be is where they are defined.  The fact that we are publishing our source code to the central server and it is this code that we are using to publish code, it probably is not a good idea to put our username and password directly into this script, or any script that gets uploaded to our source control.  Instead, what I chose to do was create a file outside my folder structure that gets imported when it exists. 

<Import Project="$(RootDir)\..\..\DNNWCNonDist.Targets" Condition="Exists('$(RootDir)\..\..\DNNWCNonDist.Targets')" />

This will allow your users who download your code to still run most of your build tasks, but will not give them rights to create a public release!  The basics of this file are as follows.

xml version="1.0" encoding="utf-8" ?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
    <DeployDir>$(RootDir)\deployDeployDir>
    <DeployToCodePlex>1DeployToCodePlex>
    <DeployToWebcontrolsSite>0DeployToWebcontrolsSite>  
    <DotNetNukeDir>D:\dev\DotNetNuke\Core_Development\DotNetNuke_Cambrian\WebsiteDotNetNukeDir>
    <WebSiteDir>$(RootDir)\websiteWebSiteDir>

    
    <IsDefaultRelease>falseIsDefaultRelease>
    <ShowToPublic>falseShowToPublic>
    <ShowOnHomePage>falseShowOnHomePage>
    <Description>Nightly BuildDescription>
    <ReleaseStatus>PlannedReleaseStatus>
    <User>******User>
    <Password>******Password>
PropertyGroup>
Project>

With our release created it is now time to use another task to upload our files.  First we need to define what files to use by creating an ItemGroup.

<ItemGroup>
    <ReleaseFile Include="$(DeployDir)\WebControls.install.v$(Major).$(Minor).$(Build).$(Revision).zip">
        <FileType>RuntimeBinaryFileType>
    ReleaseFile>
    <ReleaseFile Include="$(DeployDir)\WebControls.source.v$(Major).$(Minor).$(Build).$(Revision).zip">
        <FileType>SourceCodeFileType>
    ReleaseFile>
ItemGroup>

We then use the UploadFiles task to cause our files to be uploaded.

<UploadFiles
        ProjectName="$(ProjectName)"
        ReleaseName="v$(Major).$(Minor).$(Build).$(Revision) - Nightly"
        ReleaseFiles="@(ReleaseFile)"
        Username="$(User)"
        Password="$(Password)" />

Triggering an Automated Build

In order to completely automate our process, we need a piece of software to monitor our source code at some defined interval and pull down any changes, then simply initiate our build process.  Since all of our deployment logic is encapsulated in our build script this is probably the easiest portion to configure.  I chose to use CruiseControl.NET running locally to handle my builds mainly due to the fact that CodePlex offers a sourcecontrol block for us found here.  If your new to CruiseControl.NET I suggest digging through their documentation.  Once you have cruise installed simply follow the instructions on the CodePlex page:  Copy 3 dlls into the CruiseControl.NET\Server folder and make sure you have the J# redistributable installed.  Yes, I agree, requiring J# for a .NET plugable architecture like Cruise is a bit odd.  To configure your project simply find the CruiseControl.NET Start menu entry and choose CruiseControl.NET Config to edit the xml file used in setting up your project.

<cruisecontrol>
    <project>
        <name>DotNetNuke_WebControlsname>
        <triggers>
            <intervalTrigger seconds="3000" buildCondition="IfModificationExists"/>
        triggers>
        <workingDirectory>E:\dev\DotNetNuke\CodePlex\DotNetNuke.WebControlsworkingDirectory>
        <sourcecontrol type="codeplex">
            <project>dnnwebcontrolsproject>
            <projectPath>/trunkprojectPath>
        sourcecontrol>
        <tasks>
            <msbuild>
                <executable>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exeexecutable>
                <workingDirectory>E:\dev\DotNetNuke\CodePlex\DotNetNuke.WebControls\workingDirectory>
                <projectFile>DotNetNuke.WebControls.slnprojectFile>
                <buildArgs>/noconsolelogger /p:Configuration=Release /v:diagbuildArgs>
                <targets>Buildtargets>
                <timeout>3000timeout>
                <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dlllogger>
            msbuild>
        tasks>
    project>
cruisecontrol>

With cruise you simply define an interval trigger to pull your sourcecode directory.  I chose to only perform a build if a modification has taken place, which I believe is the default.  The interaction with CodePlex is all handled by their plugin, simply specify the project name and path within the source control tree to pull and then launch a msbuild task passing in your solution file.  You will notice that there is no secure information here.  Instead it will be assumed that the DNNWCNonDist.Targets file, mentioned earlier, will be relatively located to the working directory.  Without this file our builds will still work, they just won't be published. 

Closing Thoughts

Obviously I could have spent a lot of time going into each of the details on how to customize your own build environment.  I purposefully chose to address this series at a higher level, to try and give you a roadmap of where to start and what are the pieces you need to consider.  Hopefully you found it helpful.

I've been working on a project for a client recently and was bitten by a bug recently.  It has to do with using the Microsoft AJAX Extensions, specifically, the JavascriptSerializer.  Our use of JSON is simply as an easy way to serialize our objects, whether it be to disk or across the wire.  What was happening is objects that contained dates would get their time shifted when they reached the other side.  The explanation is that the serialization format of JSON has no way of representing what .NET uses its Kind property for.  And since there is no Kind available on deserialization it assumes UTC. 

For those who don't know or don't memorize, here is a quick bit of trivia.  Assume central time.

The answer is...

A DateTime of Unspecified Kind that has ToLocal applied to it will be -6.  Similarly a DateTime of Unspecified Kind that has ToUniversalTime applied will be +6.  The logic is that .NET does not know the kind.  If you call ToLocal or ToUniversalTime you must want a conversion.  As to why the JSON deserialization process chooses to make it Utc I don't know.  It would seem to make more sense to simply use Unspecified as the json has not specified a kind.  There are several blog posts covering this subject (here and here for example) but the solutions offered seemed to come up short of what I desired.  I want to serialize any object and not have to inform the other developers that DateTime properties need this extra logic in their setters. 

Fortunately, the JavascriptSerializer allows you to add your own Converters with ease.  Information on how to use it can be found on Microsoft's site here.  However, when I first looked at it I was a bit confused by the SupportedTypes property, as I have never seen code quite like it.

        public override IEnumerable SupportedTypes
        {
            //Define the ListItemCollection as a supported type.
            get { return new ReadOnlyCollection(new List(new Type[] { typeof(ListItemCollection) })); }
        }

Can it really be necessary to create a new ReadOnlyCollection, passing it a new generic List, passing it a Type array, which specifies a Type?  Yeah, this is a bit more complicated than it needs to be!  I will post my entire console sample for you to play with yourself.  Hopefully it saves someone the trouble I went through.

using System;
using System.Collections.Generic;
using System.Web.Script.Serialization;

namespace jsonconverters
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime now = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
            
            Console.WriteLine(now.ToString());
            var title = new Title() { Name = "Iron Man", ReleaseDate = now, CreateDate = now };

            var serializer = new JavaScriptSerializer();
            
            //comment this line out to see results without our custom converter
            serializer.RegisterConverters(new JavaScriptConverter[] { new DateTimeConverter() });

            var json = serializer.Serialize(title);
            Console.WriteLine(json);
            var newTitle = serializer.Deserialize