The Web Part has the following features:

• Search SharePoint lists – perform advanced searches on any SharePoint list or library using metadata
• Generate reports based on SharePoint list items – export to print-friendly pages or Word documents
• Adaptive styling – works with any SharePoint 2010 theme and styling
• Open-up SharePoint list items on the search result screen

You can download and try the product today!

You must also take into consideration the following use-cases that your web part will participate in:

• From the site’s Web Part Gallery, clicking the web part and rendering it in “Preview mode”.
• When editing the page that has the web part in SharePoint Designer 2010, that the web part renders properly as a user-control.

I want to focus on properly rendering the Web part in SharePoint Designer because this is a use-case that can be commonly missed. Today, I was testing a web part I am developing for Zenpo Software Innovations when I encountered the following error in SharePoint Designer 2010:

“Error Creating Control” – what does that mean?

The web part’s OnLoad and OnInit event-handlers didn’t check that the page is in “design mode”. So, it tried to render its content as if it was in browse-mode.

The web part uses custom JavaScript. I have to register the scripts in order for the web part to use them. I implement the script-registration during the OnInit event of the web part like the following:

        protected override void OnInit(EventArgs e)
        {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                     scriptRegistered = false;
                     Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
        }

This script registration code works fine on the web browser. The problem is when this code is invoked during SPD-editing of the web part page, Page.ClientScript.GetWebResourceUrl returns empty string (under normal browsing state, it would have returned the URL to the WebResource.axd file). And you cannot pass an empty string URL to the Page.ClientScript.RegisterClientScriptInclude method (it will throw an exception if you pass an empty URL). The web part really had no business trying to register scripts during design-time.

You might say to yourself, “this shouldn’t be an issue since Web part pages are edited through the browser anyway”. Think again! Web designers at your organization will use SharePoint Designer at some point to edit SharePoint pages and if your web part cannot handle “design mode” correctly, the designers will see the ugly “Error Creating Control” in SPD. You cannot instill confidence in the use of your web part if it’s throwing exceptions in SharePoint Designer!!!

So, how do we fix this? You can use the one of the following or both:

• SPContext.Current.IsDesignTime
• Control.DesignMode

I found this Microsoft SharePoint Designer Team Blog post that has nice explanation on how to create “designer friendly controls”. SPContext.Current.IsDesignTime and Control.DesignMode are mentioned in that blog post.

First, I modify the OnInit event-handler such that I register scripts only when “not in design mode”:

        protected override void OnInit(EventArgs e)
        {
            if (!this.DesignMode && !SPContext.Current.IsDesignTime)
            {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                    scriptRegistered = false;
                    Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
            }
        }

After deploying the modified Web part, we check SharePoint Designer and the errors are gone:

SharePoint Designer Errors - Gone

Yes, the errors are gone but we need to display something where the web part(s) are embedded. If the web part in on the page, the designer should render something there; it can’t be just white-space.

In order to render something in “design mode”, we override the Render method of the web part:

        protected override void Render(HtmlTextWriter writer)
        {
            if (this.DesignMode || SPContext.Current.IsDesignTime)
            {
                writer.Write("<input type="button" value="Web part is in edit mode..." />");
            }
            else
            {
                base.Render(writer);
            }
        }

If the web part is in “design mode”, we render a simple HTML button. Otherwise, we let the base class (WebPart) handle the rendering. Deploy the updated web part and you should now see the following in SharePoint Designer:

Render HTML button in Desing Mode

To summarize, you will want to render web parts correctly in designers such as SPD 2010.  The likelihood that Web designers will edit SharePoint pages in SPD is high enough that you will want to “design mode” for your web part to run properly.

protected override void OnPreRender(EventArgs e)
{
   if (this.Page != null)
   {
      if (string.IsNullOrEmpty(SelectedListName))
      {
            placeHolderLiteral.Text = "
Web part is not configured. Please <a href="\&quot;javascript:MSOTlPn_ShowToolPane2Wrapper('Edit',">edit the Web part</a> and choose a list or library.

";
      }
   }
}

In the example above, I render a “please configure the Web part” message whenever the SelectedListName of the Web part is not set.

I’m currently developing a Web part for SharePoint 2010 and I wanted to have a “configure” link displayed for the Web part whenever Web properties (i.e. list name, view ID etc.) are not set or specified . I embed a code similar to the above snippet where I use MSOTlPn_ShowToolPane2Wrapper. It didn’t work!

So, thinking like a developer, I observe how the out-of-the-box Web parts render an “open tool pane” hyperlink. I add an Image Viewer web part to a web part page and look at the structure of the hyperlink. Here’s what I saw:

I replaced my output code in my web part class from MSOTlPn_ShowToolPane2Wrapper to ShowToolPane2Wrapper and it works!
Please note that I encourage that you put ‘this’ (object) as the second argument instead of ’129′, or ’16′ as you see in some blogs out there. The second parameter is supposed to indicate which Web part to edit. Do you really know at run-time that your Web part is ’129′ or ’16′? You don’t! So simply use ‘this’.

It’s so easy to do a “Hello World” Web part project now. These days, my Hello World projects typically involve opening up a database table and displaying records in a table. I was able to do this with minimal coding and got it up and running—a full blown Web part—in under 15 minutes!

I created a sample project that opens up the AdventureWorks database and displays employee records in a table:

Sample Visual Web Part Project using Adventure Works Database

The Web-part looks like the following when used inside SharePoint:

AdventureWorks Employees Web Part So far, I like it!Here are my first impressions:SharePoint project templates come out-of-the-box install of VS 2010. After installing VS 2010, the SharePoint project templates are ready for use. No need to do installations of VS-extensions.SharePoint Project Templates in Visual Studio 2010

• The Visual Web Part project cannot be deployed as a “sandboxed solution”. It has to be deployed as a farm solution.
• Project-debugging became a lot easier even with a full-blow farm-deployment. Press F5 in the VS 2010 IDE and Visual Studio will build, package, deploy, and activate your feature, and launch the debug-browser all in one click! When you’re done debugging, terminate Internet Explorer, Visual Studio will deactivate and retract the solution out of SharePoint.
• IIS-reset (for the target Web app) even for full-blown deployments when debugging is fast!
• Remember in VSeWSS 1.3 where you had to Google first how to specify the group the Web part appears in because it wasn’t so obvious? Well, it got easier in VS 2010! Now, the Elements.xml file has a place-holder for the Web-part group. All you have to do, is change it from “Custom” to whatever value you want it to be. It’s so visible now you can’t miss it.

Web-Part Group Place-Holder in Elements.xml File

• You can now add Web User Controls (ASCX files) into the project! As a matter of fact, the project template adds one ASCX file for you. This just made Web Part development a HECK of a lot easier! This is HUGE! Back in VS 2008 developing SharePoint 2007 Web parts, there were no designers available. If developers wanted to use ASCX files, they had to create regular ASP.NET Web apps, design the ASCX files there, write the code-behind, compile the project so the code-behind logic gets packaged with the ASCX files, deploy the ASCX files to UserControls folder within the SharePoint virtual Web app folder, deploy and enable Smart Part, add a Smart Part Web part to the SharePoint pages, then finally, hook-up the Smart Part to the ASCX files. Whew!!! Talk about LOTS of steps! In VS 2010, you don’t need Smart Part or that lengthy way to integrate ASCX file in SharePoint anymore. The challenge of “imagining” what your Web part will look like as you write your C# code is no more. The designer is built in to the Visual Web Part project. Leverage your ASP.NET skills to the max.
• Despite all the improvements, Web part development veterans should recognize familiar concepts and project files such as Elements.xml, .webpart file, strong-named key file, packages and features. 

I have many ASP.NET developer friends who didn’t want to get into SharePoint development because:

• The Web part project wasn’t easy in SharePoint 2007. No designers, hard to design a visual element.
• ASP.NET developers got accustomed to easy debugging of their projects by simply pressing F5 key or the play button on the IDE toolbar. In 2007, ASP.NET developers thought deploying the app and then attaching to the w3wp.exe process (multiple manual steps, not one) was too cumbersome.
• It took forever to even debug the code because the SharePoint Web app always recycled on deployments.

If you are an ASP.NET developer contemplating if you should try SharePoint development, I highly recommend you try it NOW! SharePoint 2010 development feels like traditional ASP.NET development more than ever!

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!

Most objects in ASP.NET Framework are allocated/deallocated in memory automatically. However, there are objects that inherit from the IDisposable. You have to explicitly dispose objects that implement the IDisposable interface or you will run the risk of memory leaks. Some examples of ASP.NET objects that implement IDisposable include Connection, Command, Adapater, and Reader objects (in the System.Data namespace). You can perform any of the following to dispose these objects properly:

SQLConnection connection = new SQLConnection(connectionString);

//use the connection object here

connection.Dispose();

Or, you can using the using statement:

using(SQLConnection connection = new SQLConnection(connectionString))

{

                //use connection object here

} // don't have to call Dispose(); the using statement will dispose connection correctly

When working with SharePoint API (SharePoint .NET libraries and not the SharePoint Web services), it is important to know when and when not to dispose SharePoint objects. If you do not dispose objects in SharePoint, your server will run the risk of memory leaks which can lead to performance issues. If you dispose objects that you’re not supposed to call Dispose() on, you might inadvertently kill the SharePoint application! For example, the following code will definitely kill the SharePoint Web application:

SPContext.Current.Web.Dispose(); // expect calls to your help-desk with this line in your code!

If you are the custodian of the SharePoint farm, you might want to use the SP Dispose Checker Tool to ensure that the custom .NET assemblies being installed on your farm will not cause memory leaks.

For complete guidance on when and how to dispose SharePoint objects, you can read the SP Dispose Team blog.

Solution Explorer in VS 2008

In order to see the manifest.xml or feature.xml file, you have to look at the “WSP View“. WSP View can be accessed by going to the menu and hitting View–>Other Windows–>WSP View. The WSP View looks like the following:

WSP View

The manifest.xml file doesn’t contain “product description” type information. The manifest.xml contains assemblies and features information. The feature.xml file, that on the other hand, start containing “description” type data. Here’s what the feature.xml contents typically look like:

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="cfc5cfdd-62cf-4d98-aeba-e1b38ec6f64f"

             Title="HelloPart"

             Description="A Web part that wants to say hello to you."

             Scope="Site" Version="1.0.0.0" Hidden="FALSE"

             DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="HelloPart\HelloPart.xml" />

    <ElementFile Location="HelloPart\HelloPart.webpart" />

  </ElementManifests>

</Feature>

See that Title and Description attributes inside the Feature element? They will get displayed in the Site Features Gallery: 

WP Title and Description in the Features Gallery

What about the Web part file (in the example I’m using above, the filename is HelloPart.webpart)? What information can be customized and modified here? First, let’s take a look at the contents of the webpart file:

<?xml version="1.0" encoding="utf-8"?>

<webParts>

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

    <metaData>

      <!--

      The following Guid is used as a reference to the web part class,

      and it will be automatically replaced with actual type name at deployment time.

      -->

      <type name="247ef4d4-489d-46d1-a628-8d8daa6267a3" />

      <importErrorMessage>Cannot import HelloPart Web Part.</importErrorMessage>

    </metaData>

    <data>

      <properties>

        <property name="Title" type="string">Gabe's Hello Web Part</property>

        <property name="Description" type="string">HelloPart is a user-friendly Web part....</property>

      </properties>

    </data>

  </webPart>

</webParts>

Inside webPart–>data–>properties section, there are property elements. The first one is the “Title” and the other is the “Description“. The values for “Title” and “Description” contained in the webpart file are what gets displayed in the Web part catalog:

WP Title and Desription in the WP Catalog

Finally, let’s take a look at the Web part XML file (in the example I used above, the filename is HelloPart.xml). The Web part XML file contains the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

    <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary" />

  </Module>

</Elements>

See how the File element doesn’t have any children? We can put a Property element as a child of the File element. This Property element will contain the “Group” the Web part appears in the catalog. By default, like the in the Web part XML file example above, the Group is not specified and therefore, the Web part gets listed under Miscellaneous Group in the Web Part catalog. If you want the Web part to appear in a group other than Miscellaneous, transform the Web part XML file from the above example to the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

        <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary">

              <Property Name="Group" Value="My Stuff"/>

        </File>

  </Module>

</Elements>

We added the Property element below the File element. The Name attribute of the Property element should have a value of “Group” and the Value attribute is the group name you want the Web part to appear in the catalog. In the example above, after the Web part gets deployed, the Web part appears in a category called “My Stuff“:

Web Part appearing on specified Group

If you are developing Web parts, you will want to be able to check the state the Web part is in so that you can render content (controls and literals) appropriately. So, how do you check the different states of the Web part? You can check using the following:

(*Note: “this” that you see below is a reference to the Web part class. In other words, the expressions listed below are applicable only when inside the Web part class code.)

• WebPartManager.GetCurrentWebPartManager(this.Page).DisplayMode.Name – this property is a string with the following possible values:
  • Catalog – this is the value of DisplayMode property when a user initiates the ”edit page” command on a Web part page.
  • Edit – this is the value of DisplayMode property when the user initiates modifying the Web part.
  • Design – this is the value after the OK button is clicked on the Tool Pane (after editing the Web part properties in a Web part page).
  • Browse – browsing the Web part in a normal fashion.
• this.DesignMode – the value is true when editing the Web part page containing the Web part is being edited in SharePoint Designer.
• this.IsStandalone – the value is true when the Web part is not contained in a Web part zone. This is typically true when you’re viewing the Web part in preview mode in the site collection Web part gallery.
• WebPartManager.GetCurrentWebPartManager(this.Page)  – the object returned by this method will be null when the Web part is being previewed (in the site collection Web part gallery)

Checking the state of the Web part is useful when deciding what to render. For example, during regular browsing mode, the Web part will render the normal Web part contents. But if the Web part is being rendered in SharePoint Designer, you might want the Web part to render a “Preview command button” (the way invisble controls like the AJAX ScriptManager or ObjectDataSource look in layout/design editors).