Recently I left Microsoft where I worked for almost 15 years and where about 10 of those years were spent in Escalation Services where my daily routine was debugging failing or faulting applications. This all began with user and kernel mode Windows processes and then once the .Net Framework shipped I move to the ASP.Net and CLR teams and began debugging more managed processes. Normally customers would send my team crash dumps or memory dumps of the offending process(s) and we would use tools such as WinDbg or CDB to dig deeper into the process to determine what was happening. There are several challenges when doing this type of work and one of the most painful is locating and referencing the correct symbols files (*.pdb).
I have a 16GB Lenovo laptop which I use in my daily work. It runs Windows 7 and while you can install SharePoint 2010 on Windows 7 I choose never to do that (you can read more here about why I don’t use Windows 7 as my SharePoint development platform). I am not a big fan of dual, triple, quad, (or whatever comes next) booting, because as soon as I boot into one OS I will likely need to send email or do something which is setup in another OS. I also don’t like running a server OS on my laptop because I use Bluetooth every once in a while and I like the hibernate and sleep functionality Windows 7 provides. So until Windows 8 hits mainstream with its virtualization platform I must resort to running a 3rd party virtualization solution so I chose VMWare Workstation and currently I am running their latest version 8.0.
This is the 4th article and last article in a series where I have been discussing the extensibility offered with the SharePoint 2010 Usage and Health services. If you have read all the prior articles to this point then bravo for you! I really hope this last article was worth the wait. At this point I have provided an overview of the Health and Usage Service, discussed the development of a Custom Usage Provider and showed you how to create custom Health reports and host those within Central Administration. This last article covers my favorite Health and Usage extensibility Usage Receivers. In fact, here is a little secret I will let you in on, to build its analytic reports the SharePoint Web Analytics Service application uses a Usage Receiver to grab all its data from the OOB Request Usage Provider. So take a look at the SharePoint 2010 Web Analytics with all its data and rich reporting and know that all came from a Usage Receiver.
If you missed the prior articles the list below is for you, otherwise lets jump into the article:
- Feature and Capability Overview
- Writing a Custom Usage Provider
- Writing Custom Reports
- Writing a Custom Usage Receiver (this article)
So lets say you want to change a list item but you don’t want to impact any versioning or having to deal with check-in or check-out, and you don’t want to change the last modified or modified by values. You can do this with the bit of code shown below. Grab the item reference and update the item just as you normally would however rather than calling SPItem.Update() you want to call SPItem.SystemUpdate(). You can check out the TechNet reference if you want to see additional code samples.
In this season of giving why not consider adding ULS logging to your customizations for your SharePoint administrators. When troubleshooting a critical issue around the holidays nothing goes better with the old Eggnog and Jack Daniels than some good old fashion, the way your mama did it, diagnostic logging. In this post I will show you a pattern that I use which not only provides an easy way to add that logging to your SharePoint customizations, e.g.. one method call, but also allows the SharePoint Administrator, tat has to keep your code up and running, the ability to customize and manage the Tracing and Event levels from within Central Administrator just like any other logging component within SharePoint Server 2010.
In this blog post I am going to show how to use an alternate rendering mechanism to render Managed Metadata Fields which allows them to behave like standard Choice Fields.
A Brief Background
Managed Metadata fields are a really cool feature of SharePoint 2010. They allow an administrator to configure a field in SharePoint to source its values from one or more terms within a term set. Terms can be used in a number of ways such as tagging and in fields within lists and libraries. I have had several of my customers want to move away from using Choice based fields for some of their content types to Managed Metadata fields however the editing experience changes. Choice fields usually render as either a dropdown list or in the case of where multi values are a set of checkboxes for each potential choice value. Managed Metadata Field editing is done with a single textbox which leverages AJAX to implement type ahead auto population. As a result a user can start typing part of the name of a term and a list will pop within the UI to help filter the choice of terms. There is also a button next to the textbox which allows the user to popup a modal dialog that displays the choice of terms. As you can probably tell by this description the user experience can be quite different when moving from a SharePoint Choice Field to a Managed Metadata Field and users will most likely find this move at least a little confusing.
In a previous blog post I talked about how you can use XSLT to display additional Managed properties returned from Search. In this post I want to talk about the method I went about to create the XSLT in the hopes that you find it an interesting enough pattern to use should you find yourself creating some of the same visualizations for Search, the CQWP, Lists, or the BCS WebParts which all use XSL to transform XML into HTML.