RealTime Sharepoint Interview Questions 3

What deployment mechanism can you use to instigate Code Access Security attributes for your WebParts?

SharePoint solution files can add in order to handle code access security deployment issues. This is done in the element in the SharePoint solution manifest.XML, which makes it easier to get assemblies the appropriate permissions in order to operate in the bin directory of the web application.

What is a SharePoint Feature? What files are used to define a feature?

A SharePoint Feature is a functional component that can be activated and deactivate at various scopes throughout a SharePoint instances, such as at the farm, site collection, web, etc. Features have their own receiver architecture, which allow you to trap events such as when a feature is installing, uninstalling, activated, or deactivated. They are helpful because they allow ease of upgrades and versioning.

The two files that are used to define a feature are the feature.xml and manifest file. The feature XML file defines the actual feature and will make SharePoint aware of the installed feature. The manifest file contains details about the feature such as functionality.

Side Question: I got asked how the introduction of features has changed the concept of site definitions. SharePoint features are important when understanding the architecture of site definitions, since the ONET.XML file has been vastly truncated since it has several feature stapled on it.

What types of SharePoint assets can be deployed with a SharePoint feature?

Features can do a lot. For example, you could deploy

• Simple site customizations
• Custom site navigation
• WebParts
• pages
• list types
• list instances
• event handlers
• workflows
• custom actions

What are event receivers?

Event receivers are classes that inherit from the SpItemEventReciever or SPListEventReciever base class (both of which derive out of the abstract base class SPEventRecieverBase), and provide the option of responding to events as they occur within SharePoint, such as adding an item or deleting an item.

 When would you use an event receiver?

Since event receivers respond to events, you could use a receiver for something as simple as canceling an action, such as deleting a document library by using the Cancel property. This would essentially prevent users from deleting any documents if you wanted to maintain retention of stored data.

 What base class do event receivers inherit from?

Event receivers either inherit from the SPListEventReciever base class or the SPItemEventReciever base class, both which derive from the abstract base class SPEventReceiverBase.

If I wanted to not allow people to delete documents from a document library, how would I go about it?

You would on the ItemDeleting event set: properties.Cancel= true.

 What is the difference between an asynchronous and synchronous event receivers?

An asynchronous event occurs after an action has taken place, and a synchronous event occurs before an action has take place. For example, an asynchronous event is ItemAdded, and its sister synchronous event is ItemAdding.

How could you append a string to the title of a site when it is provisioned?

In the OnActivated event:

1 2 3

SPWeb site = siteCollection.RootWeb; site.Title += "interview"; site.Update();

Can an event receiver be deployed through a SharePoint feature?

Yes.

What is a content type?

A content type is an information blueprint basically that can be re-used throughout a SharePoint environment for defining things like metadata and associated behaviors. It is basically an extension of a SharePoint list, however makes it portable for use throughout an instance regardless of where the instantiation occurs, ergo has location independence. Multiple content types can exist in one document library assuming that the appropriate document library settings are enabled. The content type will contain things like the metadata, listform pages, workflows, templates (if a document content type), and associated custom written functionality.

Can a content type have receivers associated with it?

Yes, a content type can have an event receiver associated with it, either inheriting from the SPListEventReciever base class for list level events, or inheriting from the SPItemEventReciever base class. Whenever the content type is instantiated, it will be subject to the event receivers that are associated with it.

  

What two files are typically (this is kept generally) included when developing a content type, and what is the purpose of each?

There is generally the main content type file that holds things like the content type ID, name, group, description, and version. There is also the ContentType.Fields file which contains the fields to include in the content type that has the ID, Type, Name, DisplayName, StaticName, Hidden, Required, and Sealed elements. They are related by the FieldRefs element in the main content type file.

What is an ancestral type and what does it have to do with content types? 

 

An ancestral type is the base type that the content type is deriving from, such as Document (0x0101). The ancestral type will define the metadata fields that are included with the custom content type.

 Can a list definition be derived from a custom content type?

Yes, a list definition can derive from a content type which can be seen in the schema.XML of the list definition in the element.

 When creating a list definition, how can you create an instance of the list?

You can create a new instance of a list by creating an instance.XML file.

What is a Field Control?

Field controls are simple ASP.NET 2.0 server controls that provide the basic field functionality of SharePoint. They provide basic general functionality such as displaying or editing list data as it appears on SharePoint list pages.

What base class do custom Field Controls inherit from?

This varies. Generally, custom field controls inherit from the Microsoft.SharePoint.WebControls.BaseFieldControl namespace, but you can inherit from the default field controls.

What is a SharePoint site definition? What is ghosted (uncustomized) and unghosted (customized)?

SharePoint site definitions are the core set of functionality from which SharePoint site are built from, building from the SiteTemplates directory in the SharePoint 12 hive. Site definitions allow several sites to inherit from a core set of files on the file system, although appear to have unique pages, thereby increasing performance and allowing changes that happen to a site propagate to all sites that inherit from a site definition. Ghosted means that when SharePoint creates a new site it will reference the files in the related site definition upon site provisioning. Unghosted means that the site has been edited with an external editor, and therefore the customizations are instead stored in the database, breaking the inheritance of those files from the file system.

How does one deploy new SharePoint site definitions so that they are made aware to the SharePoint system?

The best way to deploy site definitions in the SharePoint 2007 framework is to use a SharePoint solution file, so that the new site definition is automatically populated to all WFE’s in the SharePoint farm.