12

This is an almost religious question; what are your preferred base classes for building WebParts in SharePoint? Are you using the ASP.NET WebPart (System.Web.dll) or the SharePoint WebPart (Microsoft.SharePoint.dll)?

What are the pros and cons of each respective choice?

I personally like to use the ASP.NET WebPart class!

/WW

Improve this question
1
  • In SharePoint 2010 the Visual Web Parts are based on the ASP.NET WebParts as well as most of the new built-in web parts in SharePoint 2010. Also for sandboxed webparts you have to go with the ASP.NET Web Part.
    – Wictor Wilen MCA MCM MVP
    Commented Oct 27, 2009 at 7:27

9 Answers 9

Reset to default
15

Like Bill mentions, the SharePoint web part is primarily there for backwards compatibility, although it does provide 4 features that are not available in the standard asp.net web part:-

  • Cross page connections
  • Connections between Web Parts that are outside of a zone
  • Client-side connections (Web Part Page Services Component)
  • Data caching infrastructure, including the ability to cache to the database

This information comes from the remarks on the SharePoint web part MSDN page...

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.webpart.aspx

Hope this helps :-)

Improve this answer
2
  • 1
    Thanks Russel, I'm aware of these features, and I have not had any cases when those scenarios fitted and you can work around most of them quite easily using the .NET framework built-ins and client side scripting.
    – Wictor Wilen MCA MCM MVP
    Commented Oct 27, 2009 at 7:24
  • 1
    Yep, me too. I've never found the need to use the SharePoint web part, I've always used the Asp.Net one. :-)
    – Russell Giddings
    Commented Oct 27, 2009 at 12:12
5
  • SharePoint web parts are there for backwards compatibility.
  • For new development we should use the ASP.NET web parts.
Improve this answer
2
  • I can agree on that and SP2010 will probably tell us more about that. But I doubt MS will stop supporting the SP WebParts...
    – Wictor Wilen MCA MCM MVP
    Commented Oct 8, 2009 at 17:57
  • 3
    Agreed. But the future investment won't be in the "old" SharePoint web parts.
    – SPDoctor
    Commented Oct 9, 2009 at 10:45
4

I use the ASP.NET class as that's what Microsoft recommends in Working with ASP.NET 2.0 Web Parts and Windows SharePoint Services 3.0.

I haven't found or seen any good reasons to use one over the other apart from the different feature sets each class offers. That is, advanced web part connections are only offered by the SharePoint web part class.

Perhaps MS hoped the generic ASP.NET web part class would be used more outside of SharePoint?

Improve this answer
3
  • Both versions supports WebPart connections, though in different ways. For example SharePoint webparts can have cross-page-connectons.
    – Wictor Wilen MCA MCM MVP
    Commented Oct 7, 2009 at 13:18
  • Oops - forgot that detail, fixing answer!
    – Alex Angas
    Commented Oct 7, 2009 at 13:33
  • NP :-). As I see it that is one of the few scenarios where you should use the SharePoint WebPart...and seriously how often do you use cross-page connections? I've never created a solution when that was necessary.
    – Wictor Wilen MCA MCM MVP
    Commented Oct 7, 2009 at 13:36
4

There's a few extra reasons for using the ASP.Net WebPart over the SharePoint WebPart.

Basically, the ASP.Net WebPart can be used IF your solution/client/project ever had to shed the MOSS Skin and the decision was made to move from MOSS onto another platform.

Improve this answer
1
  • Agreed, this is the most common answer, but this argument is often killed with the statement that as soon as you add a reference to the SharePoint dlls you could have used the SP version anyways...
    – Wictor Wilen MCA MCM MVP
    Commented Oct 9, 2009 at 1:30
4

when it comes to SP2010, webparts that derive from the SharePoint web part are not supported in Sandbox solutions.

Source: An Overview of the SharePoint 2010 Sandbox Solution

Improve this answer
1
  • 2
    Yup, I've seen that. And also the Visual Web Part derives from the ASP.NET webpart. So my recommendation stands still; use the ASP.NET Web Part when creating web parts.
    – Wictor Wilen MCA MCM MVP
    Commented Nov 13, 2009 at 11:48
4

I'm a bit torn between the two actually, and my reasons are for things that don't often get a mention.

I'm a fan of the ASP.NET web parts .dwp/.webpart xml file schema. I think it's a lot cleaner and you don't have to specify a namespace whenever you specify a custom property value in the file.

However some of the things that (sometimes) make me revert back to the SharePoint WebPart are

  1. GetToolParts() is better than CreateEditorParts()

With GetToolParts(), we could control the standard web part properties, and hide some if we wanted to. I haven't worked out how/if you can do this with ASP.NET WebParts. For example:-

    public override ToolPart[] GetToolParts()
    {
        ToolPart[] parts = new ToolPart[1];

        WebPartToolPart wptp = new WebPartToolPart();

        //prevent detail link and title from being changed
        wptp.Hide(WebPartToolPart.Properties.DetailLink);
        wptp.Hide(WebPartToolPart.Properties.Title);

        parts[0] = wptp;

        return parts;
    }

  1. SharePoint's WebPart.Qualifier was a handy little int value that you could use when you wanted to deal with multiple instances of a web part on a page. Easy to work around, but still handy!

  2. SharePoint's WebPart.ClassResourcePath was good in order to isolate your resources (images, css etc) into their own location and then easily refer to that location from within the web part.

Improve this answer
2
  • To get the ClassResourcePath you can use Page.ClientScript.GetWebResourceUrl() instead
    – Wictor Wilen MCA MCM MVP
    Commented Apr 2, 2010 at 8:04
  • Got To admit I have some old webpart where I wanted control over the settings layouts, but I still use the new way drink the koolaid you cant fight it any longer.
    – BinaryJam
    Commented Aug 18, 2011 at 13:04
2

There is one thing I like about Microsoft WebParts: caching using SharePoint and that is not available on ASP.NET WebParts.

Improve this answer
1
  • 2
    Yes, that's true. While using ASP.NET WebParts you can use the OOB ASP.NET caching techniques
    – Wictor Wilen MCA MCM MVP
    Commented Oct 7, 2009 at 17:10
2

I haven't find a good reason not to use sharepoint webpart.

If my sharepoint project is gonna be on asp.net w/o Sharepoint chances are you'll have to rewrite the entire application either way. ...

It's more likely youll use connections between multiple zones. That actually won't depend on the infrastructure, but on the user dragging the webParts, so I'd go with Sharepoint webparts just because it doesn't have restrictions on WSS.

Regards,

Nicolas.

Improve this answer
2
  • ASP.net webparts handle connections between zones, so that's no restriction.
    – Wictor Wilen MCA MCM MVP
    Commented Oct 29, 2009 at 7:01
  • Right Wictor. I misunderstood Russell's answer. However, I cannot find a reason why not using Sharepoint's Base Webpart class.
    – Nicolas De Irisarri
    Commented Oct 29, 2009 at 14:58
2

My point of view

  1. When we develop a web part for SharePoint environment, better to stick with SharePoint Web Part class.
  2. When we develop a web part which has standalone logic and doesn't depend on SharePoint as such then it is better to do with Asp.Net web part

In general, it is always advantageous to use sub class instead of base class unless otherwise…

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.