This is more for my benefit as a reminder of steps, but if you use Makecab.exe for your .wsp packages, it is important to install new versions that don't step on old versions.  I keep old versions set to "No New Instance" and then New versions pick up the new version of the workflow. New Version of Sharepoint workflow using a .wsp Package Solution – add Solution folder “Deploy” Add Manifest.xml (xml) Add Solution.ddf (text)   1. Manifest.xml – change SolutionID using New Guid 2. Manifest.xml-change Destination Location folder to include version number. 3. Change Assembly version to next version, Properties, Application, Assembly Information 4. Solution.ddf – change CabinetNameTemplate 5. Solution.ddf – increment version on Feature Folder name (2nd name, leave first folder same since this is the source folder). 6. Feature.xml, change feature ID to new GUID. 7. Feature.xml- change Title to include version number 8. Feature.xml-Change Description to include version number 9. Workflow.xml –Change Name  to include [...]

 By creating a list of application errors, you can take advantage of all the Sharepoint goodness like metadata, alerts, etc.  This post shows how to add a complete Error Management system for custom sharepoint errors, with alerts .  It’s really pretty simple, use the existing Sharepoint lists and alerts to help you stay up to date with any application errors. Create a list to hold your application errors.  See below for a screenshot. Title Application URL Message Inner Exception Source Stack Trace   click to expand  2. From your custom code, create a utility method (I usually have this in a utility class) to add items into the Application Error list.  Pass in the Error, the url, the Title, and the url to your web that contains the error list.  I tend to use constants as much as I can. Note that I also write the error into the Event Log, [...]

SQL Reporting Services in Sharepoint Integrated Mode (MOSS 2007) has always been a little quirky to install, but can be very convenient to organize reports, by leveraging all the Sharepoint metadata, permissions, grouping, filtering and other user interface features. Reporting Services defaults to 60 days for the execution log.  To change it, go to Central Administration, Application Management, Reporting Services, Set Server Defaults and change the Report Processing Log. To find out how often reports are being used in your sharepoint installation, you can query the RSSharepoint.Catalog table, join on the Execution Log, and then join against the SP databases to get the metadata for the reports.  Below is a sample query: (replace list ID with your Report Library list ID)  --Gets metadata from SP database Use WSS_Content_XX_DB1 SELECT  A.tp_leafname As RDL, A.ntext2 as Description, A.ntext3 as Business_Group, A.ntext4 as Application INTO #Temp1 FROM AllUserData A INNER JOIN AllLists L ON [...]

As developers we always look for the latest technology, but after many years, clients tend to keep applications beyond their expected time.  I am lucky? enough to have an application that has been in use for close to 10 years.  The problem with this is that the underlying server software is no longer supported and we have to migrate the application. So, the decision is keep it on an unsupported platform, or move to a newer platform. Here's the site that shows the support dates for MS products: http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=windows&Filter=FilterNO Here's a sample of the support lifecycles: Windows Server products are at the top and all the Sharepoint products are at the bottom. Products Released General Availability Date Mainstream Support End Date Extended Support End Date Service Pack Support End Date Windows 2000 Advanced Server 3/31/2000 6/30/2005 7/13/2010   Windows 2000 Datacenter Server 11/13/2000 6/30/2005 7/13/2010   Windows 2000 Professional Edition [...]