Why Fx Cop recommends String.ToUpperInvariant for normalizing ?

I used to normalize strings using lower case from Visual Basic 5.0 era before a string comparison activity. While executing Microsoft FX Cop on a recent SharePoint project, FX Cop rule #CA1308 stumbled upon on many places and recommending to convert to upper case invariant for normalizing.

As usual Microsoft doesn't have proper documentation and I'm just looking for what's the difference between ToLowerInvariant & ToUpperInvariant in terms of performance. Michael Kaplan's blog reveals the difference.

All Microsoft NTFS filesystems follow the normalizing to upper case, so the framework developers just followed the NTFS standards. The NTFS filesystem contains a metafile named $UpCase which is a table of unicode uppercase characters for ensuring case insensitivity in Win32 and DOS namespaces. This $UpCase file contains the upper case conversion table for NTFS file systems.

Now the question is why NTFS is following upper case conversion standards, there are some language scripts which doesn't have lower case letters. So for these scripts if we apply the lower casing logic this will also produce the upper case letters producing a round trip. To avoid this Microsoft seems to follow this upper case standards

Move site collections between content databases using Central Admin

We can use scripted commands to move site collections across the content databases that we all are aware of, Recently I came across an astonishing hidden feature in Sharepoint adminsitration toolkit. 

Batch Site Manager, is that tool which is a hyperlink you will see after installing the toolkit to the MOSS box. This feature should be capable of doing all bulk operartions such as moving, locking and deleting site collections across content databases in a single web application as per MSDN.

Open Central Administration

clicking over the link will open up a new screen as follows and probably you will not see any site collections in the list. You will need to start the statistics aggregation timer job by clicking over "Click here" hyperlink which will populate all your site collections in this page

provide the details such as Target content database, Temporary file location and the schedule to start the job etc.

Yes, it can even send an email upon completion/Failure. So fire and forget. you can see a sample mail 

I did not check this functionality with very huge site collection move activity, if any one carried out please let me know :)

for more information go here

http://technet.microsoft.com/en-us/library/cc508982.aspx

SharePoint Page processing model

This is one of the architectural diagram I'm searching for a long time, finally I found it in MSDN

1. The browser requests a Web page from Microsoft Internet Information Services (IIS).

2. IIS passes the request to ASP.NET 2.0.

3. An HttpApplication pipeline is created for the request.

   a. This request will be handled by WSS specific module SPRequestModule

   b. Then the processed request will be handled by WSS specific handler SPHttpHandler.

4. ASP.NET 2.0 fetches the page via the Windows SharePoint Services 3.03 file provider. ASP.NET passes the URL to the file provider, and the file provider fetches the page and returns the page stream. The Windows SharePoint Services file provider implements caching and reduces round-trips to the database.

5. ASP.NET loads a Page class, parses the page stream, and finds a reference to the page layout upon which the page is based.

6. The ASP.NET engine compiles the page stream and stores it in memory.

7. ASP.NET queries the Windows SharePoint Services file provider for the page layout.

8. ASP.NET loads the stream for the page layout associated with the current page.

9. ASP.NET compiles the page layout and stores it in memory. ASP.NET can free this memory later if the system needs memory.

10. ASP.NET determines the master page for the site and fetches the master page via the Windows SharePoint Services file provider.

11. ASP.NET compiles the master page and writes to the disk so you never have to recompile the master page unless you modify it.

12. The page layout runs each control on the page in the context of the page that was requested.

13. ASP.NET updates the necessary caches.

14. IIS returns the page to the browser.

The next time the page is requested by the same user or by a different user who has the same permissions to see the page as the first user, page processing is much more efficient:

1. The browser requests a Web page from IIS.

2. IIS passes the request to ASP.NET 2.0.

3. An HTTPApplication pipeline is created for the request and hits the HandleRequest.

4. ASP.NET uses all the internal caches.

5. ASP.NET renders the HTML for the controls.

6. IIS returns the page to the browser.