SharePoint 2010 ships with Developer Dashboard which allows you to see how well different pieces of SharePoint are performing. And while it’s extremely useful by itself, it becomes even more important when used to measure the performance of your custom code!
Yesterday we had a great evening here at Mavention talking about web standards and accessibility on the SharePoint platform.
SharePoint 2010 ships with a great developer story. The new Visual Studio 2010 SharePoint Developer Tools provide great experience and allow you to be productive while working on SharePoint Solutions. And while these tools ships with rich functionality they obviously don’t cover all new capabilities of SharePoint 2010. In some situations you might need to manually modify some of the SharePoint artifacts like for example when specifying dependencies for your Solution.
SharePoint 2010 ships with the Sandbox: a new concept that allows you to deploy solutions with limited trust. Still there are many scenarios to think of when you might need to deploy your work to the Web Application’s BIN directory. When doing that, you need to define for your assembly a CAS policy, which specifies what your code should and should not be allowed to do. While the contents of the policy always depend on your code, I have noticed that there are a few entries that are common for almost every solution deployed to the BIN directory.
By default, when you create a User Control in Silverlight or Windows Presentation Foundation (WPF) all child controls are publicly available. This is not only bad for reusability of the control but also from the design point of view as you should always try to encapsulate the internals of your control and only make available to the outside world functionality that makes sense to them. Additionally encapsulating properties allows you to validate the input what makes your control less error prone.