When working on SharePoint Solutions one of the common requirements is delivering multilingual solutions. Depending on your scenario you might either need to localize a single Web Part or a complete Solution. Thinking of multiple languages you have to take into account not only the development but also the packaging process for all the different assets in your Solution. One of such assets, where implementing support for multiple languages in SharePoint 2010 might seem complex at first sight, are Site Definitions. However you can easily create a multilingual Site Definition using nothing more than the standard capabilities of the new Visual Studio 2010 SharePoint Developer Tools.
Developing localized solutions on the SharePoint 2007 platform wasn’t as straight-forward as we wanted it to be. First of all you had to make your code support globalization and then you had to provision the localized Resource files to your Web Application. As SharePoint 2007 didn’t provide any mechanism to do that, you had to use custom Timer Jobs to get this done correctly. Luckily this situation has changed with SharePoint 2010 which introduces the new App\_GlobalResourceFile element in the Solution Manifest which makes it possible to declaratively deploy Resource files in a structured and repeatable fashion.
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.
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.