Dealing with anonymous access to a website, I found some rather interesting behavior where a Redirect handler I had written was throwing a
NullReferenceException. It turns out that the
SPContext.Web property includes some fairly complex logic that under certain circumstances creates a new
SPWeb instance. As a result, it may fail with the
NullReferenceException, although that behavior is not documented (Big surprise for the MSCryptic fans…)
In my case it dealt with an application page in the _layouts folder that was set for anonymous access using the UnsecuredLayoutsPageBase class. My RunWithElevatedPrivileges code block was creating problems when trying to access certain properties using the SPContext.Current.Site object.
The solution was to instantiate a local variable outside the using block to hold the user’s current site and then read properties from the local variable once inside the RunWithElevatedPrivileges block in order to avoid the
NullReferenceException. Here is the code:
protected override void OnPreInit(EventArgs e)
// site and web objects working with the current user's privileges
SPSite userSite = SPContext.Current.Site;
// get new site and web objects working with elevated privileges
using (SPSite thisSite = new SPSite(userSite.ID))
//Code here using thisSite instead of SPContext.Current.Site....
For some reason, Microsoft doesn’t like the idea of the average user running server as their desktop, but for those of us who develop SharePoint and don’t want to go through the hack of installing it on Windows 7 it can be rather limiting.
I use virtual machines for some custom development, but also run Server 2008 R2 locally or remote into servers to do work/research. One slightly annoying feature is the lack of user tools like the drive cleanup and all my lovely video codecs. Enter the Desktop Experience feature…
Unfortunately, codecs for H.264 and AAC are missing on Server 2008 R2. Microsoft has KB2483177: Update for Desktop Experience Decoder for Windows Server 2008 R2 available to fix this issue.
This feature is mainly for developers. Microsoft has added new classes which help to log and trace the errors and exceptions.
- Developer Dashboard: This records the time, resources used for a particular web page request and shows on the UI.
- Request usage database: This database contains all the information about requests and resource usage.
- SPMonitoredScope: This is the attribute and if you apply this to a class then you can save the complete details to the SharePoint usage database.
- With new API features it is very easy to implement or communicate with ULS logs by using SPDiagnosticsServiceBase class.
If you have not already done so, I highly recommend you download the ULS Viewer tool. It allows admins and developers to open a ULS log file and display its contents in a user friendly format. Users can then perform advanced functions such as filtering, sorting, highlighting, loading logs, appending logs, etc in order to single out the data that is important to the user. This information can be used to diagnose problems with machines running ULS services, or to monitor machines and the events they create in real-time.
Latest gacutil is part of Microsoft Windows SDK for Windows 7 and .NET Framework 4. Remember you can’t use previews version of gacutil (1.1 or 2.0/3.5) to register dll built in framework 4.0.
If you don’t want to install whole SDK you need to copy below files to server, only. Of course you need to install SDK on local machine to be able copy below files to server.
1. Files location: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
List of files required to gacutil work properly:
- 1033\gacutlrc.dll (can be placed in the same dir as gacutil.exe on the server)
Another interesting thing about assembly in 4.0 framework is location of your assembly. Location changed from C:\Windows\assembly\ to C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Remember to unregister assembly you need to use commend:
gacutil /u assemblyname (you can’t use assemplyname.dll)
Understanding The CLR Binder
Imagine you’ve been handed a farm with no documentation, or you have documentation and you don’t trust it, or you just forgot to document it. You spend some time cleaning it up and making it nice and shiny with proper documentation. Now you need to add a new server to the farm and you don’t have that all important new piece of information in 2010 called the Farm Passphrase. Currently there is no way to retrieve the Farm Passphrase from SharePoint, however there is the option to reset the Passphrase to a new one by using PowerShell.
In order to do this, you must be a member of the SharePoint_Shell_Access database role on the SharePoint Configuration database. Check Get-SPShellAdmin and Add-SPShellAdmin.
Open the SharePoint 2010 Management Shell (Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell) and make sure you run as an administrator.
Enter the following:
$passphrase = ConvertTo-SecureString -asPlainText –Force
The request for String: will appear
Type the new passphrase and hit enter
The PowerShell prompt will appear again, enter this:
Set-SPPassPhrase -PassPhrase $passphrase -Confirm
You will be asked to confirm the Passphrase by re-entering it
The system will ask Are you sure you want to perform this action?
Type Y and click enter
And now you’re able to use the Passphrase you just entered to join your new server to the existing farm. Don’t forget to record your passphrase somewhere safe in case you ever need to hand off the documentation to someone else!
NOTE: During a recent installation, the documentation we had swore up and down that what was recorded as the Passphrase was the official Passphrase. When using the SharePoint 2010 Configuration Wizard it even accepted the documented Passphrase, however during the join process scripts for some as-yet-unexplained-msCryptic reason we were getting the error message that the Passphrase was incorrect. Using the above to gently remind our farm of what it’s Passphrase was seemed to fix the issue. Not sure what the root cause was, but issue was
fixed resolved and we moved on.