Q.
How can I raise the trust level for assemblies installed in the BIN directory? Ans. Windows
SharePoint Services can use any of the following three options from ASP.NET and
the CLR to provide assemblies installed in the BIN directory with sufficient
permissions. The following table outlines the implications and requirements for
each option.
Option
Pros Cons
Increase
the trust level for the entire virtual server. For more information, see
"Setting the trust level for a virtual server" Easy to implement.
In
a development environment, increasing the trust level allows you to test an
assembly with increased permissions while allowing you to recompile assemblies
directly into the BIN directory without resetting IIS. This option is least
secure.
This
option affects all assemblies used by the virtual server.
There
is no guarantee the destination server has the required trust level. Therefore,
Web Parts may not work once installed on the destination server.
Create
a custom policy file for your assemblies. For more information, see "How
do I create a custom policy file?" Recommended approach.
This
option is most secure.
An
assembly can operate with a unique policy that meets the minimum permission
requirements for the assembly.
By
creating a custom security policy, you can ensure the destination server can
run your Web Parts. Requires the most configuration of all three options.
Install
your assemblies in the GAC Easy to implement.
This
grants Full trust to your assembly without affecting the trust level of
assemblies installed in the BIN directory. This option is less secure.
Assemblies
installed in the GAC are available to all virtual servers and applications on a
server running Windows SharePoint Services. This could represent a potential
security risk as it potentially grants a higher level of permission to your
assembly across a larger scope than necessary
In
a development environment, you must reset IIS every time you recompile
assemblies.
Licensing
issues may arise due to the global availability of your assembly.
Q.
When retrieving List items using SharePoint Web Services, how do you specify
explicit credentials to be passed to access the list items? Ans. In order to
specify explicit credentials with a Web Service, you generally instantiate the
web service, and then using the credentials properties of the Web Service
object you use the System.Net.NetworkCredential class to specify the username,
password, and domain that you wish to pass when making the web service call and
operations.
***
Side Question: I got asked when you should state the credentials in code. You
must state the credentials you are going to pass to the web service before you
call any of the methods of the web service, otherwise the call will fail.
Q.
What is CAML, and why would you use it? Ans. CAML stands for Collaborative
Application Markup Language. CAML is an XML based language which provides data
constructs that build up the SharePoint fields, view, and is used for table
definition during site provisioning. CAML is responsible for rending data and
the resulting HTML that is output to the user in SharePoint. CAML can be used
for a variety of circumstances, overall is used to query, build and customize
SharePoint based sites. A general use would be building a CAML query in a
SharePoint WebPart in order to retrieve values from a SharePoint list.
Q.
What is impersonation, and when would you use impersonation? Ans. Impersonation
can basically provide the functionality of executing something in the context
of a different identity, for example assigning an account to users with
anonymous access. You would use impersonation in order to access resources on
behalf of the user with a different account, that normally, that wouldn’t be
able to access or execute something.
Q.
What is the IDesignTimeHtmlProvider interface, and when can you use it in
WebParts? Ans.
The IDesignTimeHtmlProvider interface uses the function GetDesignTimeHtml()
which can contain your relevant render methods. It was helpful to use in 2003
since it allowed your WebPart to have a preview while a page was edited in
FrontPage with the Webpart on it, because the GetDesignTimeHtml() method
contains the HTML for the designer to render.
Q.
What are WebPart properties, and what are some of the attributes you see when
declaring WebPart properties in code? Ans. WebPart properties are just like
ASP.NET control properties, they are used to interact with and specify
attributes that should be applied to a WebPart by a user. Some of the
attributes you see with ASP.NET 2.0 properties are WebDescription,
WebDisplayName, Category, Personalizable, and WebBrowsable. Although most of
these properties come from the System.Web.UI.WebControls.WebParts class, ones
like Category come out of System.ComponentModel namespace.
Q.
Why are properties important in WebPart development, and how have you exploited
them in past development projects? What must each custom property have? Ans. Properties are
important because WebParts allow levels of personalization for each user.
WebPart properties make it possible for a user to interact, adjust, and
increase overall experience value with the programmatic assets that you develop
without having the need to use an external editor or right any code. A very
simple example of exploiting a property would be something like allowing the
user to change the text on the WebPart design interface so that they can
display whatever string of text they desire.
Each
custom property that you have must have the appropriate get and set accessor
methods.
Q.
What are ClassResources? How do you reference and deploy resources with an
ASP.NET 2.0 WebPart? Ans.
ClassResources are used when inheriting from the
SharePoint.WebPart.WebPartPages.WebPart base class, and are defined in the
SharePoint solution file as things that should be stored in the wpresources
directory on the server. It is a helpful directory to use in order to deploy
custom images. In ASP.NET 2.0, typically things such as images are referenced
by embedding them as resources within an assembly. The good part about
ClassResources is they can help to eliminate recompiles to change small
interface adjustments or alterations to external JavaScript files.
Q.
What is a SharePoint Solution File? How does it differ from WebPart .cab files
in legacy development? What does it contain? Ans. A SharePoint solution file is
essentially a .cabinet file with all a developers ustom componets suffixed with
a .wsp extension that aids in deployment. The big difference with SharePoint
solution files is is that a solution:
allows
deployment to all WFE’s in a farm
is
highly manageable from the interface allowing deployment, retraction, and
versioning
Can
package all types of assets like site definitions, feature definitions (and
associated components), Webparts, etc.
Can
provide Code Access Security provisioning to avoid GAC deployments
Just
to name a few things…
Q.
What is a .ddf file and what does it have to do with SharePoint Solution
creation? Ans.
A .ddf file is a data directive file and is used when building the SharePoint
solution bundle specifying the source files and their destination locations.
The important thing for someone to understand is that the .ddf file will be
passed as a parameter to the MAKECAB utility to orchestrate construction of the
SharePoint solution file.
Q.
What file does a SharePoint solution package use to orchestrate (describe) its
packaged contents? Ans.
The solution Manifest.XML file.
Q.
What deployment mechanism can you use to instigate Code Access Security
attributes for your WebParts? Ans. 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.
Q.
What is a SharePoint Feature? What files are used to define a feature? Ans. 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.
Q.
What types of SharePoint assets can be deployed with a SharePoint feature? Ans. 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
Q.
What are event receivers? Ans. 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.
Q.
When would you use an event receiver? Ans. 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.
Q.
What base class do event receivers inherit from? Ans. Ev
ent
receivers either inherit from the SPListEventReciever base class or the
SPItemEventReciever base class, both which derive from the abstract base class
SPEventReceiverBase.
No comments:
Post a Comment