Creating custom Site Columns is something you do in almost every single SharePoint Solution. Unfortunately even in spite of great SDK documentation and intellisense for SharePoint XML files, it’s still a tedious process to create new columns directly in the XML. Using the SharePoint web UI is way easier but then again: how would you get that out of SharePoint and put into your Solution? There is an answer to that question and it is: use CKS:DEV!
A picture is worth a thousand words. In many situations images help illustrate and explain thoughts. Without images the Web would be boring and colorless. And while we all are convinced about the power of image and how it enhances telling a story, it is surprising how complex it is to get it right on the Web. Many large images on your website make it download and display slowly. No matter how great the content is, the odds are high that your visitor will not take the time to wait for it. Large images is not something specific to SharePoint. Many Content Management Systems suffer from not being able to automatically provide resized images. And while in many cases there are solutions to that, they are either complex, expensive or both. However the great thing with SharePoint 2010 is, that using its extensibility capabilities you can easily change this…
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.
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.