简体   繁体   中英

How risky is the development in SharePoint 2010?

I'm trying to evaluate SharePoint 2010. I've bought the book "SharePoint 2010 as a Development Platform" from Apress to help me get started with SharePoint (I have C# and ASP.net knowledge)

In the first pages I saw this warning: 'We strongly recommend setting up a virtual server on a physical machine, such as Hyper-V or VMware on Windows Server 2008. [...] SharePoint projects occasionally crash the server during heavy development. Re-creating a virtual machine is much easier than losing your whole personal computer'

which begs the question: How dangerous / risky is SharePoint development? How can I crash the whole server with it?

I have never had to rebuild a machine because of SharePoint. BUT, I can understand the book's claim. The scenario I see is that SharePoint starts acting unexplainably bizarre, and there is no logical course of action to fix it. For example you try everything you can think of, and for some reason everyone gets a 404 to the site, even administrators. If you dig hard enough you find it was because a .resx file wasn't copied during a deployment or something. If you don't dig hard enough, you will be tempted to rebuild the entire machine for the reason of "something happened with permissions probably".

For this reason, I do keep my SharePoint environments in a virtual machine. It comes down to the fact that SharePoint can stop working and it's too difficult to figure out why. If I could enumerate the concrete reasons for this, I would say:

  1. SharePoint's error handling is so bad and misleading .
  2. SharePoint is influenced by every nook & cranny of the system , for example obscure group policy settings, regional settings, etc.
  3. SharePoint is driven largely by "best practices" mentality, and has its own way of doing everything. Some things are still controlled by IIS settings, other settings must be done through SharePoint administration. If you do it wrong, you will just get crazy behavior, not a hint in the right direction. Because SP is so configuration-focused, juggling all these configuration settings is overwhelming. [edit] In other words, SP configuration is not intuitive. Getting SP to do what you want is a matter of following some official recommended practice, not following intuition. In an industry that only thrives because of developers' ability to adapt, improvise, and learn-as-you-go, SP feels more like system administration than software engineering.
  4. Doing things in SharePoint like configuring / deploying can often take a LOT of time, and this can seriously interrupt the problem-solving flow . The amount of time it takes to just haphazardly try something can prevent me from trying things, and cause disorganization in my thought process.

Installing and configuring SharePoint is quite a task. So if anything goes wrong with SharePoint it will take long to reinstall it from scratch. But if you are using Virtual Machine you can install and configure a VM and take its backup. Now when anything goes wrong with your working VM simply delete it and create a new one by copying files from backup of your fresh installation.

Also depends on whether you want to do other things on your dev machine. I do pure .NET development on my dev machine and when I'm doing SharePoint dev I spin up a virtual machine.

SharePoint uses loads of resources and can easily slow a server right down. It can become a pain always having to stop all the services.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM