Inconvenient creating list instances using Feature Receivers

Recently I’ve been working with a Feature responsible for provisioning a list instance based on the Asset Library List Template (new in SharePoint 2010). In spite of the fact that everything seemed to be okay on my side (everything defined in the right place, the Asset Library Feature activated, and so on), I kept getting error that the Asset Library List Template does not exist. Finding the answer to this riddle was just a matter of… timing.

Activating selected Features during the deployment of a package in Visual Studio 2010 SharePoint Developer Tools

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.

The No Activation Deployment Configuration: use it or not?

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?

Including additional assemblies in the WSP with Visual Studio SharePoint development tools

The new Visual Studio SharePoint development tools simplify work for SharePoint developers. Out-of-the-box the tools have some great functionality and knowing about these gems allows you to fully benefit of the power of the new tools. One of such gems can be used to make the process of provisioning multiple assemblies with a simple SharePoint Solution (WSP) easier.

Extending the packaging process of the Visual Studio SharePoint development tools

The new Visual Studio SharePoint development tools ship with a broad support for the process of developing SharePoint solutions. One part of that process is packaging SharePoint artifacts into a WSP package and deploying it to a SharePoint server. By know you probably know that the Visual Studio SharePoint development tools are highly extensible, but did you know that you can even extend the way how the Visual Studio SharePoint development tools package SharePoint artifacts?