Reza Alirezaei’s Blog

In MOSS 2007 , there is a new deployment mechanism which is called “Solution Deployment Framework”. A solution is basically an aggregate CAB file (E.g MySolution.wsp) containing XML instructions and files that needed to be deployed on each fron-end web servers. Cool advantages of using solutions in MOSS 2007 comparing to any other third-party products (like
Odyssey) are:

1) Solutions can go beyond web part deployment to support the deployment of Site Definitions,Feature Definitions, Template pages , Rssources , Global and Bin assemblies .I finally managed to deploy even my custom sharepoint application, which is basically ASP.NET app, using this cool mthod.

2) Solution deployment can be schaduled through out-of-the-box UI and timer jobs.  Here are the steps:

      I) Developers create a solution for whatever they want to deploy. It is going to be in a form of CAB file with the extension of WSP.

      II) Administrator loads the solution and reviews the Code Access Security policies required for this solution

      III) Administrator add/delete this solution to the configuration database

      IV) Administrator  deploy/retract/schadule this solution to be deployed to each fron end web server through a nice UI.

3) Solutions can push deployment files to each front-end web server in a farm.Unlike MSI or other legacy methods , there is NO need of deploying your
files to every single front-end  web server.

4) Solutions can be combined with MSI files to form Hybrid solutions  for accomplishing  more complex deployment tasks. Even in this case there is no need for deploying files to each front-end web server. MSI package can call stsadm -syncsolution ….  to synchronize the deployment in all front-end web servers.

5) Solutions can contain CAS (Code Access Security) policies which makes the Admin’s life much easier and elimiate a lot of disputes between developers and admin for extra level of permissions (Developers work can be given the right permissions as they need and not full trust)

In the process of applying MOSS 2007 Beta 2 Technical Refresh update , you require to uninstall Windows Workflow Foundation Beta 2.2  (Build 3807) and then install Microsoft .NET Framework 3.0 – Release Candidate from http://www.microsoft.com/downloads/details.aspx?FamilyId=19E21845-F5E3-4387-95FF-66788825C1AF&displaylang=en that installs the latest version of Windows Workflow Foundation on your MOSS server. The .Net Framework (dotnetfx3setup.exe) that you will get by clicking on the link above is a small redistributable package that downloads the required components during setup.This means that you need to have an active Internet Connection (or ICS) in your server. Since most of us install Beta softwares on Virtual Machines, and on the other hand sharing the internet between host and guest operating systems is a little bit more of a challenge; you may want to try the .NET Framework 3.0 redistributable package that is available as a stand-alone executable file named dotnetfx3.exe.

If you have any trouble locating this file (as I did), refer to this URL then : http://download.microsoft.com/download/D/C/0/DC09D14E-494D-4E5A-A1BA-783554D9D8FE/dotnetfx3.exe

As far as I know, there is no way to perform a SELECT TOP 10 query on a disconnected Recordset in ADO.NET. However, you can create a DataView over the target table and use the technique described below to extract Top 10 records.  

As you can see in the below excerpt, I am trying to return Top 10 records of my ds dataset using a method called “GetTopTen”. First of all, I have assigned the defaultView of the only DataTable in input dataset named “SITE_DT” to a DataView object and then have sorted the result based on “Total_Size” field. This guarantees that our result (no matter how many records is returned) are always sorted in a descending manner.

Next, I have cloned the schema of first DateTable to another DataTable and added the new DataTable to a completely new DataSet. ADO.NET normally does not let you add a DataTable (neither a DataRow) directly from one dataset to another, so you have to clone it in a way. Finally I’ve just grunt it out the old-fashioned way by looping through each row of the DataView object and adding them to a new DataTable. My method ends by returning the new dataset which contains the Top 10 records based on “Total_Size”. This might not be the best option for you, but perfectly works in my case.

public DataSet GetTopTen(DataSet ds)

{
    Try
   {
    DataView dwDs= ds.Tables[“SITE_DT”].DefaultView;
    dwDs.Sort=”Total_Size DESC”;
 
    DataSet dss  = new DataSet();
    DataTable dt = dwDs.Table.Clone();
    dss.Tables.Add(dt);

    int counter = 0;

    if(dwDs.Count > 10)    
     
     counter = 10;     
    else
     counter = dwDs.Count;

    
    for (int i=0; i < counter; i++)
      {
         DataRow dv = dwDs[i].Row;
         dss.Tables[0].ImportRow(dv);
      }

    dss.AcceptChanges();
    return(dss);

   }
           
   catch(Exception e)
   {
    throw e;
   }

}

I have recently written a report generator for a client that enumerates all the items in WSS lists of a web site and then attempts to count them and calculate the overall size. Unlike many reporting tools out there which only go through list items in document libraries and ultimately through document libraries + picture libraries, my reporting tool, iterate through all the lists of any kind. It goes through all the attachments in attachment-enabled lists like links, Announsment, Custom lists,… and literally counts and calculates the size of not only the actual file, but attachments or items in the catalogs like WebTemplateCatalog, WebPartCatalog or ListTemplateCatalog. Unfortunately SharePoint 2003 does not provide a direct access to the actual files in attachments through SPAttachmentCollection and instead it only returns the URL of the attachments, so I had to use my own trick to loop in each indivitual attachments as described below:

private void ReportInvidualWeb(SPWeb web)
  {
   string fileName=””,fileUrl=””;
   int totalFiles=0, toalSize=0;
   try
   {
  SPListCollection listcol = web.Lists;
  foreach(SPList list in listcol )
  {
   switch (list.BaseType )
   {
   case SPBaseType.DocumentLibrary:
    foreach(SPListItem listitem in list.Items )
    {  

     totalFiles++;      
     toalSize += listitem.File.Length;
    }
    break;

   case SPBaseType.DiscussionBoard:
   case SPBaseType.Issue:
   case SPBaseType.GenericList:
       
    if(list.EnableAttachments)
    {
     foreach(SPListItem listitem in list.Items )
     {    
      SPAttachmentCollection attachmentCol = listitem.Attachments;
      totalFiles+= attachmentCol.Count;
      for(int p=0;p < attachmentCol.Count ; p++)
      {
       fileName = attachmentCol[p];
       fileUrl  = attachmentCol.UrlPrefix + fileName;
       SPFile attachFile = web.GetFile(fileUrl);
       toalSize += attachFile.Length;
      }
     }
    }
    break;

   case SPBaseType.Survey:
   case SPBaseType.UnspecifiedBaseType:
   default:
    //Take the appropriate action
    break;     

   }
  }

   }
   catch(Exception e)
   {
  throw e;
   }
   finally
   {
  //save memory, close the web               
  web.Close();               
   }
  }

I have recently done an extensive research on the possibility of tweaking “Shared Workspace”  task pane for SharePoint and came to conclusion that there is no way of modifying it. I have two reasons to support it :

1) SharePoint 2003 doesn’t have “hide features” in its design model. Everything is shown to everyone ,but actions can only be completed by people who have right permissions. Having said this , I think any mechanism to hide features, on the server side, are not seen in SharePoint 2003 architecture. I went through all the registry keys related to office 11.0 in the “HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0” and “HKEY_LOCAL_MACHINESoftwareMicrosoftOffice11.0” and I could not find any keys in regards to Disabling/Enabling “Shared Document” workspace features.

2) According to my research on the client side, all office applications (like word, Excel and etc) provide a customizable mechanism to end users to customize their environments, but they DO NOT really provide facilities for administrators to lock things down.The “Shared Workspace” pane is not programmable which means that there is not such a real programmability model to override the task pane behavior.

We might be able to write Macros or leverage Policies (as stated in Office Resource Kit) to disable a task pane completely ,but who wants to take this great collaboration feature away from office ?

Look at this answer by Mike Hernandez who is the program manager of VSTO (Visual Studion Tools for Office) Team:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=197143&SiteID=1