Hugo Esperanca - Tuesday, April 28, 2009
In part 1 of this post I’ve talked about the principles behind the creation of a Deployment Baseline during the development of SharePoint based applications. In this post I’m going to talk about how we, at Collaboris. normally group and categorise the different artefacts to create this baseline.
This post assumes that you are familiar with the concepts of SharePoint Features, Site Definitions and Solution Packages. For a primer on these concepts please refer to this page on MSDN.
There has always been a lot of debate around the best way to deploy SharePoint applications. Some people do not like Site Definitions or Features and prefer to use Site Templates (.stp), others prefer xcopy deployment and others like me stick with Features and Site Definitions deployed using Solution Packages. I’m not going into that debate here, I’m simply going to describe the approach that we have been taking for the last few years without any regrets.
Like I’ve mentioned on the first post I’m strong believer in using the SharePoint Features and Solution Framework for the delivery of SharePoint applications. We normally try to deploy most of the artefacts via Features which are activated via Site Definitions and deployed using ...
Full story
Comments (0)
Category:
Tags:: Deployment SAF Best Practices SharePoint
Hugo Esperanca - Sunday, April 26, 2009
One of the major lessons that I’ve learned so far with SharePoint development is how important it is to clearly define your Deployment Baseline from very early stages in the development lifecycle. In part 1 of this blog post I will describe the concepts behind this Deployment Baseline and in part 2 I will describe how in Collaboris we apply them to the development of SharePoint applications.
A deployment baseline is a clear definition of the artefacts that are going to be built and deployed when creating a new application. These artefacts should be catalogued and grouped based on their purpose, functionality and on how we plan to deploy and maintain them once the application is live. This baseline will also help to clearly define the different areas of responsibility within the team.
Imagine that you are developing a new Web Content Managed application where the development team is responsible for the creation of all the technical artefacts (ASP, HTML, CSS etc) and the business team is responsible for the creation of content (pages and documents). In this scenario it will make sense to create two separate packages; one for the technical artefacts the other for the content artefacts. These ...
Tags:: Deployment Best Practices SharePoint
MOSS has been the most successful server product Microsoft ever released. Sales are growing much faster than Microsoft ever expected and apparently the UK is outstripping worldwide growth (for more see this). Unfortunately this quick growth is also highlighting one of the major problems that everyone seems to be struggling with - deployment. I've been working with MOSS since Beta 2 and I have debated this issue with other colleagues and we are all in agreement: deployment is one of the biggest pains on any SharePoint project. It's one of the areas that will give you more problems and cost you more money. What is curious is that all companies adopting SharePoint seem to go through the same evolution path. Finding a way to measure where my customers are on this path gives me a good idea on the challenges that I will be facing when moving their projects forward. The kind of measure that I'm talking about it's called a Maturity Model so I called it the Deployment SharePoint Maturity Model (SDMM).
Like the Capability Maturity Model (CMM) I divided the SDMM is divided into 5 levels (except for level 4, I have used the same names ...
Tags:: Deployment SharePoint
Excellent list on SharePoint Web Content Management resources compiled by one of my favourite SharePoint authors - Andrew Connell. You will find it here.
Mark Jones - Tuesday, April 21, 2009
Sorry about the title, but, this blog posting is an attempt to save you from the nightmare I have just been through so wanted to be descriptive.
Here's my rig:
I am running a Windows 2008 Enterprise Server with SharePoint 2007 64 bit and Visual Studio 2008.
I have been trying to create an MSI (using VS), that installs Action Server on a SharePoint 64 bit platform. My main problem arrives when the installer attempts to run my Custom Action. The Custom Action is responsbile for installing evaluation licenses into the SharePoint Config databases. Every time, my Custom Action hits a line containing, "SPFarm.Local", the installer would throw an error like this :
"Attempted to Load a 64 bit assembly on a 32 bit platform"
After a bit of research, the main crux of the problem is that (by default) the Custom Action runs as a 32bit process and attempts to load the Microsoft.SharePoint.dll (which is 64 bit). Hence, the error. So, how do you get around this ?
Well in short, we offer big respect to Heath Stewart! The solution isn't a coded solution, or some property you can flick inside of the Visual Studio Project. You need to ...
Display as : cloud | list
© 2009 Collaboris Ltd. All rights reserved.
Sitefinity ASP.NET CMS