I searched around as I couldn’t understand what could be causing this. My executing account had full Rights in SharePoint, the local system and access to the database. I checked to ensure the url I was using was correct and that everything worked when viewing the site using a browser. Then I realized that Visual Studio by default sets Console applications to target x86 by default!!

This is a problem as the SharePoint API is 64bit only and my console application was running in 32bit mode. I checked Task Manager to view the running processes and sure enough my app was running with *32 indicating it was running in 32bit mode.This was a quick fix as I just needed to update the Platform Target build setting to be x64 instead of x86.

To do this navigate to Project Properties > Build tab and update the Platform Target to be x64 instead of x86. Once this is done run the application again to validate that the issue is resolved. Also make sure you update all of your build configurations. When you switch from Debug to Release the release configuration will still be set to target x86.

Note: Setting to AnyCPU will also work as it will run in 64bit, but since the SharePoint API is 64bit only, I suggest setting to x64 to ensure it does not run on 32bit systems.

I was working on some build automation scripts today adding email notification of the build results. Since our automation scripts use PowerShell this is what I would be using to send the email. This turned out to be really straight forward task using the SmtpClient Class.

Here is a quick example using smtpclient to send a simple email.

Source code

$emailFrom = "fromuser@domain.com"
$emailTo = "touser@domain.com"
$subject = "Subject"
$body = "Message body"
$smtpServer = "mail.domain.com"
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($emailFrom, $emailTo, $subject, $body)

The SMTP server I was using to relay the messages also required authentication. So I had to set the Credentials property of the SmtpClient object.

$smtp.Credentials = new-object System.Net.NetworkCredential("senduser", "pass")


Now you may ask how to add multiple lines to the email. There are a few ways to do this, but since this is for use internally I wanted to keep it simple so I just pass carriage return/newline `r`n`r`n at the end of the lines I want to break at.

Here is an example passing sender credentials and a couple of lines in the email body.

Source code

$emailFrom = "fromuser@domain.com"
$emailTo = "touser@domain.com"
$subject = "Subject"
$body = "Message body`r`n`r`n"
$body += "2nd Line`r`n`r`n"
$body += "3rd Line"
$smtpServer = "mail.domain.com"
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Credentials = new-object System.Net.NetworkCredential("senduser", "pass")
$smtp.Send($emailFrom, $emailTo, $subject, $body)

Error

Load control template file /_controltemplates/TaxonomyPicker_broken.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

The Fix…

To fix the issue with the error being logged in the Events Log do the following.

1. Navigate to the controltemplates directory in the 14 hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14)
2. Rename TaxonomyPicker.ascx to TaxonomyPicker.broken (or remove it completely since it is never used).
3. Recycle the app pool for the SharePoint Web Application.

After the app pool recycles the control will no longer be loaded when the site initializes and you won’t be seeing the error within the event log any longer.

The following code displays a sample message for 5 seconds and then removes it.

Source code

<script type="text/javascript">// <
//First wait until the SP.js is loaded, otherwise the Notification won't work and a null reference exception is thrown
ExecuteOrDelayUntilScriptLoaded(Initialize, "sp.js");
//Function to remove the status from the page
function RemoveStatus() {
SP.UI.Status.removeStatus(this.statusId);
}
//Fucntion called after sp.js is loaded.
function Initialize() {
this.statusId = SP.UI.Status.addStatus("My Title"," My Message");
SP.UI.Status.setStatusPriColor(this.statusId, "Blue");
setTimeout(RemoveStatus, 5000);
}
</script>

Messages can be displayed using the following priorities by passing the corresponding color to the SP.UI.Status.setStatusPriColor method.

One thing to note when displaying multiple messages is that the highest priority will be used. For example if you display a Very Important (Red) message and then swap out to show an informational (Blue) message. The status priority color won’t update and the second message will display as Very Important (Red).

Many times during SharePoint development you may need to execute code or access information that the current impersonated user does not have access to. An internal example of this is SharePoint elevating calls to the database. Every application user doesn’t need assigned roles in SQL Server, only the SharePoint runtime accounts need to be configured for SQL Server access.

The SPSecurity class provides the static method RunWithElevatedPrivileges for elevating calls. Code executing using this has Full Access so care must be taken not to elevate code that relies on authentication and/or authorization rules.

Here is an example showing the syntax to define an anonymous method in the call to RunWithElevatedPrivileges

Source code

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    // Code that needs to be elevated
});

Recently while working on a project, I ran into an issue with a site that was using forms based authentication (FBA). The application would load configuration settings before the user had logged in. If the application was in a state that the target site’s configuration had not been previously loaded & cached, then the request would be made as an anonymous (null) user. Since some of these settings were stored as SPWeb properties and the unauthenticated user does not have the required permissions the request would be denied and the user was redirected to a page stating that access was denied and they needed to login. The problem was they didn’t have a chance to login yet?!

SharePoint “handles” Access denied exceptions by catching the exception internally and then redirecting the user to a landing page where they can log in to the site. By default this is generally “_layouts/AccessDenied.aspx”.

Most of the time this is an acceptable way for unauthorized exceptions to be handled as you can elevate calls when required in your code. But the scenario does arise where you may need to handle the exception within your own code, not elevate the call and not have the user redirected to an access denied page.

Since SharePoint redirects the request to the default Access Denied landing page you cannot catch the UnAuthorizedAccessException as the redirect causes a ThreadAbortException to be thrown so your code will never get executed.

In order to handle a thrown UnAuthorizedAccessException within your code you first need to set the property CatchAccessDeniedException (part of the SPSecurity class) to false. Doing so means that the Access exceptions aren’t handled by the SharePoint platform and the request isn’t redirected.

The following is some example code.

Source code

//It's a good idea to store the original value to be safe.
bool orgcatchvalue = SPSecurity.CatchAccessDeniedException;
try{
SPSecurity.CatchAccessDeniedException = false;
//your code that may throw an authorization exception
}
catch(UnAuthorizedAccessException)
{
//Code to handle exception
}
finally
{
//set the value back to what it was
SPSecurity.CatchAccessDeniedException = orgcatchval;
}

With the above example setting CatchAccessDeniedException to false allows you to handle the UnAuthorizedAccessException within your own code without SharePoint redirecting the request.

Source code

[WebPartStorage(Storage.Shared)]
public Boolean MyProp
{
   get { return _myprop; }
   set { _myprop = value; }
}

Valid values for WebPart storage are:

• Storage.Shared, which means that the property is stored with the same value for all users.

An example of this might be a Web Part that displays stock information and has a URL to a stock site as one if its properties. In this case, you’d probably define this property storage as Shared to make sure your part works as designed.

• Storage.Personal, which means that the property is stored per user (the default).

With the above example of a stock ticker WebPart you may have an option where users can enter in the symbols they want to follow.

• Storage.None, which means that the property is not stored in the database, and the default value assigned by the designer is applied

This may be an internal property that would be set at design time, like frequency of updates.

Using the contents=1 querystring parameter you can put the page in “Maintenance mode” allowing you to remove the bad webparts.

Example: http://yourserver/Lists/badlistpage/Allitems.aspx?contents=1

It looks like this is a short cut to the  Maintenance page and passes the referring URL in the querystring

http://devbox/_layouts/spcontnt.aspx?&url=%2fLists%2fbadlistpage%2fAllItems.aspx

Reference list of the default list types as defined in the global onet.xml file. This is not exhaustive but meant as a quick reference for development.

The WASC Threat Classification is an effort to classify the weaknesses and attacks that can lead to the compromise of a website, its data and or its users. The primary goal is to offer a central guide for common attacks and weaknesses. You can find the document online at http://projects.webappsec.org/Threat-Classification