Office Live with Multiple Domains

If you are hosting a Website with Office Live and you need to create additional sites for your company, you should know that you need to first create a different live account and apply for an additional Office Live account. If you buy additional domains with the same Office Live account, all those domains will point to the primary domain on your account. This is only good if you want to create promotional domain names and use one Website.

If you need a new website, you will need to create a different live email account and request a new Office Live account. This email account will become the owner of the site. If you want to manage all the Websites with one email or live account, you can add that account to your Website and grant the administration role to the account. This way you can use one log in, and you will be able to design the Websites for different domains. This is quite convinience when your customer is already the owner of the site, and you only need admin access to design the Website.

I hope this helps someone out there.

CodeProject
og-bit.com

Use HTML5 LocalStorage in your Mobile Web Applications

LocalStorage or Dom Storage provides Web pages with the ability to store named key/value pairs locally. This storage is different from the browser cookies. In some systems, it allows Web applications to store from 5MB to 10MB of application data. Unlike cookies, this data is not posted back to the server. It remains locally on the device, and it is persisted even after navigating to another site or closing the browser. Like cookies, this data can be removed if the user clears the browsing history.

This storage is ideal for Web mobile applications that do not require a lot of data storage, and all the data access can be done with scripting objects. When using the local storage, you should consider the following:

1)      Validate that the local storage is available. This is available on browsers that support HTML5 and IE8+. Devices like IPhone, Android and BlackBerries support HTML5. Windows Mobile 7 may be getting HTML5 support in the middle of 2011.

2)      For the keys, use a namespace that differentiates the Web applications in the same domain and append a unique token for that record.

3)       Always check that the storage limit has not been reached. This exception would be raised when adding new items.

Simple data provider to illustrate the ability to add and read values from the Local Storage:

og.Data.Storage = {

    isSupported: function () {

        try {

            return ('localStorage' in window && window['localStorage'] !== null);          

        } catch (e) {

            return false;

        }

    },

    Add: function (key, value) {

           try {

                localStorage.setItem(key, value);

                //or localStorage[key] = value; //like associative arrays

            } catch (e) {

                alert(e.Description);

                return -1;

            }

    },

    Get: function (key) {

        return localStorage.getItem(key);

        //or localStorage[key];

    }

}

This simple data provider implementation can be used to test if the localStorage is available. It also supports Add and Get methods. To use the provider, you could write a simple script as follows:

if (og.Data.Storage.isSupported()){
    og.Data.Storage.Add("myapp.key1","value 1");   //notice the key name
    og.Data.Storage.Add("myapp.key2","value 2");
    var val1= og.Data.Storage.Get("myapp.key1");
    var val2= og.Data.Storage.Get("myapp.key2");
}

If you need data storage for small Web apps, this may be something to look into.

CodeProject
og-bit.com

Customize the Build Number in Team Build

If you have used TFS team build, you know that MSBuild creates a default label and build number/name with the following format:

Build Definition Name_YYYYMMDD_#

Where the # is an incremental number for the date. This format does not really provide any information about the version your are building. Nevertheless,  The build number can be customized using the BuildNumberOverrideTarget. There are different approaches to achieve this.  In this instance, we will take a very simple approach that allow us to add the current product version to the build number without having to use a custom task which requires the deployment of a assembly on the build machine. The one item to always keep in mind is that the build number must be unique.

Open your TFs build project  and add the following property group:

<PropertyGroup>

    <VersionMajor>1</VersionMajor>

    <VersionMinor>0</VersionMinor>

    <VersionService>0</VersionService>

    <VersionBuild>1</VersionBuild>

</PropertyGroup>

We just added a group of variables that indicate that the product we want to build has this version 1.0.0.1. You can change this to match your standard and your product version.  Now add the target override as follows:

<Target Name="BuildNumberOverrideTarget">

<Message Text="Build number before [$(BuildNumber)]" />

<PropertyGroup>

<BuildNumber>$(BuildNumber) [$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>

</PropertyGroup>

<Message Text="Build number after [$(BuildNumber)]" />

</Target>

With this override, we are basically indicating that we want to append our version number to the TFS build number. We decided to keep the TFS build number  to continue to provide a unique label/number to the build. The messages in the override log the build number before and after the change.  If you check in your changes and queue a build, you will see that the build number has changed to this new format:

Build Definition Name_YYYYMMDD_# [MAJOR.MINOR.SERVICE.BUILD]

You will now be able to easily see the version associated to the  build. When you are ready to build a new version, you will need to modify the property group.  You should also know that if you try to build during the same day, you will probably get a non-unique build number error. This is because the build number that was generated was replaced by our custom build number, and the build process uses the "Build Definition Name_YYYYMMDD_#+1" to increment the build for the same date. To address this, you can add a parameter and append it to the build number as follows:

The build label parameter should be added to the MSBuild command-line arguments as follows:

/p:BuildLabel=001
The custom build task should address this limitation, but this is part of a different blog entry.

I hope this is helpful.

<Target Name="BuildNumberOverrideTarget">

<Message Text="Build number before [$(BuildNumber)]" />

<PropertyGroup>

<BuildNumber>$(BuildNumber)$(BuildLabel) [$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>

</PropertyGroup>

<Message Text="Build number after [$(BuildNumber)]" />

</Target>

CodeProject
og-bit.com