André Vala : SharePoint 2007 Deployment: Using Resources in Features. SharePoint 2007 Deployment: Using Resources in Features This series of posts about SharePoint deployment would not be complete if I didn’t write one about using resources in Features to allow localization. After all, SharePoint’s out-of-the-box features use resources all the time.
Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index. Why should I use Resources? In my opinion, you should always use resource files for your features. Why? First, because it’s easy to do even if you only have one language. Examples of things that should be placed in resource files: Title and Description of you feature, so that they will be displayed in the language of the website; Site column display name and description; Content type name and description; List template name and description; List instance title and description; Custom action title and description. How do I use it? There are three steps to use resources in a feature: <? <? Shared Resource Files. André Vala : SharePoint 2007 Deployment: List Template Features.
SharePoint 2007 Deployment: List Template Features Summary This post is about developing features to create list templates in a SharePoint site. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index. Package Structure As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files: The feature manifest file (which must be named feature.xml) One or more element manifest files Additionally, a list template must include a third file, called schema.xml, that contains the list definition. You can then place these three files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).
List Templates A list template is a reusable definition of a SharePoint list that is used to create lists. Using a feature, just as described in this post. Allowed Scopes. André Vala : SharePoint 2007 Deployment: Creating and Using Features. SharePoint 2007 Deployment: Creating and Using Features Summary This third post is about creating and using Features in a general sense.
Creating Features for each specific element will be the subject of later posts. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index. Feature Scopes A Feature can be activated or deactivated in a specific scope, and there are four different scopes: Farm – The elements will be deployed at the farm level. Each type of element can be deployed to one or more of these scopes. Feature Schema To create a Feature you must create a XML file named feature.xml which contains all the general configurations for the Feature and the references to all the files that describe the Elements contained in the Feature. Feature Element The <Feature> element is the root element of the feature.xml file and it has several possible attributes, although not all of them are required: Id (required): Unique identifier for this feature (GUID). André Vala : SharePoint 2007 Deployment: Overview. SharePoint 2007 Deployment: Overview I'm starting a new series of posts on SharePoint Deployment, since I believe it's one of the hardest tasks on a SharePoint project.
This first post will be updated every time I add a new article to this series. SharePoint 2007 Deployment Series Part 0: Overview (this post) Part 1: Features and Solutions Part 2: Creating and Using Features Part 3: Creating and Using Solutions Part 4: Site Column Features Part 5: Site Content Type Features Part 6: List Template Features Part 7: List Instance Features Part 8: Custom Action Features Part 9: Module Features Part 10: Event Registration Features Part 11: Content Type Binding Features Part 12: Feature Stapling (Feature Site Template Association) Part 13: Using Resources in Features Who Needs Deployment?
Regarding the development environment, there are two types of SharePoint projects: Additionally, you can have two types of farms, in a SharePoint installment: What Does Deployment Mean, in a SharePoint Sense? Sample code acceptance checklist for IT organizations. Updated: 2009-02-26 Web sites that are based on Microsoft Office SharePoint Server 2007 often include custom solutions. The ability to customize sites by adding custom solutions gives Office SharePoint Server 2007 power and flexibility. However, a poorly designed or implemented executable module that runs in a SharePoint farm can do harm even beyond the scope of the Web application for which it was intended.
Poorly implemented custom solutions can introduce security or performance risks, increase the cost of support, complicate deployment, and reduce productivity. Because the impact of installing custom solutions in a SharePoint server farm can be either positive or negative, we recommend that you to carefully evaluate all custom solutions before deploying them in your production environment. Among the areas to evaluate are the following: In this topic: Security Session management Validation Sensitive data Exception handling Web parts Documentation General software development best practices.
Using Visual Studio 2005, MakeCab.exe and MSBuild to Create Window SharePoint Services v3 Solution Files (*.WSP's) The Problem When you had custom code to deploy in WSS v2, primarily Web Parts, you packaged them up in a Web Part Package using WPPackager for deployment on your servers. Unfortunately it wasn't the easiest tool to use, nor was it error-free. Thankfully Microsoft has abandoned the WPPackager utility in WSS v3 in favor solution files. A solution file is a Windows SharePoint Services solution package that is really just a CAB with a WSP extension.
You can use solutions to deploy Web Parts & associated files (such as resource files, images, CSS, etc), add safe control entries, deploy the CAS policy changes, features, and so on… (read the documentation in the WSS SDK linked at the end of this post for more info). The only downside is that building CAB files isn't the easiest or most straightforward thing to do. Your other option is to get the Microsoft Cabinet SDK that includes the MakeCAB.EXE utility, craft a diamond directive file (*.DDF), and build the *.WSP that way.
Overview There is! <? SharePoint 2007 Features - Home. SharePoint Feature Manager Update 1.0.0.2 - Todd Baginski's SharePoint 2003 and MOSS 2007 Blog. SharePoint 2007 Features – Creating Site Columns and Content types. + New .COMs $7.99/yr plus 18 cents/yr ICANN fee. Discount based on new one-year registration prices as of 1/27/2012 with sale price reflected in your shopping cart at checkout. Discount applies to new registrations and renewals and cannot be used in conjunction with any other offer or promotion. Domains purchased through this offer will renew at regular price after the initial term has expired. Offer ends May 31, 2012 5:00 pm (MST). † Good for one 1-year registration of any available .COM, .US, .BIZ, .INFO, .NET or .ORG ‡ Annual discounts available on NEW purchases only.
GoDaddy.com is the world's No. 1 ICANN-accredited domain name registrar for .COM, .NET, .ORG, .INFO, .BIZ and .US domain extensions. Source: RegistrarSTATS.com 1 GoDaddy.com is rated the world's largest hostname provider according to Netcraft®. Creating site columns, publishing content types and page layout using a feature. Experiences about my developer life (.NET, C#, SharePoint), and sometimes all but developer life Personal MOSS 2007 ASP.NET .NET Silverlight General February 2009 (1) June 2008 (3) March 2008 (1) February 2008 (1) December 2007 (4) November 2007 (4) September 2007 (4) August 2007 (2) July 2007 (3) June 2007 (6) May 2007 (6) April 2007 (4) March 2007 (3) February 2007 (5) January 2007 (3) Andrew Connell Bart De Smet Mikhail Dikov ECM Team Blog Scott Guthrie Harbar.net Chris O'Brien Joel Oleson Part I – Creating site columns, publishing content types and page layout using a feature In this 3 part series I will explain the steps you need to follow in order to create site columns, content types and page layouts for use with a MOSS publishing site.
Site columns are created by placing elements inside an tag. Most of the attributes of the element are optional. StaticName = " IntroductionText " SourceID = " " Publishing field for storing an image. Deploying a calculated site column using a feature in SharePoint 2007. SharePoint solution builder. MOSS Feature Generator - Home. Chris O'Brien's blog: Deploying content types as a feature. This is the third article in my series of how to create common SharePoint site artifacts as features. Last time we looked at creating site columns as a feature. Site columns are typically used in lists and/or content types. The concepts are fairly simple since a content type is also effectively a list with a series of columns (for those who have worked with CMS2002 the equivalent entity was a template definition). The columns give the data entered into content areas on a page somewhere to be stored.
However, content types in SharePoint are also a valuable unit of granularity, since workflow, document lifecycle policy and several other key pieces of functionality can be configured at this level. Any page layout you create as a template for pages on your site must be associated with a content type. Fortunately creating content types as features is fairly simple - CAML only, no need for a feature receiver (code). The basics are: find the ID of the content type you are deriving from.
How to create common MOSS site artifacts as features. Having been through the process of creating a MOSS site entirely through Features, it struck me how non-intuitive some of the associated tasks are. Many SharePoint developers who are working in this way will agree that something that takes 30 seconds in the UI can take several hours in Visual Studio. Over the next few articles, I'll note some of the issues I came across in this process, and also the solution I used for each. But first, let's be clear on why developing SharePoint Features is the way to go for MOSS development.
The main reasons as I see them are:- ability to deploy updates through dev/QA/staging/production etc. in a repeatable manner (i.e. without recreating things manually through the UI - since this wouldn't scale well across many environments)ability to deploy updates to all the web-front-end machines in the farm in one go (when the Feature is wrapped in a Solution - more on this later). The next articles in my series will be:- So long for now.. Chris.