Is the sharepoint developer technically “equipped” to create custom dev and vise-versa applications?

Question

This may be an opinion-based question, but this is what I wanted to ask (even if it ends with a closure or deletion).

I am using a user dev application (asp.net/aspMVC) and have absolutely no knowledge about sharepoint and wondered:

If you have a “terrific” user application, can asp.net/aspMVC web developer easily move on to sharepoint development? What about the other way? Does an experienced sharepoint developer have cuts to create a custom application using asp.net/aspMVC?

By no means do I want to offend sharepoint developers or custom application developers. I'm just trying to understand how much knowledge you can take with you when you move from one type of development to another.

Answer 1

I recently put a very strong .NET member from my team through the SharePoint learning process, and let me tell you its small task. The problem is not so much in getting to know the SharePoint object model or the architecture of the product (he was very familiar with the latter), the more he understands the “SharePoint method” for doing things.

Let me expand a bit; the main thing is that the concept of working locally on the host system comes out of the window, so you need to work either with VPC (which you may need to build from scratch) or with a server on which the appropriate development tools are also installed. Some people even run the Windows server product directly on their host computer, but you want it to be pretty dedicated when it also includes starting SQL Server and SharePoint on your PC.

The following is not just a matter of opening a SharePoint site and writing code against it, much less a question of creating separate websites and features that can then be deployed. This is also due to some very obscure settings for the XML files, which, if they are not executed correctly, 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 “published” option, such as youd, with a normal ASP.NET environment, but an intricate deployment and activation process.

SharePoint does a lot of things very well, but when it comes to writing custom applications, it has an uncanny ability to do things that are usually very simple, extremely complex. You reach a large number of intersections where either the SharePoint path or the highway is located, and if you do not know about this in advance, you are at serious risk of the effort required to blow. Do not get me wrong, this is a great product, I just say that I don’t approach it with the attitude of “its just .NET development” and expect everything to go smoothly.

IMHO, this is a very big leap for the .NET developer, and should not be accessed unless you are serious about moving to SharePoint. At present, I am completely clear in my environment that if someone does not have real development experience in SharePoint, they should not jump and “learn from work”; the risk is too high.

By the way, there is a good question called What are your biggest Sharepoint complaints you should read.

Answer 2

I know (a little) about SharePoint, and pretty much you can use code in SharePoint if you are .Net code.

There are (many) quirks you need to know, though.

• WebParts for one. These are available in WebForms, but they take on a new meaning in SP.
• How and where pages are stored. SP, if you make changes to the standard page, it saves the modified pages in the database and refers to it from there, so if you look at your file system for your file, you will find it, but it will be the wrong one.
• I think the life cycle of a page may be a little different, but don't quote me on this.

Just to name a few.

To summarize, although I don’t think you can just dive in and start coding. I think your best option is to either get an SP developer to teach you, or take a course.

I took the SP course, and to be honest, I still don't think I can just dive right in and figure it out.

SP strictly punishes you when you do not do SP actions.

Answer 3

I am in this position and fall into MOSS (I am certified for configuration), but this is not easy to understand, since new concepts appear when developing for MOSS (for example, production of web pages). BUT this is just a new process and a lot to understand about MOSS and how it works.

My limitation is not enough Sharepoint 2007 at work, so obviously I will lag behind creating webpart, etc. But that’s why I’m going to install the software at home.

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

If you are Sharepoint code, I think Winforms is easier, so you can switch to this normally. ASP.NET and Sharepoint 2007 share many concepts, since Sharepoint is a very advanced ASP.NET web application, so you can move from MOSS to ASP.NET.

Answer 4

I have been developing Sharepoint applications since 2002 and have successfully completed dozens of projects on it, starting from.

Starting with WSS 3.0 / MOSS 2007, most Sharepoint technologies (aka web pages) have been included in .net; therefore, application development has changed a lot: you do not need to have SPWeb for breakfast, but being a regular ASP.NET developer and having a pragmatic approach to learn about content management is enough.

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