Is a sharepoint developer technically "equipped" to do custom app dev and vise-versa?

Question

This may be an opinion based question, but it's something that I wanted to ask (even if it does end up getting closed or deleted).

I do custom app dev (asp.net/aspMVC) and have absolutely no knowledge about sharepoint and was wondering:

If you have a "rock solid" custom app dev, asp.net/aspMVC web developer can he jump into sharepoint development fairly easily? What about the other way around? Does a seasoned sharepoint developer have the "chops" to do custom app dev using asp.net/aspMVC?

By no means do I want to offend any sharepoint developers or any custom app dev developers. I'm merely trying to see how much knowledge you can take with you when going from one type of development to another.

Answer 1

I know a (little) about SharePoint and to a large extent you can pretty much code in SharePoint if you are a .Net coder.

There are a (lot) of quirks you need to be familiar with though.

• WebParts for one. These are available in WebForms but they take on new meaning in SP.
• How and Where the pages are stored. SP, if you make a change to a standard page, stores the changed page in a database and references it from there so if you go looking at your file system for your file, you'll find it but it'll be the wrong one.
• I think the page life cycle may be slightly different but don't quote me on that.

That's just to name a few.

To sum up though I don't think you can just dive in and begin coding. I think your best option is to either get a SP developer to teach you or to do a course.

I did an SP course and to be honest I still don't think I could just dive right in and get it right.

SP punishes you harshly when you don't do things the SP way.

Answer 2

I am in this position and getting into MOSS (am certified for configuration) but it is not easy to understand as there are new concepts when developing for MOSS (eg webpart production). BUT it is just a new process and a lot to understand about MOSS and how it works.

My limitation is not doing enough of Sharepoint 2007 at work so obviously I am going to be lagging behind in webpart creation, etc. But this is why I am going to install the software at home.

On the other hand, Sharepoint development is C# and ASP.NET, so in the codebehind/presentation, you have a solid base.

If you code Sharepoint, I think Winforms is easier so you can switch to that ok. ASP.NET and Sharepoint 2007 share A LOT of concepts as Sharepoint is pretty much a very advanced ASP.NET web application so you can go from MOSS to ASP.NET.

Answer 3

I develop Sharepoint applications since 2002 and ran successfully dozens projects based on it, ranging from .

Starting with WSS 3.0/MOSS 2007 most Sharepoint specific technologies (aka webparts) was incorporated into .net; so, application development changed a lot: you don't need to eat SPWeb on breakfast, but being a regular ASP.NET developer and having a pragmatic approach to learn about content management it's enough.

Bottom line: Sharepoint development isn't rocket science; don't be afraid, get a VS2005/8, a VPC and happy coding!

Answer 4

I recently put a very strong .NET guy from my team through the SharePoint learning process and let me tell you, it’s no small task. The issue is not so much familiarity with the SharePoint object model or product architecture (he was quite familiar with the latter), it’s more about understanding the “SharePoint way” of doing things.

Let me expand a little; the main thing is the concept of working locally on a host system goes out the window so you need to work on either a VPC (which you may need to build from ground up) or a server which also has the appropriate development tools installed. Some people even run a Windows server product directly on their host machine but you’d want to pretty dedicated when this also involves running SQL Server and SharePoint on your PC.

The next thing is it’s not simply a matter of opening up a SharePoint site and writing code against it, it’s more a matter of building individual webparts and features which can then be deployed. This also involves some very obscure configuring of XML files which if done incorrectly, can have a very negative impact on the entire environment (i.e. things just stop working). Finally, the deployment process is completely different. There is no simple “publish” option like you’d have with a normal ASP.NET environment rather there is a convoluted process of deployment and activation.

SharePoint does a lot of things really well but when it comes to writing custom applications it has an uncanny knack of making things that are normally very simple extremely complex. You reach a lot of crossroads where it’s either the SharePoint way or the highway and if you’re not aware of these upfront you run a serious risk of the effort required blowing out significantly. Don’t get me wrong, it’s a great product, I’m just saying don’t approach it with the attitude of “it’s just .NET development” and expect things to go smoothly.

IMHO, this is a very large jump for a .NET developer and shouldn’t be approached unless you’re serious about moving into SharePoint development. I’m quite explicit in my environment now that unless someone has real world experience developing for SharePoint they should not be jumping in and “learning on the job”; the risk is just too high.

BTW, there is a good question titled What are your biggest complaints about Sharepoint which you should read.