Did you know: extending Solution Manifest with intellisense

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.

Code Access Security policy template for Visual Studio 2010 SharePoint Developer Tools

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.

Making controls in a Silverlight/WPF User Control private

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.