For the default Month and Day view, you can apply the following style:

.ms-calheader img { width: auto; }

This will reset the width for a spacer image that the fine folks at Microsoft have decided to give this enormous amount of width to.

For the Week view, you need an additional style rule (hold your breath for this one):

.ms-cal-wtopday div img, .ms-cal-wtopdayL div img, .ms-cal-wtopdayLover div img, .ms-cal-wtopdayover div img, .ms-cal-wtopdayRTL div img, .ms-cal-wtopdayRTLL div img, .ms-cal-wtopdayRTLover div img, .ms-cal-wtopdayRTLLover div img, .ms-cal-wtopdayfocusover div img, .ms-cal-wtopdayfocusLover div img, .ms-cal-wtopdayfocusRTLover div img, .ms-cal-wtopdayfocusRTLLover div img, .ms-cal-wtopday-todayRTLover div img, .ms-cal-wtopday-todayRTLLover div img, .ms-cal-wtopday-todayRTL div img, .ms-cal-wtopday-todayRTLL div img, .ms-cal-wtopdayfocusRTL div img, .ms-cal-wtopdayfocusRTLL div img, .ms-cal-wtopdayfocusL div img, .ms-cal-wtopdayfocus div img
{
width: 80px;
}

Holy smokes! Good thing were not optimizing stylesheets for web performance right? This is a cumulative width that is specified for each day column. The value for the width you specify here will by multiplied by 7 to make up the overall width for the view.

Until one day I stumble upon this lovely error:  “Trying to use an SPWeb object that has been closed or disposed and is no longer valid”

So I google it and find out that I’m trying to dispose the current context of an SPWeb that needs to be used by other controls on the page.

Those familar with SharePoint development will know that this is a recipe for diaster. Typically, development for SharePoint is done within an isolated Virtual PC and for good reason.

Unfortunately our Systems team got wind of our plans to host local virtuals running Windows Server with SharePoint and the idea was quickly killed as a violation of “policy” (apparently all servers should be managed by our system admin team, even those used exclusively for development).

So, if you find yourself in a similar situation and need ammunition as to why each developer should have an isolated environment, feel free to use the following:

Why Individual Development Environments?

Initial SharePoint development cannot be done on a shared server (with concurrent users) for the following reasons:

• Global Assembly Cache (GAC) – SharePoint development often requires custom applications and libraries to be deployed to the GAC. If two or more developers are working on a class library that outputs a DLL with the same name, then deploying that DLL to the GAC will only include changes made by a single a developer. Multiple developers will not be able to keep track of current deployments by other developers or be able to test their individual changes.
• Build & Compilation – Code compilation is an extremely processor intensive task that often requires 100-percent CPU utilization for the length of the compile.  A developer is constantly recompiling code to test and debug, if multiple developers are sharing the same machine, then this would undoubtedly result in constant CPU usage and unusable system performance. Additionally the Visual Studio development environment is an extremely resource intensive application. It is not uncommon for a single instance of Visual Studio to use at least 500MB or to regularly drive high levels of CPU utilization.
• Unreliable Server Availability – Deploying code often requires IIS services and application pools to be recycled or restarted. In a shared development environment with multiple developers it will be unfeasible for a single developer to effectively test changes or debug problems if other developers could be causing application errors by restarting system services.

Microsoft’s Recommendations:

• “Most SharePoint developers use a local SharePoint installation. This allows them to build, test, and debug their work without affecting the work of anyone else on the team. The local environment can be installed on either the developer’s host workstation or on a virtual computer that runs on either Microsoft Virtual PC 2007 or Microsoft Virtual Server 2005 R2.”
  (http://msdn.microsoft.com/en-us/library/dd239299.aspx)
• “When each developer has her own instance of SQL Server 2005 and Office SharePoint Server 2007 or Windows SharePoint Services 3.0, this configuration helps prevent conflicts during development, mitigates performance issues during debugging, and ensures that the solution works in multiple environments.”
  (http://msdn.microsoft.com/en-us/library/bb330848.aspx)
• “First and foremost, you need to develop locally for the “best” debugging and testing experience. Development is done in a virtual machine using the Win2003 OS and WSS/MOSS installed.  Each developer should have their own virtualized environment…”
  (http://blogs.msdn.com/scaravajal/archive/2008/04/27/creating-a-sharepoint-development-environment.aspx)
• “Working locally…you can configure the development environment so that all of the SharePoint development work can be done locally…We recommend this configuration for a number of reasons…”
  (http://msdn.microsoft.com/en-us/library/bb530302.aspx)

Feel free to add any other suggestions…