Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
    
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 Oct 27 '09 at 7:27
add comment

9 Answers

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 :-)

share|improve this answer
    
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 Oct 27 '09 at 7:24
    
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 Oct 27 '09 at 12:12
add comment
  • SharePoint web parts are there for backwards compatibility.
  • For new development we should use the ASP.NET web parts.
share|improve this answer
    
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 Oct 8 '09 at 17:57
3  
Agreed. But the future investment won't be in the "old" SharePoint web parts. –  SPDoctor Oct 9 '09 at 10:45
add comment

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?

share|improve this answer
    
Both versions supports WebPart connections, though in different ways. For example SharePoint webparts can have cross-page-connectons. –  Wictor Wilen MCA MCM MVP Oct 7 '09 at 13:18
    
Oops - forgot that detail, fixing answer! –  Alex Angas Oct 7 '09 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 Oct 7 '09 at 13:36
add comment

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.

share|improve this answer
    
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 Oct 9 '09 at 1:30
add comment

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

share|improve this answer
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 Nov 13 '09 at 11:48
add comment

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.

share|improve this answer
    
To get the ClassResourcePath you can use Page.ClientScript.GetWebResourceUrl() instead –  Wictor Wilen MCA MCM MVP Apr 2 '10 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 Aug 18 '11 at 13:04
add comment

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

share|improve this answer
2  
Yes, that's true. While using ASP.NET WebParts you can use the OOB ASP.NET caching techniques –  Wictor Wilen MCA MCM MVP Oct 7 '09 at 17:10
add comment

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.

share|improve this answer
    
ASP.net webparts handle connections between zones, so that's no restriction. –  Wictor Wilen MCA MCM MVP Oct 29 '09 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 Oct 29 '09 at 14:58
add comment

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…

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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