Getting Key Token of a Signed Assembly

To obtain the public key token from strong-named and signed assembly, I normally use the Reflector tool to view it. Lately, I discovered that you can get the key token from the Visual Studio.NET IDE tool, too. Here are the steps

1. Open Visual Studio 2005, click Tools -> External Tools...
2. Click Add and enter the following inputs

Title: Get Public Key
Command: C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe
Arguments: -Tp "$(TargetPath)"

* Uncheck all options, except Use Output window\

After clicking OK, go to the "Get Public Key" in the Tools Menu.



And you would get the public key as well as its token in the OUTPUT WINDOW.

ASPMENU Source Code is now available !

The underivable AspMenu class that shipped with WSS 3.0 is now unsealed ! The class source code has been released lately to allow developers to extend its functionality. Download the MOSSMenu source code here and you can treat the class as your base class for your own custom menu.

Check Customizing the WSS 3.0/MOSS 2007 Menu Control -- MossMenu source code released for more information.

Inflexibility of WSS 3.0 Customization

Recently I came across the page customization in WSS 3.0 (Creating new custom page that using application.master under _layouts folder), and I found out that the master page is likely not edited for the company branding purpose because the master page is used and shared by all sites in the WSS v3. Any changes upon the application.master would eventually applied to the rest of the sites too.

This would be a PAIN for developers where easier customization feature is not ready for them. The very easy and straightforward solutions to the matter that I can think of are:

1. Clone the application.master and rename it to your own name. Change and apply the custom master page separately.

2. Develop a custom web control that check current SPSite or SPWeb to change master page accordingly.

Perhaps, there are more elegant solutions that can resolve this problem.

Installing Custom Group and Actions in WSS/MOSS Features

Another customization in WSS/MOSS! You can install your own custom feature other than out-of-box features that offered WSS/MOSS. You can add new actions or menus in any location in WSS/MOSS like Site Settings, Site Actions, Item Context Menu, and etc in Standard Menu.

By default, there have 5 groups - Look and Feel, Users and Permissions, Gallaries, Site Administration, Site Collection Administration.

To install new custom feature, create a new folder in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES. I name the folder as MyCustomGroupAndAction. Then we need to create an XML called feature.xml and another xml file that contains the feature definition. (featuredef.xml)

Feature.xml has several elements - <Feature>, <ActivationDependencies>, <ElementManifests> and <Properties> but the important ones are :

1. <Feature> (the root element) - Defines feature ID, scope (site, collection, etc), description and title.

2. <ElementManifests> - defines the feature definition, which links to the xml file that contains the definition.

In feature.xml

<?xml version="1.0" encoding="us-ascii"?>
<Feature  Id="F863C1CF-897D-49c6-8600-7E6F3FC9D653" 
                Title="My New Feature" 
                Description="This is my new feature"
                Scope="Web" 
                xmlns="http://schemas.microsoft.com/sharepoint/">
    <ElementManifests>
        <ElementManifest Location="featuredef.xml" />
    </ElementManifests>
</Feature>

The ID of the feature is unique GUID. You need to generate new GUID for each new feature being created. To generate the GUID, you can go to Visual Studio -> Tools Menu -> Create GUID or launch the tool at C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\guidgen.exe.



The location attribute of <ElementManifests> specifies the location of feature definiton XML file.

In featuredef.xml

<?xml version="1.0" encoding="us-ascii"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomActionGroup
     Id="MyCustomGroup"
     Location="Microsoft.SharePoint.SiteSettings"
     Title="My Custom Group" />
  
 <CustomAction Id="MyCustomFeature"
  GroupId="MyCustomGroup"
  Location="Microsoft.SharePoint.SiteSettings"
  Title="New Custom Feature"
  Sequence="50">
  <UrlAction Url="_layouts/layoutdesign.aspx"/>
 </CustomAction>
</Elements>

The <CustomActionGroup> specifies the definition of new group to be created. Location attribute specifies where the custom group will reside. In this example, "Microsoft.SharePoint.SiteSettings" indicates that the new group will be in the Site Settings menu of WSS sites. Check Location and Group ID in MSDN for more information. Text in the Title attribute is the name of the group.

<CustomAction> is where the custom feature definition set. The location attribute MUST BE same as the location being specified in the group that the custom feature points to (in GroupID attribute). <UrlAction> element merely specifies URL of the custom application page.

It is about to install the feature ! Go to the command prompt, type

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o installfeature -name MyCustomGroupAndActions

The feature has just been installed. However, you need to activate the feature before using it. To activate it, you can type

stsadm -o activatefeature -filename MyFeature/feature.xml -url <server url>

or

go to http://<server name>/_layouts/manageFeatures.aspx, and you will see this



Click "Activate" button to activate the feature. Go to "Site Settings" and you will see this




You have completed installation of new custom group and feature !!

Converting String GUID to System.Guid

Simple matter. I was trying to convert the GUID in string to type of System.Guid and the code below apparently did not work for me.

System.Guid guid = (System.Guid)strGUIDInString;

I was given invalid specified cast error message and I noticed that direct casting wasn't the way. I ended up with

System.Guid guid = new System.Guid(strGUIDInString);

This was the final solution I could think of, so far !

MOSS 2007 and WSS3 Functional Architecture Diagram

Here is the colourful and comprehennsive diagram illustrating the functional architecture of the most latest of Microsoft Office Sharepoint Server 2007 and Windows Sharepoint Services 3.0.

Release of WSS RTW and MOSS Standard and Enterprise Edition

YOu can download the Release-To-Web version of WSS (Windows SharePoint Services) and Microsoft Office SharePoint Server 2007 Evaluation version at

1. Microsoft Office SharePoint Server 2007 x86 English Evaluation
2. Windows SharePoint Services 3.0

CD Keys available for standard and enterprise edition are

SharePoint Server Standard Trial: XJMKW-8T7PR-76XT6-RTC8G-VVWCQ
SharePoint Server Enterprise Trial: F2JBW-4PDJC-HKXTJ-YCKRP-T2J9D

For more resources about installation, upgrade, versioning, check this link, from Microsoft SharePoint Products and Technologies Team Blog

Efficient String Concatenation in JS

In .NET, we use StringBuilder if we need to concatenate strings for better string manipulation performance. For instance,

StringBuilder builder = new StringBuilder();
builder.append("This");
builder.append("is");
builder.append("really");
builder.append("good");
builder.append("for");
builder.append("performance");
  
string str = builder.ToString();

In JS, we can also do the same thing for better memory allocation in string concatenation too.

var builder = new Array();
builder.push("This");
builder.push("is");
builder.push("really");
builder.push("good");
builder.push("for");
builder.push("performance");
 
var str = builder.join("");

This method will perform faster if the number of string concatenation is huge. THe normal += operator will win, otherwise.

Check Efficient JavaScript for more information on optimizing JS code