Thank God for Windows Home Server!

This week was the first in my new job in Bouvet ASA in Oslo. On the first day I was handed a Lenovo ThinkPad W500 with Windows 7. I installed SharePoint 2007, Visual Studio 2008 and all the dozens of applications and utilities I can’t develop without. After a couple of days I was told it was very likely I would start on a SharePoint 2010 project. Cool! Since the machine only had 4 GB of RAM it was out of the question to run SharePoint 2010 in a virtual machine. I decided to make a VHD with Windows Server 2008 R2, SharePoint 2010 and Visual Studio 2010 and boot from it. At the end of the week I had two complete and separate development environments for both SharePoint versions on my machine. I had even started to prepare for the potential 2010 project by making a test project to investigate some ideas I had.

On Saturday I booted into Windows 7 and read news as usual while eating breakfast. After that I rebooted into Windows 2008 R2 and wanted to work some on my test-project. After the boot load screen I got an bluescreen. Booted into Safe Mode, but again got an bluescreen. Tried to boot into Windows 7 but that bluescreened as well! WTF happened?!?

I would normally boot with a bootable utility CD to be able to fix problem or rescue files, but I thought this was an excellent opportunity to test a restore from my Windows Home Server backup.Luckily I had installed the WHS client on the Windows 7 machine and a full backup, including the VHD, was done Friday night. After 30 minutes downloading and burning the Restore CD and put network drivers on a USB stick – and then 1,5 hour restore time my machine was in perfect state.

Thank God for Windows Home Server!

Advertisements

“Failed to retrieve the list schema for feature” caused by missing BaseView in List element

I needed a very basic custom list template with one custom content type and a few custom fields. I first started by copying schema.xml from a feature I recently used and started to modify it. To make a long story short: I got some errors in the views I couldn’t figure out, so I decided to start fresh by copying the schema.xml from the OOB CustList feature and copy’n’paste needed customization from the “old” schema.xml.

When I tried to create a list I got the famous: 

Cannot complete this action.
Please try again.   at Microsoft.SharePoint.Library.SPRequestInternalClass.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)
   at Microsoft.SharePoint.Library.SPRequest.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)

In the Sharepoint logs I found this:

Failed to retrieve the list schema for feature [FEATURE GUID], list template [TEMPLATE]; expected to find it at: "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\[FEATURENAME]\[LIST]".    
Failed to find the list schema for FeatureId ‘[FEATURE GUID]’, list template ID [TEMPLATE].  Cannot create list in web "[WEBURL]" at URL "(null)".    

This error is often caused by having more than one directory level in the feature folder. But in my case none of the suggestions Google gave me was valid.

I therefore tried to start with a fresh schema.xml but this time without modification. Deployed and added a list. No problem. I thereby modified the List attributes. Deploy. No problem. Added the content types. Again no problem. Added the fields. No problem! Added ViewFields. No problem!!! At this stage the schema.xml was practically identically to the one that caused the error – with one exception: The BaseView=”0” attribute of the List element was included in the working version. Hmmm, the documentation states that this attribute is optional. But as soon as I remove it, the error occurs.

Conclusion: The BaseView attribute is not optional. At least in this case…

Consolidating Application Pools

I had a need to consolidate application pools for several MOSS 2007 sites I had created on my development machine. I had been so stupid that I just created a new application pool each time I created a site. Since Sharepoint Search crawls every site, a new work process (w3wp.exe) was created for each site – even though I didn’t use them. No need to say that this eats valuable memory in my VPC…

This was what I did:

  • Make sure all sites use the same application pool acount in Central Administation > Operations > Service Accounts. I use Network Service for simplicity
  • Make sure authentication providers use NTLM in Central Administration > Application Management > Authentication Providers
  • Do a IISRESET and test that all sites works OK. If something doesn’t work now, it’s easy to go back if you remembered to make a note of previous settings for the first two steps
  • Go to IIS Manager
  • Create a new Application Pool:
    • Call it something reasonable, like “Sharepoint Shared App Pool”
    • Set Identity to the same identity as you used in the first step
  • Configure Application Pool for each web site under Web Sites that you want to colsolidate
    • Right click root of web site and select Properties
    • Under Home Directory, change Application pool to the newly created application pool
    • Expand the _layouts-folder under root and change the application pool for both images and inc
  • Do a IISRESET and test that all sites works OK
  • Delete the application pools you no longer use (when testet that everything works ok!)

View more rows in Edit in Data Sheet

I received an requirement from my boss to display more than the default 6 rows in the Edit in Datasheet view of data lists. I hate this beast (ie. datasheet) because it is really unpredictable (see my previous posting).

After messing around I found the simplest solution was to alter the OOB core.js:

Changed:
cGCMinimumHeight=200;

to:
cGCMinimumHeight=600;

This offcourse makes the change global for all Datasheets and very exposed to future updates from Microsoft. So add it to your list of things to check after next upgrade… 😉

Sharepoint Edit in Datasheet locks or freezes Internet Explorer

Recently I had an issue with a new masterpage for one of the companies in our group of companies. The design is pretty much the same for all companies, just different logo, header illustration and footer image. For some reason IE would hang if the user selected “Edit in Datasheet” in a Document Library.

Googling the problem gave me a couple of hints:

… but none of them helped in my situation.

I tried to implement the new design step-by-step and noticed that the freeze-problem only occured when I changed the footer image. After a lot of trial and error I found what seemed to be the culprit of my problem. The footer image that worked was 322×19 pixels. The image that didn’t work 316×21 pixels. By resizing the footer image I found that as long as the height was 19 pixels I could change the width without any problem. Don’t ask why I tried this in the first place…

This correlates to Tom’s discovery which suggests that the GC-functions that resizes the grid is dependant on the scroll height. When the footer image got taller than 19 pixels – scroll height changes too.

Conclusion: Edit in Datasheet is VERY dependant on the layout. Hope Microsoft can fix this soon!

Enable debug information in Sharepoint

Just a reminder for myself:

 

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<configuration>
  <configSections>
    <sectionGroup name=”SharePoint”>
      <section name=”SafeMode” type=”Microsoft.SharePoint.ApplicationRuntime.SafeModeConfigurationHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
    </sectionGroup>
  </configSections>

  <SharePoint>
    <SafeMode MaxControls=”200″ CallStack=”true” DirectFileDependencies=”10″ TotalFileDependencies=”50″ AllowPageLevelTrace=”false” />
  </SharePoint>

  <system.web>

    <customErrors mode=”Off” />

    <compilation batch=”false” debug=”true” />

  </system.net>
</configuration>