I say both!
Recently I wrote about the use of 3rd party tools. I am a big fan of leveraging tools to help me get my work done. But the .NET API is a big playground and there is a lot we can do on our own to simplify our coding lives and extend the framework ourselves. I love to play in this playground as well. And of course, it's not all play. I think I have an idea where my line is with respect to building something myself and just using something that someone else has built.
This line is different for everyone though.
I had an interesting discussion with some people about third party tools after this week's Vermont.NET User Group meeting. Well, the discussion was actually about using the APIs. Someone had brought up their annoyance about the fact that when you drop an asp:TextBox onto a web page, it defaults with the word "TextBox" in the Text property and you always have to change it. As far as I'm concerned, that's not a problem, because the other possibility is to have it blank and you have to change it anyway. Either way you have to change it, but seeing the word "TextBox" on my form is a good reminder to me that I still need to change it! (I need all the help I can get!) Rather than arguing this point, I asked, "well, why not inherit the TextBox into your own control and set your own default Text property". Boy did I get flack for that. The response from many was that they didn't want to have to do stuff like this - dig into the API and create their own controls. They'd rather get a third party tool (or have the TextBox work their way by default).
That wasn't the end of it. Later that night, I got the same rolling eyes when I was talking about using the ASP.NET 2.0 Control Adapters. Again "why should we have to do all that work? Just buy a control!". This is great news for FarPoint, telerik, Infragistics and all the rest (big and small, for a fee or free).
There's such a huge market of people who I guess I might want to call "application builders" or "site builders". They just want to build software for their clients, not for other developers (or for themselves). This is reflected in the simplicity of ASP.NET 2.0, with so much draggy droppy no-code functionality.
But there is a point where the tools don't behave exactly the way you need them to. A perfect example for me was using the new membership controls in ASP.NET 2.0. They got me the functionality I needed right away with no effort. But the more I hammered on the site I was creating, the more I noticed that the membership control as I was using it did not play well with caching. The control wasn't behaving the way I wanted it to. So I took the control off of the master page and replaced it with a Post-Cache Substitution control that was driven by functionality directly from the membership API. It was super easy and now it acts exactly the way I want it to (and became a great demo in one of my sessions, too!)
One of the people who was teasing me for my giddiness about finding these solutions would be stuck between a rock and a hard place here. I know she is a perfectionist. I know she would have not liked living with the behavior of the control. Someone else asked me that if most of the problems I was experiencing were due to caching, why not turn caching off? It's a site that won't get a lot of traffic. But that doesn't really solve the problem for me because what happens when I go to build a high-traffic site? I won't be prepared.
There's no right and wrong here. There's just different attitudes about where people feel like (or are able to) spending their time and energy when creating applications. We have a lot of options. That's the good part!