Hugo Esperanca - Wednesday, May 13, 2009
One of the best articles that I’ve read so far about the importance of properly disposing SPWeb and SPSite objects has been written by one of my favourite SharePoint bloggers Stefan Gossner and can be found here.
Unfortunately there are still some conflicting messages about what to do with SPWeb instances creates via the SPSite.RootWeb property. According to Stefan we need to call dispose but other people from Microsoft are saying the opposite as you can see here.
So the search continues….
Full story
Comments (0)
Category:
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 ...
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.
Hugo Esperanca - Sunday, July 20, 2008
Ever wanted to use the same page layout containing a DFWP, and bind it to a local site list in each site of your site collection ?
Ever want to be able to deploy a page with a DFWP to a different server?
If you ever tried any of the above using SharePoint Designer you would have found problems because, by default, SharePoint Designer binds the control to the list instance using the list instance GUID. To resolve this we need to replace the GUIDs by the list name. The steps to do this are:
<WebPartPages:DataFormParameter Name="ListID" ParameterKey="ListID" PropertyName="ParameterValues" DefaultValue="{GUID}"/>
<WebPartPages:DataFormParameter Name="ListID" ParameterKey="ListID"
PropertyName="ParameterValues" DefaultValue="{GUID}"/>
<WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName" PropertyName="ParameterValues" DefaultValue="LIST_NAME"/>
<WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName"
PropertyName="ParameterValues" DefaultValue="LIST_NAME"/>
<ParameterBinding Name="ListID" Location="None" DefaultValue="{GUID}"/>
with:
<ParameterBinding Name="ListName" Location="None" DefaultValue="LIST_NAME"/>
This should give you a GUID free DFWP that can be placed on a page layout used by multiple ...
Comments (2)
Tags:: SharePoint
Hugo Esperanca - Friday, August 24, 2007
SharePoint should be seen as another layer in the technology stack that your code will interact with. But just because you are using this layer you should not forget to follow good and proven design practices. The following points describe some of the principles that sometimes seem to be forgotten when using SharePoint:
Before SharePoint all configuration needed by you applications resided in a data store (normally ...
Hugo Esperanca - Thursday, March 03, 2005
Those are the three most valuable artefacts of a project. Requirements should drive most (if not all) activities in a project. A project should be architectural centric and requirements driven... We have all heard these clichés before but how exactly does one manage requirements in an iterative process?
How do we make sure that all team members are rowing the same way?
Supporting Iterative Development Through Requirements Management gives a good insight on how effective requirements management can be accomplished in an iterative process - in this case using the Rational unified Process (RUP). Even if you are using another iterative process (like SCRUM or XP) the article should give some good ideas.
If you are not using an iterative process then forget about the article and read "Why should I be using an iterative process" instead.
Hugo Esperanca - Tuesday, March 01, 2005
Unit testing has taken a new momentum with the rise of the agile development practices. NUnit is a fantastic and simple unit-testing framework for all .Net languages but if you used it before you have probably come across the difficulty on how to isolate the unit that you want to test. NMock was created to address this issue. Mock Objects to the Rescue is a very good article on how to use this useful tool.
If you have not used NUnit before you will find a good introduction on the Test Driven C# msdn article.
Hugo Esperanca - Tuesday, December 07, 2004
Isn't it funny that, suddenly, interfaces do not seem to be in fashion in the .Net world anymore ?
In the not so good old days of COM there wasn't an option - if we wanted a component we had to have at least one interface. The abstract server pattern was alive and kicking and the advantages of separating a service contract from its implementation were clear to all (at least to the ones using OO languages). In those days there was a clear distinction between a component (something providing services trough an interface) and a class.
Now, in the new world of .NET, we can have classes, in different assemblies, talking directly to each other. Call me an old fashion geezer but I still strongly believe in patterns like the Separated Interface and Factory (from one of my favourite books Agile Software Development). Perhaps I should go back to my perforated cards...
Tags:: Architecture
Display as : cloud | list
© 2009 Collaboris Ltd. All rights reserved.
Sitefinity ASP.NET CMS