The new Visual Studio 2010 SharePoint Development Tools not only simplify working with SharePoint Solutions but are also a great productivity booster. By encapsulating the internal working of packaging SharePoint artifacts developers can focus on the development process instead of keeping the track of what should go where. One of the productivity features of the new developer tools is automatically adding project items to Features: each time you add a new SharePoint Project Item (SPI) to your project the tools will look for a suitable Feature and will add the SPI to it. This process isn’t random and is being executed based on a number of criteria such as the scopes in which the given SPI may be deployed vs. the scope of the given Feature. This process of matching, although very useful in some scenarios, can lead to SPI’s added to wrong Features. This is especially difficult to track when working with complex solutions that consist of multiple Features and many SPI’s. Unfortunately there is no out of the box way to disable to auto adding process. However, thanks to great extensibility capabilities of the new Visual Studio 2010 SharePoint Developer Tools it is possible now. Proudly introducing: Mavention Cancel Adding SharePoint Project Items extension.
By default the new Visual Studio 2010 SharePoint Developer Tools activate all Features from the package that is being deployed. While this is a great productivity feature when you need to quickly deploy something, it might be not the thing that you want while working with larger projects. The alternative available out of the box is not activating Features at all. Where does that takes us? I wrote about it previously. In my previous post I also suggested you could use Post-deployment Commands to activate the Features that you want. But wouldn’t it be just more convenient and intuitive if you could select Features that you want to activate during the deployment process? Proudly presenting: Mavention Activate Selected Features extension.
If you have worked with the new Visual Studio 2010 SharePoint Developer Tools you probably know that one part of the cool pieces of the new tools is the ability to specify the steps executed while deploying SharePoint Solution Packages on your development machine. These Deployment Configurations are fully configurable: you can either use one of the two existing configurations or create a new one that fully suits your needs. By default two Deployment Configurations are available Default and No activation. The only difference between those two is that the No activation configuration doesn’t activate any Features after the solution has been deployed. If the difference is that small: why do we need two configurations?
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.
SharePoint 2010 ships with Silverlight Object Model that simplifies working with SharePoint data within Silverlight components. Thanks to the new object model you no longer have to create and deploy custom services to retrieve data from SharePoint. Out of the box the Silverlight Object Model encapsulates calling standard SharePoint WCF Services which makes it extremely easy for you as a developer to create Silverlight components that communicate with SharePoint. Although working with the Silverlight Object Model is pretty easy, there is one thing that you have to keep in mind while developing for anonymous users.