Tuesday, May 12, 2009
1. Unsigned types should not be part of the public interface of the class.
What this means is public fields should not have unsigned types like uint or ulong, public methods should not return unsigned types, parameters passed to public function
should not have unsigned types. However unsigned types can be part of private members.
2. Unsafe types like pointers should not be used with public members.
However they can be used with private members.
3. Class names and member names should not differ only based on their case.
For example we cannot have two methods named MyMethod and MYMETHOD.
4. Only properties and methods may be overloaded, Operators should not be overloaded.
The above-mentioned rules should be followed only for the types and member that are
publicly exposed by your program. Private classes, private methods and local variables need to follow the rules.
By default the C# complier does not check for CLS compliance of the code.
We should explicitly make the C# compiler check for CLS compliance by using the CLSCompliantAttribute class. By specifying the value of true to this attribute we specify that the C# compiler should check for the CLS compliance of the code. The CLSCompliantAttribute can be applied to assemblies, modules, types, and members.
To make an assembly CLSCompliant, add the following line in the AssemblyInfo.cs file of that project -
Friday, May 8, 2009
When you create a site collection in SharePoint based on the OOTB starter template "Collaboration Portal Template" you get a series of sub sites such as "Document Center", "News", "Reports", "Search" and "Sites". Typically if your organisations has just installed SharePoint or are evaluating SharePoint this "Collaboration Portal Template" is the first place an end user will start their interaction with SharePoint.
One main point to note is that the slight variation of the available templates under the "Publishing" tab in Central Administration and on an existing SharePoint site which has been based on the "Collaboration Portal Template" which is available the first time you create your starter site collection in the Central Administration Site when you first install and configure SharePoint. Typically this is done by your SharePoint Administrator at the beginning.
|Available via Central Administration|
Available via an existing SharePoint Site
I want go into too much details about these templates now since the point of this post is to highlight how you can list all your SharePoint sites in the "Site Directory".
One of the Site Templates that you can use to categorise and view all of your SharePoint sites is the "Site Directory" Template. Often the Site Directory template features and functionality are not used effectively due to the not so apparent configuration options that you or your SharePoint administrator need to configure to ensure that any SharePoint site and site collection created in your SharePoint farm is categorised and listed to provide you with a list of all sites. Effectively you can almost create a global categorisation of all your sites in your SharePoint deployment.
This process involves some thinking and a few configuration options that I will highlight. Scenario: You want to create a single list of all your SharePoint site's that are being used in your organisation and you also want to minimise the overhead of categorising these manually. You also want your users with rights to create sites the ability to categorise the sites they create when they are creating them.
Master Site Directory
To ensure that any site and site collection being created within your SharePoint farm is listed in your "Site Directory" you need to add/configure the URL of your "Site Directory" in Central Administration. Go to Central Administration and to the Operations Tab. Under "Global Configuration" click on "Master site directory settings".
Once the URL of your master site directory has been set you can enforce the listing of new site collections in the Site Directory and ensure that you capture the correct Categorisation meta data for your sites. This settings effectively provides the Global location for your Master Site Directory. You may think that this is all it's required to list all the sites in the Site Directory but you also need to configure this at your site collection level in your deployment.
Site Directory Settings
Next step involves that you configure the "Site directory settings" to capture site categorisation when users create sites in an existing site collection. Go to Site Settings and select "Site directory settings".
Once you configure the settings in the next screen accordingly you can enforce your site's to be listed in the Site Directory and capture the correct meta data against your sites. One decision that you may need to make is if you should allow users to create "Site Collections". Site Collections effectively provide isolation and portability. In large deployments particular types of sites depending on their use and functionality maybe better created as Site Collections. For users to be able to create site collections Administrators need to enable "Self-Service Site Management" for the SharePoint web application.
Once you enforce the listing of sites and site categorisations any site that is created by an end user will always be listed in the "Master Site Directory" .
To add some context to this consider this scenario. In my example I have a SharePoint Intranet/Portal where all employees are directed to access organisational information. The Intranet/Portal provides access to various functional business applications such as Collaboration sites and document management sites etc. The URL of this SharePoint site is http://intranet/ In this deployment my SharePoint Administrator sets the Global Site Directory setting URL as http://intranet/SiteDirectory in Central Administration. I want all sites created within my organisation to be listed in this directory. Since I am the "Owner" of the Intranet I can enforce this at the Intranet/Portal level.
Furthermore certain departmental leads have the "Create Site Collection Permission" and are allowed to create own "Site Collections". The authority to create site collections is delegated by IT to these groups. Since the global setting enforces all sites and site collections to be listed in the "Site Directory" users are able to find any new site that is created in my deployment.
Also any new SharePoint web applications that are created in my Farm can be effectively listed in the Global Site Directory since the global setting enforces new Site Collections created via Central Administration on the same Farm to be listed in the Site Directory. When a new Site is created under the existing site structure the site can now be categorised and listed in the "Site Directory"
Once the site is created the site is listed under the correct Category.
Site Directory Links Scan
Another most often overlooked functional part of maintaining the Site Directory is hidden away in Central Administration. This is called "Site Directory Links Scan"
Effectively you can check for broken site links and get a report as well as update your site description listings in the Site Directory using Site Directory Links Scan. Site Directory Links Scan is available via the Operations tab in Central Administration.
The site property update is automated to reflect any changes you may apply to how the sites are categorised and listed in the Sites list in your Site Directory.
Once you have enabled Site Directory Links Scan you can also go to your SharePoint Site and from your Site Directory site select Site Settings and "Scan for Broken Links" which will initiate a manual scan. This will search the "Sites" list located in the Site Directory site for any changed or broken links.
The scanner will provide you with options of what View you would like to scan and update you of the Scan progress.
Thursday, May 7, 2009
On the top navigation bar, click Operations.
On the Operations page, in the Global Configuration section, click Site directory links scan.
On the Site Directory Links Scan page, in the Choose views to scan section, type the URLs of the site directory views that you want to scan for broken links in the Site directory view URLs box (for example, type http://[ServerName]/sitedirectory/lists/sites/allitems.aspx). Separate the URLs by using commas.
The site directory is updated the next time that the site directory timer job is run. By default, this timer job is scheduled to run daily.
In the Update Site Properties section, select the Update title and description of links in the site directory automatically check box if you want the site directory links scan to automatically update link titles and descriptions.
This overwrites previous title and description values in the site directory.
Use the command line to schedule the site directory links scan to run automatically
You can use the Stsadm command-line tool to schedule a job to run the site directory links scan.
You must be a member of the Administrators group on the local computer to use the Stsadm command-line tool.
To use the command line to schedule this job, perform the following steps:
On the drive where SharePoint Products and Technologies are installed, change the directory to %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin.
At the command prompt, type stsadm -o setsitedirectoryscanschedule -schedule recurrence string
The recurrence string indicates the frequency or the date and time at which to run the job.
every 5 minutes between 0 and 59
hourly between 0 and 59
daily at 15:00:00
weekly between Fri 22:00:00 and Sun 06:00:00
monthly at 15 15:00:00" "yearly at Jan 1 15:00:00
To view the current schedule for this job, you can use the following operation:
stsadm -o getsitedirectoryscanschedule
1) create a new User Control
2) Drag an Update Panel to the form
3) place whatever controls you need inside the Update Panel
4) save your work
5) Create a Folder called "User Controls" in your WSS web directory (inetpub\wwwroot\wss\80\User Controls (not exact))
5) Copy your User Control Files to your WSS 3.0 User Control Directory
6) Install the feature (Return Of smartpart v1.3) from site Collection feature.
7) Add a New Web Part (SmartPart with AJAX) to your page
8) Open the SmartPart control panel and use the drop-down list to find your "User Control"
Monday, May 4, 2009
and if you really intuitive to drill down this tool and want to inspect how it works and want to make something more better based on this tool, you have the source code to download(SandCastleSource.zip).
At that very moment I thought it must be a pluggable component (like other VS 2005 add-ins ) in VS 2005 environment. But, I didn’t found anything in VS2005 environment, so I was a bit confused (how to start and where to start?). I thought if there is some Hello World kind of thing, then life will be easy.
So I inspect the installation folder (in my workstation C:\Program Files\Sandcastle this may vary depending upon the desired location you have installed SandCastle). I found an folder Named as Examples, (so the total path becomes C:\Program Files\Sandcastle\ Examples). Inside Examples folder you will a folder named as generic (so now we are at C:\Program Files\Sandcastle\Examples\generic).
Here you will find an exe named as SandcastleGui.exe [Fig 1](That’s what I was searching for, a GUI based tool which will provide me the desired document without any long configuration change or alteration.)
1. Open the project for which you want to make the documentation
2. Open the Solution Explorer and right click on the project node and select Properties from the context menu.
3. Visual Studio will open a property page for the project.
4. Now select the Build tab, from the left navigation pane. In the right Detailed pane check the XML Documentation File check box.
2. Now, save this project properties page.
3. Now we need to generate the assembly as well the xml comment file for this assembly.
4. Right click on the project node and select Build option from the context menu.
Now we are ready for the code document generation using SandcastleGui.exe
1. Double click the SandcastleGui.exe to run.
2. It will open a window something like-
a. In the first segment (Assemblies) we need specify the assembly file for which we need to generate the code document.
b. The second segment (Comments) we just need to specify the XML file (the file we created during the build process of our assembly.)
c. The third segment is the dependent assembly.(which is optional, only valid for dependent assemblies)
d. Now, specify the name of the document file to be generated (Under Options section fill the name text area)
e. Now select the default target (I’ve checked the Chm check box to get the help file as .chm file).
2. After performing the above step (step 3), the UI will look something like -
2. The Log portion shows all the activities which are currently performed by the utlitity.
3. After sometime (it takes a bit time to generate the .chm file depending upon the assembly and dependent assembly) a build finished dialogue box will open and the chm file is ready.
4. Now to locate the .chm file by inspecting the last log entry