What's wrong with SharePoint
Whats wrong with SharePoint
from a developer point of view?
- It’s somewhat unreliable in it’s deployment of files.
- Takes a lot of time to install/uninstall a package.
- Not a modern approach to package management. Its basically a cab file with files and xml describing it.
- How do you test the deployment of configuration?
- How does it work exactly? You have to observe the result … It only works when you use it the right way and you don’t get much in error messages.
- Deploying the right way is frikkin hard. But, if you expect the tools for sp to work without crashing your site, you better do it the right way.
- From line of code to result. Could this be described as lead time of changing a line of code to viewing the results of it in the interface?
10 min or more if you’re unlucky. This means that the roundtrip is not comparable to a clean site in asp.net.
Not even a mediocre web platform. Its written for intranet. This shows.
Running code in SharePoint context can be up to 10 times slower for the same dll.
Security. Some of the problems with SharePoint are related to security. It adds to the complexity.
- You need to mark your controls as SafeControls.
- Can get you thinking that GAC deployment is a good idea. Also you need to be aware of asp.net security configuration and what you may do. If you put things in GAC without very good reason do not complain if visual studio crashes, your projects use obsolete versions of your code, your build crashes.
- Huge. There looks like there at least 3 ways of doing things, and they are all for slightly different scenarios. This is an issue. You have to learn a lot of SharePoint concept in order to get the job done. You have to do extra work to introduce for instance an asmx.
This is not helped by asp.net being a leaky abstraction for producing web sites/apps. It can work well if you accept the behavior and limitations of of asp.net. Problem is that it’s not often that people are satisfied with this. Thus it may help to move to asp.net mvc for a simpler more web centric view.
- If you’re supposed to develop web, it’s not a good experience.
Compare this to a regular asp.net web app/ site.
How do you improve the experience?
Conventional wisdom apply:
- Testing your logic using automatic tests is valuable. Even more so since any changes take a lot of time to enter into SharePoint.
- If you can simplify by faking SharePoint functionality
- Writing web in regular web and move it using merge or generation
- Write simpler versions of SharePoint classes.
Some other helpful tips may be:
- Wspbuilder can be a good starting point. It can help you by automatically registering safe controls. Ms commerce extendability project can show you how to do it without the tool. Some of the uses for this tool might become obsolete with the introduction of Visual Studio 2010 and SharePoint 2010 (might not save your bacon though). I’ve not tried this, only read it on blogs. It might help you to understand what the tools generate.
- Be pragmatic when it comes to configuration. Don’t hesitate to use a merge program when your configuration feature fails. Unless of course your client will use the wsp on a SharePoint farm.
- Put your code behind wcf services so that the configuration and context is outside of SharePoint. Less configuration helps. Also the separation of your code and the executing context in SharePoint help you configure security easier.
- Don’t be stressed if it takes time. Read up on the things your working with (try to ignore the rest).
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a
fork of this post and do a pull request on github.