One of the pieces of developing custom components is logging information. No matter if it’s for diagnostic purposes or when an error occurs, logging allows you to track the health of your custom component. When developing custom components for SharePoint 2007 we hadn’t much choice. Although SharePoint 2007 shipped with the Unified Logging Service, we couldn’t use it. The SharePoint SDK was pretty clear about it: although some methods were publicly available, ULS was for internal use only and was not supposed to be used in custom code. Because of this, we couldn’t provide a similar logging experience to SharePoint and had to develop custom logging solutions. SharePoint 2010 changes this situation: using the new ULS is now supported and may be used for logging in custom code.
My deck from the DIWUG event on May 25 is available on-line. So if you either couldn’t make it to the event or want to have the content for future reference, you can get it from SlideShare.
Dutch Information Worker User Group SharePoint eMagazine \#2 has just been published and is available for download. This second issue contains some great articles about Web Content Management in SharePoint 2010, Community Kit for SharePoint: Development Tools Edition (CKS:DEV) and more. Get your copy of the FREE DIWUG SharePoint eMagazine \#2 now!
Tomorrow (May 25) I will be presenting at the Dutch Information Worker User Group (DIWUG) about developer improvements in SharePoint 2010 Web Content Management. We will be not only looking at what’s new in SharePoint 2010 WCM but I will also share with you some tips on how you can get the most of your WCM solutions on the SharePoint 2010 platform.
SharePoint 2010 ships with the Sandbox: a new concept that allows you to deploy solutions with limited trust. Still there are many scenarios to think of when you might need to deploy your work to the Web Application’s BIN directory. When doing that, you need to define for your assembly a CAS policy, which specifies what your code should and should not be allowed to do. While the contents of the policy always depend on your code, I have noticed that there are a few entries that are common for almost every solution deployed to the BIN directory.