Showing posts with label Visual Source Safe. Show all posts
Showing posts with label Visual Source Safe. Show all posts

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.

Monday 12 July 2010

VS2010 deployment error Site Url property missing

Overview: Each new developer on a project grabs the solutions/project files from TFS or VSS as in my case. When they try deploy the solution, they receive an error "Error occurred in the deployment step 'Recycle IIS Application pool': Cannot connect to the SharePoint Site: http://... Make sure that this is a valid URL and the SharePoint site is running on the local computer, ... Update the Site URL property on the project."
Resolution: As the error suggest go to the project being deployed and ensure that you local development url is entered in the "Site URL" property. Obviously this setting should not be stored in source control as it will often differ per environment/developer.
Visual Studio 2010 Project properties

Tuesday 29 June 2010

SharePoint 2010 using VS 2010 and Visual Source Safe 2005

Overview: Client is implementing SP 2010, they don't have TFS and the source control is Visual Source Safe (VSS) 2005.
Steps to integrate VS2010 into VSS 2005:
  • Install the VSS client on your development server/environment;
  • Open the VSS explorer and add the project (Subsequent developers need to locate the file and download a copy) and set the working directory if pulling the project;

  • Open VS2010, select Tools > Options > Source Control > Plug-in Selection > Change the source control to "Microsoft Visual SourceSafe";


  • I prefer to hold my solution file locally and pull my projects however a lot of architects prefer to keep the solution in Source Control. Open the solution in VS2010 and you should be ready to run.
  • Tip: If you projects won't deploy click on the project and look at the "Site Url", this gets cleared down. Enter you local development server url i.e. http://demo1.app.dev/