Muhimbi’s SharePoint development guidelines available for public download

Posted at: 11:58 on 19 May 2009 by Muhimbi

BibleIf it wasn’t for the active SharePoint community, who have filled in the many gaps in Microsoft’s SharePoint documentation, it would be virtually impossible for the developers in our organisation to do any kind of half decent SharePoint development.

Although we have been happily sharing our knowledge and experience on this blog, we feel we have to do something more, which is why we have decided to make our internal SharePoint development guidelines documentation available for download.

Let’s put a big fat disclaimer first: These guidelines have been written with our internal developers, environment and products such as our PDF Converter, URL Shortener and Audit Suite in mind (spot the subtle, yet shameless, plug). There is some valuable information in this document, but not everything may apply to your situation, team or company. Feel free to rip the document apart, rebrand it so it looks like you wrote it, we don’t mind. However, we would appreciate it if you would include a link to this blog posting in any derivative works.

Let’s disclaim a bit more: This is not a SharePoint Tutorial, existing SharePoint development knowledge is assumed, the document is constantly being revised, we don’t guarantee that ANY of the information in the document is accurate, use at your own risk etc. etc.

Now, having said that, this document is serving our internal developers well. I cannot imagine that anyone has memorised it, but it is very useful to read at least once and then use it as a reference to get to the real information.

The following topics are covered:

GuidelinesTOC

Even if you consider yourself a SharePoint expert it is worth a look, particularly chapters 8 Dealing with version numbers and 9 Sharing Libraries and DLLs between SharePoint solutions may be of interest.

Over the next few weeks and months we will discuss each section in a separate blog posting to allow an open discussion to take place.

We would like to thank Brian Farnhill for reviewing an early version of this document in early 2009.

Constructive feedback is always welcomed. Either use the comments section at the bottom of this posting or any of the facilities listed on the Contact Us page. If you find this information valuable then please subscribe to our RSS feed and feel free to evaluate our products.

 

Download the SharePoint Development Guidelines in docx format.

.






Labels: ,

11 Comments:

  • I see several improvements I'd make. An important one is when making changes to the web.config file.

    It is critical to use the SPWebConfigModification Class as SharePoint maintains the web.cong within the Content_DB in addition to the file system.

    Ensure the Owner property of the SPWebConfigModification object is set to the solution id (the GUID string) of the feature associated with the web.config changes. For a feature receiver that is installed from a different WSP file and makes web.config file changes for a feature, use the solution id of the target feature WSP file.

    By Anonymous Steven Fowler, At 19 May, 2009 14:38  

  • Hi Steven,

    Thanks for that, we have been struggling with undoing the changes made by declarative web.config changes (http://msdn.microsoft.com/en-us/library/ms439965.aspx) so will probably move to a model that uses a code only approach.

    Are you saying that when changes are made declaratively these are not stored in the Content Database?

    By Blogger Muhimbi, At 19 May, 2009 14:47  

  • * EDIT *
    Config_DB not Content_DB

    By Anonymous Steven Fowler, At 19 May, 2009 14:48  

  • "When changes are made declaratively these are not stored in the Config Database?" Correct.

    A WSP will natively handle the safe control entries for you, but there may be cases where you want to alter the web.config (good example is to temp enable custom error handling and verbosity).

    email me at steven at steven-fowler dot com and I will send some code..

    By Anonymous steven fowler, At 19 May, 2009 15:07  

  • Firstly thanks for article and guidance, I'm really interested in this article as I am tasked to try and work on some guidelines for our internal team. I'm very interested in chapter 9; sharing/using first/third party libraries.

    We are using SVN for source control. Each project resides in it's own repository, I believe therefore the branching you speak of for shared source code isn't an available option to us. Do you know SNV?

    "3. The version number of the branched source code is synchronised with the project it is embedded in (we use a shared SolutionInfo file)."

    Regarding the above, how exactly does this work? Say you checkout V10 of the shared library and you are only on V2 in the new project, what is synced and where?

    Finally about version numbers. Build and revision, both the same? Don't seem the same to me? 0.41734 and 2.41734.

    Appreciate any response.

    By Anonymous Anonymous, At 12 October, 2009 16:27  

  • Hi Anonymous,

    I am somewhat familiar with SVN as I understand it is similar to CVS, which I used many years ago (we are on TFS now). Having said that, I don't know if there is a way to branch between repositories, if this is a problem with SVN or if it is related to the way your company has structured your Source Control system. I cannot give any specific advice on this subject, but have a look on-line as branching shared libraries is a very common topic that is not specific to SharePoint development.

    Regarding the shared SolutionInfo file, this belongs to the Project and not to whatever library you are branching into the project. As our Shared Library Project files use the same structure as our individual projects, the fact that the SolutionFile is located at the same (relative) path means it will automatically be picked up. If your structure is not identical then you may need to fix this up post branching.

    For more information on using a Shared SolutionInfo file, see http://www.google.co.uk/search?q=c%23+use+shared+solutioninfo+file

    The point we are trying to make in the development guidelines is that by keeping your shared libraries in separate projects and branching the source in whenever is convenient to you or the project makes change (in both ways) relatively easy to manage and solves some of SharePoint's versioning problems.

    Regarding the versioning and keeping the Build and Revision numbers the same, see the footnote on page 31.

    By Blogger Muhimbi, At 13 October, 2009 10:30  

  • Much appreciated. I beleive we can use the SVN:Externals property to force checkout code from another repository. It can target a particular revision if required too. Devs checking out the main project don't need to care about it as the link is taken care of. This means the source will become part of the new assembly but I beleive this is what your process does any way?

    Do you combine all projects (for 1 application) into one assembly for your WSP, or let your WSP deploy many?

    By Anonymous Anonymous, At 15 October, 2009 08:51  

  • You are correct, the 'shared' source becomes part of the new project and can be merged (in both ways) when convenient.

    We merge all external (3rd party) assemblies into the Project's main assembly to make sure removal of the solution doesn't wreak havock on any other solutions (which we don't control) that may use the same libraries. So far this has been working well for us.

    For the rest, we keep all our own assemblies separate. We could merge them together, but as we guarantee unique version numbers there is no need for this extra level of complexity.

    By Blogger Muhimbi, At 15 October, 2009 09:00  

  • Wow! A lot of time saving information your Development Guidelines documentation. It will greatly serve as a jump start to our Agencys guidelines. Full credit to Muhimbi will be given of course, but just wanted to take time to say ....Thank you!

    By Anonymous AA, At 26 October, 2009 00:40  

  • Thank you for the detailed guidelines. I am curious to know if you are planning on posting an updated version that applies to practices for the SharePoint 2010 and Visual Studio 2010 development any time soon?

    By Anonymous Anonymous, At 24 January, 2011 16:29  

  • The guide is due for an update, including specifics for SharePoint 2010, but it is unlikely that we'll go into detais about using VS2010's SharePoint functionality as that is not suitable for our purpose.

    We did write a couple of posts about porting a SharePoint 2007 project to SharePoint 2010. For details see http://blog.muhimbi.com/2010/03/porting-sharepoint-2007-wspbuilder.html

    By Blogger Muhimbi, At 24 January, 2011 16:40  

Post a Comment

Subscribe to Post Comments [Atom]

Subscribe to News feed

Headlines
Archives