WSPBuilder Fails to Copy Assembly to GAC

Small tip I just found when having an issue using the WSPBuilder "Copy to GAC" option.

For this one particular web part assembly, when selecting that WSPBuilder "Copy to GAC" option from the context menu in Visual Studio, the copy operation failed with the following message:

System.BadImageFormatException: The module was expected to contain an assembly manifest

Examining the references in that Visual Studio project, I found that one reference for some reason had the "Copy Local" property set to True. By setting this to False (and thereby matching the settings for all the other references), the assembly successfully copies to the GAC using WSPBuilder

And I Quote, “Problem I Find With SharePoint…”

Just been reading a newsgroup posting in which the author recommends to “avoid SharePoint” as a CMS and to “build your own so it can adapt and fit 100% into your business”.

Why that suggestion? Judging from the rest of the post it seems to boil down to this - “Problem I find with SharePoint is it allows everyone to become a publisher and sites quickly get out of control with everything being dumped on it”.

Could rephrase that sentiment as “problem I find with a hammer is that it allows everyone to knock in screws and so splits the timber”. SharePoint is but a tool. And as a tool, it needs policies and procedures in place to give guidance and control over its usage.

SharePoint doesn’t allow everyone to be a publisher – the IT department who deploys it or the power users who configure it are the ones who can decide to allow everyone to become a publisher.

It’s the same with any corporate software tool or platform; governance and planning are vital from the very start of the implementation cycle. As is gaining a thorough understanding of the tool.

MOSS Install - Tips from an MS Field Engineer

Tips from a Microsoft premier field engineer on how to achieve a "... less painful experience ..." when faced with a MOSS install - http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=9

(and here's another useful post on configuring Alternate Access Mappings)

Simple script to Remove and Redeploy a Feature

This script deactivates and deletes an existing feature, then redeploys this feature - it is useful when modifying features during development:


REM Add the 12 Hive bin folder to the path for access to STSADM
@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

REM Configure local values
set siteURL=[site URL here]
set featureName=[Name of the feature]
set WSP=[Name of the WSP file, including the WSP extension]

REM Go to the folder containing the WSP file
cd [Full path to the folder holding the WSP file]

REM Remove the solution
stsadm -o deactivatefeature -name %featureName% -url %siteURL% -force
stsadm -o retractsolution -name %WSP% -immediate
stsadm -o execadmsvcjobs
stsadm -o deletesolution -name %WSP% -override
stsadm -o execadmsvcjobs

REM Add the solution
stsadm -o addsolution -filename %WSP%
stsadm -o execadmsvcjobs
stsadm -o deploysolution -name %WSP% -immediate -allowgacdeployment
stsadm -o execadmsvcjobs
stsadm -o activatefeature -name %featureName% -url %siteURL% -force

Adding Custom Build Steps to a Visual Studio Project

Developing a solution to deploy a timer job involves modifying the CSPROJ file (an MSbuild file) to call the MakeCab utility - this creates a WSP file.

I found that adding an Import statement referring to the custom Targets file (in this case named BuildSharePointPackage.targets) from within the CSPROJ file didn't always produce the right output.

The cause was that MSBuild executes the last build target in order of appearance of Import statements. The csproj file included:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="BuildSharePointPackage.targets" />

The BuildSharePointPackage.targets file did not call any of the standard compile statements in the Microsoft.CSharp.targets file used to build C# projects, so the dlls were not getting rebuilt, and old versions os the dlls were being placed in the WSP file.

The solution was as follows:

1. Set the DefaultTargets attribute in the Project element of the csproj file to equal the Name attribute of the Target element in the custom targets file:
   <Project DefaultTargets="BuildMossPlus" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   
2. Add a DependsOnTarget attribute to the Target element in "BuildSharePointPackage.targets":
   
   <?xml version="1.0" encoding="utf-8" ?>
   <Project DefaultTargets="BuildMossPlus" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
       <MakeCabPath>"C:\Program Files\Microsoft Cabinet SDK\BIN\MAKECAB.EXE"</MakeCabPath>
     </PropertyGroup>
     <Target Name="BuildMossPlus" DependsOnTargets="$(BuildDependsOn)">
       <Exec Command="(SOME COMMAND)"/>
     </Target>
   </Project>
   

(with help from the MSBuild Team Blog)

SPSchedule String Formats (the FromString method)

When establishing timer jobs by defining an SPSchedule in a feature receiver (as per Andrew Connell's excellent article), the schedule can be entered using the FromString method of the SPSchedule class - see this post by Mark Arend for the acceptable string formats.

Note that this is a static method!

There is a lot of choice and flexibility in the permitted formats - some examples are "every 15 minutes", "hourly between 10 and 12" and "monthly at 1 09:00:00"