MSBuild - Condition to determine if you are building TFS or Desktop.

Just a nice simple solution on this one.

Create a Target with the following condition:

Condition="'@(SolutionToBuild)'==''" 

 The SolutionToBuild property is populated by TFSBuild.proj so on a local build this will not exist (Unless you created it yourself!)

Full examples below:

<Target Name="NonTFSBuild" Condition="'@(SolutionToBuild)'==''">
  <Message Text="Local BUILD" />
</Target>

<Target Name="TFSBuild" Condition="'@(SolutionToBuild)'!=''">
  <Message Text="TFS BUILD" />
</Target>

Event Throttling

To reset Event Throttling to the out of the box defaults, select All as a category then set Least critical event to report to the event log to Error and Lease critical event to report to the trace log as Medium. The set the following four items to the below settings.

Using STSADM

The following command will set the logging back to default:

stsadm -o setlogginglevel -default

The following command will list the current settings:

stsadm -o listlogginglevels

Trace Log

Ensure that the path is set to a separate drive than the one hosting the operating system and ensure that it has adequate space to hold the log files.

The default values have 48 hours of log files being stored on the server, you can reduce this by changing the number of log files down or decreasing the minutes in a log file.

This is a nice one…

We take product quality seriously and make every effort to avoid and resolve issues that adversely impact our customers.  Unfortunately, we have recently discovered a bug with Service Pack 2 (SP2) that affects all customers that have deployed it for SharePoint Server 2007. 

During the installation of SP2, a product expiration date is improperly activated. This means SharePoint will expire as though it was a trial installation 180 days after SP2 is deployed. The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes. Furthermore, product expiration 180 days after SP2 installation will not affect customer’s data, configuration or application code but will render SharePoint inaccessible for end-users.

We are working to release a hotfix to automatically fix this issue. A manual work-around is currently available and involves customers re-entering their Product ID number (PID) on the Convert License Type page in Central Administration.  For more information and detailed steps please read this KB article.

Real easy work around… Re-enter your Product ID in Central Admin. Done.

More information can be found here: http://blogs.msdn.com/sharepoint/archive/2009/05/21/attention-important-information-on-service-pack-2.aspx

KB: http://support.microsoft.com/kb/971620

I just had a friend drop by who had a question on how to access a web.config or an app.config from a separate class library. This is a fairly typical scenario in any development project where you separate your business logic into a reusable library file. (In Visual Studio this would be a separate project to your application and compiled as a class library and you then add a reference to this project).

My answer was you don’t.

My approach is that any separate class should be stand alone from file based configuration like a web or app config file. If you have complex configuration driving your business logic like custom rules, etc then pass in the location of the configuration to a configuration object in the class, otherwise just pass the properties to the class on instantiation or set a property.

This makes the process of testing and threat mitigation simpler.

SharePoint Content Deployment can be a fun beast at times, this article will walk you through a approach for resolving issues.

While working with a client we had the following error in a incremental job:

The object has been updated by another user since it was last fetched

Since the client was not on the latest patch level and unable to patch at this point in time I want to see if I could resolve it out manually. The problem was I dod not know which site they had edited and replaced the default page on.

Running the job it was failing at object 1829, being the lovely SharePoint that it is I have no way to workout what object is at 1829… or do I?

If you have the system setup to leave the failed cabs on the destination server you can open them up and look for the Manifest.xml files. Once you have these copy them to a place on the system.

The following powershell commands will allow you to find the object that it stopped on so you can resolve it, delete it or recreate it.

PS C:\> [xml]$man1 = get-content .\Manifest.xml
PS C:\> [xml]$man2 = get-content .\Manifest1.xml
PS C:\> $man1.SPObjects.SPObject[1829]

Id              : 2f93cb16-fae5-4344-8549-3f6c5de60863
ObjectType      : SPDocumentLibrary
ParentId        : b677f641-222c-4185-9cf4-e916174b316b
ParentWebId     : b677f641-222c-4185-9cf4-e916174b316b
ParentWebUrl    : /SiteCollection/SubSite
Url             : /SiteCollection/SubSite/Pages
DocumentLibrary : DocumentLibrary

This is a great tool! This link is so I do not forget the name of it

http://www.anvir.com/taskmanager/