I find this question a bit strange, and it's ridiculous that people still ask such questions, because they don't understand what the SharePoint is.

SharePoint is just a platform that build on the top of asp.net and is appropriate for the specific needs. It's not a question of taste - use it or not, it's dictated by requirements and architecture.

Asking why asp.net devs wont use SharePoint is the same as asking why asp.net devs wont use AJAX for example ? u use it when it's necessary only

May I suggest adding to the Cons of Sharepoint that a significant issue of the server development environment is running as Administrator whereas ASP.NET development can easily be done on Cassini with a standard user account.

WSS provides a lot of rich features, but it also introduces a lot of complexity.  As far as developing LOB applications I think the cons outweigh the pros for using SharePoint as a development platform (development experiance, need a specialized administrator to manage the enviornment, ...).  Case in point imagine if team had built StackOverflow on top of WSS...  there is no way they would run that on 2 servers and would have been able to deliver that application in 16 weeks. 

WSS is powerful, but for a much narrower purpose than Microsoft (and much of the Sharepoint community) claim. It is not even remotely close to a general-purpose development platform. If your business processes and IA strategy already line up with a WSS-compatible model, then Sharepoint gets some basic DM and collaboration plumbing out of the way for you.

Here are the major reasons I see ASP.NET developers avoiding Sharepoint:

- Steep learning curve. In ASP.NET, any newbie can make a Hello World application in less than an hour and generally grasp what's going on to make that happen. Learning & complexity grow in parallel with the developer's needs. By contrast (and maybe I'm just a little slower than most) - I have been using Sharepoint and MOSS for nearly two years solid and I *still* don't fully grasp what all is happening under the hood between writing a web part and getting it to show up on a page. That's fine for making Hello World widgets, but not for building and deploying complex LOB systems. Knowing ASP.NET backwards and forwards takes up a lot of space in my brain. I can't justify learning something just as vast and complex just so I can avoid writing my own publishing workflow.

- Overly simplistic. Although *getting it to do something* is very complicated, what it *actually does* is remarkably simple. But how many applications actually have a model which maps to a simple tree hierarchy of items? Most applications use an RDBMS because their model doesn't look anything like a file system. WSS emulates a file system on top of an RDBMS. You tie yourself into a pretzel writing CAML which accomplishes the same thing a mid-level developer could write in 2 minutes using SQL. Developers who *do* give it a try will last all of a week before giving WSS the boot and going back to SQL Server. Imagine trying to build Facebook on WSS. And yet in my experience, most applications have more in common with at least some aspect of Facebook than they do with the way WSS works.

- Microsoft has not attempted to sell it to ASP.NET developers. This might be the biggest one. Even something like SQL Server gets sexed up and trotted out at MIX. Any moderately-plugged-in ASP.NET developer can name at least one feature coming up in c# 4.0. WSS is... that thing I read about on some enterprise architecture blog. No developer uses Sharepoint because they want to, they use it because their EA got a ton of literature from MIcrosoft about it and learned all about it at the architecture conference, and got together with the CIO and decided that Sharepoint would be the development platform for the 3-year IT strategy.

Here's a quick list of reasons for my anti-SharePoint development tweet yesterday.

Some background info to give some context:
- I've been a commercial developer for 8 years now. I started in Classic ASP and spent the last 5 years also in working ASP.NET, with the last 12 months in ASP.NET 3.5 working heavily in Visual Studio 2008.
- I follow developers like Scott Hanselman and Jeff Atwood and read books like Pragmatic Programmer. I'm continually trying to improve the overall technical solution quality and the general development experience. I have had to make some unhappy comprimises to get my current SharePoint solution working.
- I have poor recall memory but excellent recognition memory. Unfortunately I'm finding SharePoint development relies heavily on recall for fixes and workarounds (things the development toolsets - ie Visual Studio - should handle for us so we can get on with creating the best possible solution and user experience). By comparison, I find ASP.NET development more "natural".
- I'm heavily focused on software usability, producing the best possible product to meet business needs and improving developer efficiency. I'm finding SharePoint more difficult than need be to meet these goals (especially in caprison to standard ASP.NET development).
- I get frustrated that in 2009 we don't have the tooling (IDEs, Frameworks, APIs, etc) that allow developers to work at the "higher levels" of abstraction I would expect - i.e. that hide the mundane detail.
- My current dissatisfaction with SharePoint extends from both the specific difficulties I'm having with SharePoint as well as increasing diffulty in recent years with development using the .NET Framework and ASP.NET in general. It all combines to make for an unhappy developer.

- 12 months ago I did the MS certification of installation and configuration of SharePoint Server 2007 (Exam 70-630 I think) - I actually haven't worked on any SharePoint project since then. 2 weeks ago I started my first SharePoint development project. I'm developing Features (modules) and a site template using Visual Studio 2008 and need to deploy to an Extranet in [I think] a Farm configuration.

Some the my main gripes with SharePoint development are:
- Tooling: Visual Studio does not have enough integration with SharePoint, especially for testing and debugging. It is try painfail in comparison to ASP.NET development and adds considerable time and pain to the process. Everything seems half-baked.
- The background knowledge required to start SharePoint development and actually know and understand what you are doing is extensive, even for an experience .NET developer. It is hard for experienced ASP.NETdevs to jump across. As it is, I'm just being prodded in the right direction by a more experience developer then Googling for solutions to specific problems and requirements - this "Cody by Coincidence" and "Cody by Google" is not what I consider an optimal learning process for understanding the product.
- I having to perform lots of manual settings/file changes while developing in Visual Studio - eg Web.config and Module.xml. Time consuming, repetative and error prone. It also points to a half-baked product.
- There is considerable time wasted on basic tasks and fixing errors rather than being able to concentrate on important issues, like providing be best solution to the customer business needs.
- At least 50% of my day is currently spent Googling to find solutions to SharePoint errors and other technical problems. The constant stream of errors and friction it places on development is leaving me annoyed and aggavated.
- The whole development process is highly inefficient and has high development friction - there's NOTHING smooth about it (at least that's the way it seems - with the problems overshadowing any good that is coming from the experience).
- .NET and and SharePoint development requires us to deal increasingly in abstraction that hide lower level detail (which I belive is good and necessary), through increasing increasing class base. Yet as developers I find we often have to dig in an know the low level implementation detail in order to understand the abstraction, what it is doing and how to implement it. Again, wasted time, efficiency and cost.
- Documentation in MSDN (actually, much of what comes out of Microsoft in general) is a joke nowadays and often little better than a auto-generated snapshots of the API (which it probably is). For example, I looked up http://msdn.microsoft.com/en-us/library/ms468837.aspx for more information regarding the Location property on the Assembly element and the description I got was "The relative file path of the assembly". Relative to what?!? When I go looking for documentation it means I need a better understanding than what I derice from teh API. Again, it's a frustration that leads to a poor development experience.

Don't get me wrong, I think SharePoint has potential to be a great product for both users and developers and is certainly heading in the right direction. However, from my dealings with it as a user and my current experience as a developer I feel we have a long way to go before polished enough to provide the experience we should be getting.

More comments on stack overflow

totally agree with rex and anon

Hello Jeremy and the Developer Community,

I am not sure this Con is really accurate.

Development Environment
Server development environment required

You can develop SharePoint components with just the DLL's on any computer with pretty much any operating system. For testing you need WSS or MOSS so I can see where some confusion arises in this. It is also important to note that you can run WSS (quite easily) on Vista, and develop on Vista. Thereby allowing you to test, and develop on the same local machine without any need for a server.

Do we have other cons?
The too many options doesn't seem like a Con to me. Really it can be perceived as a pro, or a con. In my experience that flexibility allows for you to develop it in a way that either works best for the specific client/support team, or in a way that is fastest/most cost effective.

I can agree with many of the points made by anonymous. However I don't see how many of these items don't apply to ASP, or other .Net related code. If you haven't read the books, or learned it all in the first place it really represents the same issues (too googling, and recall). Anyways looking forward to anyones thoughts or corrections on my quickly presented opinions.

Thank you,
Richard Harbridge

I have to agree with Anonymous (3). Developer experience is still very poor. Feature wise there is lots to take advantage of but very hard to use due to lack of doco.

I'm going to push on with it simply because despite all the drawbacks it's better than starting from scratch every time with a new Web Application project.

I have been developing ASP.Net from the beginning so like others with a lot of experience even though SharePoint is built on top of the 2.0 Framework you are very limited in what you can do in SharePoint and it is very frustrating.. 

I often equate working with SharePoint to wearing hand-cuffs, there are two main themes which I found very difficult to deal with:

1. Customization

2. No relational database

Although there are templates, and assorted workarounds it is very problematic to customize OOTB functionality through Visual Studio.

2.  Every application I have EVER built was based on relational data, how MS could give you a platform that doesn't effectively allow the standard T-SQL and CRUD functionality is a gross short-coming.

Regardless, "I will build it, because they do come", but I will continue to hope for a better design paradigm.

JL

As others have stated, SharePoint is both a product and a platform. There are engagements when I stick to OOTB capabilities of WSS/MOSS, this is a big turnoff to developers that see such an engagement as administration. Other times that I perform heavy customizations via the APIs. The key is understand the technology stack (takes time), the business requirements, and doing your design and implementation accordingly.

Steven Fowler

I would really like to see SharePoint see a kind of 'service release' similar to Windows 7 for Vista. This release would address the significant pain points in consultation with the community and add some important new features (but not the huge number we had with 2007). The old way of doing things would be deprecated and then removed in the subsequent version.

It really feels like SharePoint is bogged down with some design flaws, and technologies that make it hard to develop for. It would be nice to clear the cruft away.

Source: Sanjay Narang's - Should I Build my application in SharePoint vs. ASP.net
Many times, I get question from my customers if they should build a new application in SharePoint or ASP.net. For certain kind of applications such as Collaboration or KM Portal, Internet facing web site, intranet social networking site, applications requiring browser enabled forms or Enterprise Search, SharePoint is THE option to go for.
However, it's not a straight forward answer for all types of applications. You need to look at different aspects before deciding. I've put a high level list of questions that I use to make such decisions. Hopefully, the questions should help you also.

1. What are the features that you are going to use out-of-the-box (OOB) from SharePoint (site provisioning, search, version control, roles/groups, easy forms (list edit, new, view pages), collaboration, workflows, content deployment, alerts ) )
   1. The list of feature is huge, have a look at evaluation guides for complete list: WSS, SharePoint and Search
   2. If you are not using any of these features what's it that you'd gain from SharePoint?
   3. If you need these features, why are you thinking of not going with SharePoint? What's the effort if you custom build those features?
2. What are the features that I'm going to build custom (for example, reports for some applications would be custom and need relational tables with transactional support)
   1. How much effort is required for custom development in ASP.net vs. in SharePoint? Is the difference huge?
3. What kind of application it is? Is it one off application, or this is going to replicated across many teams. SharePoint is an excellent platform where you need to replicate one type of site to many teams.
4. What are the required Scale and Performance objectives of your application
   1. SharePoint has some boundaries, most of these can be avoided with adjusted design or workaround. Would the adjusted design or workaround be acceptable to your users? Examples:
      1. 2000 list items at a single level – a well know limitation
      2. 2000 security principles for a securable object – a lesser known limitation, but this can create problems when users in a site collection grows more than 2000 – there are workarounds for this (such as using AD security groups) – are those acceptable?
   2. SharePoint may not be able to match the performance of a plain ASP.net application as it does a lot more work (security trimming, getting files from database etc.) Can your performance targets be met using SharePoint?
      1. You can check benchmarks published by Microsoft or other vendors (such as HP, Intel) to see if SharePoint can meet your requirements. Links to most of the benchmarks are available in this blog post: SharePoint (Performance, Stress ) Load Testing 
5. How many employees would be using these application? How many requests you can expect for customization from different teams. Remember, SharePoint provides a pretty good platform for customization and personalization.
6. How much time do you have to build such apps? Can you use some off-the-shelf solutions? For examples, there are many custom applications which be deployed in no time by using WSS Application Templates (http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx)
7. What's the cost you can afford. Remember, you need not buy any separate license, if you are only using Windows SharePoint Services. Have a look at difference of features between WSS and MOSS in the comparison Excel spreadsheet.
8. What skills your developers have? Though SharePoint is based on ASP.net, but you need have additional knowledge to develop SharePoint applications. Also, development is SharePoint is not like normal .NET development (for example, you don't get WYSWYG designer to develop web parts for SharePoint). You also need to take extra care to follow same build and source control process that you do for .Net code. Have a look at Application Lifecycle Management Resource Center for SharePoint Server for more details.

As I don't have WSSv3, I'd like to hear your impressions on it and a discussion on what it delivers. It seems like there's not much documentation on what this thing actually is and what it allows developers to do beyond the very generic best video poker hand frequency and encompassing title of "workflow".How flexible is this engine? Is it in any way related to WWF? What is the featureset of the workflow engine? Is it any good? What are the key limitations? And so on.If you know of other good resources to answer these questions, I think many in the community would appreciate links.
Thanks.

Time for my 2 cents...

I think WSS shouldn't be compared to plain old ASP.NET. WSS is built for a narrow range of solutions and even some of that it doesn't do so well. (did someone mention CMS?) ASP.NET on the other hand will cover a much broader range of solutions.

As for the workflow engine, it's WF. This is the direction that Microsoft seems to be going with workflow. I heard a while back that BizTalk will be implementing it too but not sure on that one.

Early on as I was learning to program against WSS, the thing that really annoyed me was that I didn't control the UI anymore. Rather the data drove it out. It was difficult to get used to.

I'm sure the other thing you may have noticed is that the .NET Framework has moved on a bit since WSS 3 was released (under .NET 3.0). Without a fair amount of work, it's looking pretty dated now.

If you don't "get" SharePoint, it's likely you can't fully digest enterprise architecture. Someone in the thread mentioned "8 years" of development experience. I have 13 years of development experience and I've been around long enough to note that sometimes developers with multiple years of experience can be talking about multiple years of the same. It doesn't count if you keep reliving the same year over and over again. If you're 13 years into a programming career - then you have more-than-likely relived a year on a few occassions. Unfortunately, the ones who shun SharePoint are the ones that need the exposure the most. Take a look at the SharePoint core technologies and architecture. You could learn a lot. Don't be just a code monkey for the rest of your life. Trust me, it gets old. If you want a real challenge, stretch yourself and jump into solutions architecture or go build a device driver or two.

Before you drink the sharepoint coolaide that many here are obsequiously cheerleading for you should read what independent sources have to say about sharepoint.  From a Forrester Research report:

• "(A)s many shops are discovering, SharePoint is also a development platform that people both inside and outside of IT use to create intranets, outward-facing portals, electronic forms, workflows, and even dashboards. The promise of SharePoint: Your organization will be able to create and deploy collaboration applications faster and give businesspeople productive new tools. The pitfalls: SharePoint can add new unplanned demands as your teams fill the product's gaps in application life-cycle management and enterprise integration and as they create policies to prevent a new chaos of usergenerated applications."
• "Forrester noted that "SharePoint is a pure Microsoft server stack that closes off any opportunities to substitute third-party databases, Web servers, and other products for Microsoft components," Forrester cautioned. In addition, the Enterprise Edition of SharePoint, which includes many of the advanced app-development features, "can add $200 per user to your budget," the report's authors noted."
• "The Forrester study provided a fairly lengthy laundry list of app-dev-specific shortcomings in Office SharePoint Server 2007 — everything from the lack of support for SharePoint database replication, to required custom development to include data stored in SharePoint lists for reporting purposes. Application lifecycle management of SharePoint is incomplete, the report authors said. And enterprise data integration for SharePoint is 'primitive.' "
• "Forrester recommended customers keep their SharePoint customizations to a minimum and that they create a comprehensive SharePoint governance policy sooner rather than later."

http://blogs.zdnet.com/microsoft/?p=1492 http://www.forrester.com/Research/Document/Excerpt/0,7211,45560,00.html

Interesting discussion, and in most part ignores the root problem. I've been doing ASP.NET apps for years and after looking at SharePoint have dismissed it for the following reasons:

• Bad db architecture, SharePoint should only hold the simplest of data and i can't get to the database schema.
• WebForms based, scourge of web development.
• If anyone has looked at SharePoint CSS and JS, it is amateur work at best.
• I still have no help with business rules and have to write it myself, I am not counting workflow stuff in SharePoint as any help in this regard.

So I would rather spend a few weeks, develop my own code base, write the application and embed it in an Iframe if I need SharePoint integration as well as use the SharePoint API to interact with SharePoint if requirements call for such interaction.

In summary, SharePoint is too complex, over engineered and badly engineered application to extend. I get more bang for my buck by starting fresh... and if I am a architect/developer worth my paycheck I am not developing authentication, user management, simple CRUD froms, master pages and layouts from scratch every time, so all the benefits of SharePoint only benefit those without vision or decent library set.

I've written an update on this opinion from a SharePoint 2010 perspective too.