Monday, January 14, 2013

Put all your POCO’s in a PCL

We recently introduced a small, but useful, change to our Windows 8 solution.

We put all our POCS’s in a PCL.

POCO = Plain Old CLR Objects (POCOs)

PCL = Portable Class Library

Windows 8 Store Apps can leverage only a subset of the .Net framework.  Same applies for Silverlight or Windows Phone projects.  Which means that we cannot reference a regular .Net Assembly from a Windows 8 App, as the .Net assembly could be using classes which are not available to Windows 8 Apps.

In Visual Studio, if you try to refer a .Net class library project from Windows Store App project, you will get an error: Unable to add a reference to project 'ClassLibrary1'. The error message is not very useful. The error message when you try to reference an .Net assembly instead of a Visual Studio Project is more informative: A reference to 'ClassLibrary1.dll' could not be added. The project targets '.NETCore' while the file reference targets '.NETFramework'. This is not a supported scenario.

Multiple Copies of Code:

Without Portable Class Library (PCL), if you are developing an Application which needs to be supported on different Microsoft frameworks, you may end up duplicating the code for each of the platforms. Over a period of time, you might end up with a lot of almost similar, but duplicate code on each of the platforms. This of course is difficult to maintain.

PCL to the rescue:

Portable Class Library (PCL) project in Visual Studio 2012 comes to the rescue. In a PCL project, you can use only those classes which are supported across the different platforms. A PCL project or assembly can be referenced from Widows 8 Store App, Windows Phone App, and Silverlight application.

When should we use PCL?

Some useful scenarios are:

·         If you plan to write a application which you plan to support on different .Net platforms in future

e.g. You are developing a traditional Windows App for Win 7. Your organization does not even allow Windows 8 OS to be installed on its machines (as of today). Even if you have no current plans for targeting Windows 8 Apps, you can make it easier to upgrade (in future) by using PCL as much as possible.

·         Entity Classes in PCL:  e.g. You are developing a Windows 8 App which calls a .Net Web Service.

This was the scenario I was working on. The Windows 8 App called a .Net Web Service (REST using ASP.Net Web API to be more accurate) for data. We had defined classes to pass the data from Web Service to the Win 8 App (being developed in XAML and C#). Before PCL, we ended up defining the same entities twice, once for the Web Service project and once for the Win 8 App project. So maintenance was becoming an issue. We have now put all our entity classes in a PCL, so that they can be used by both the Web Service and the Windows 8 App projects.

To know more about PCL, refer the Microsoft link:
http://msdn.microsoft.com/en-us/library/gg597391.aspx

.Net & SharePoint Coding Standards and Best Practices document

What are your .Net / SharePoint Coding Standards? Where is your SharePoint Best Practice document?

Many customers have posed this question at some point of time or other. And organizations spend lot of time and effort to create the documents (often only to impress customers). A senior resource in the team, an Architect or a Tech Lead, is usually allocated the task of creating the document. However, Coding standards need to be updated with every new release of the product, .Net or SharePoint. Keeping the document updated with the new release of products is an ongoing task. And we have seen SharePoint guidelines (for when to Dispose, and when not to Dispose) change for few scenarios in past.

I often come across Coding standard documents that are for .Net 2.0 or .Net 3.5 being used in today’s projects on .Net 4.0 and SharePoint 2010/2013. They have not been updated for recent versions of .Net and SharePoint due to various reasons. The document owners are (and most likely will always be) playing catch up with Microsoft releases.

Sometimes, the standards document is created and updated, but team members are not aware and educated about the same. The standards remain only on paper if not enforced in reality.

In my opinion, unless there is required expertise, long term commitment and budgets, Enterprises should stop maintaining coding standards for .Net and SharePoint.  

No, No…I didn’t say that there is no need to define them.

Microsoft is maintaining the standards and best practices for us. So why reinvent the wheel?

The time originally spent on documenting the standards can be more effectively utilized on educating the team members about the standards, and enforcing compliance towards the same in the organizational projects.

There is a possibility that your organization standards may differ from MS Standards (mostly related to naming conventions). In such cases, only the differences need to be captured instead of recreating entire standards.

Below are few links that might be useful:

Standards:
·        C# / VB.Net Standards

Choose the version of .Net in above link for your project (Choose .Net 3.5 for SharePoint 2010 and .Net  4.0 for SharePoint 2013)


·        SharePoint 2010 Standards


All the links under “Customization Best Practices” at above link.

Update [11 Sep 2014]: Above link now redirects to a different page in MSDN. Copying relevant links below for reference.

Customization Best Practices

Best Practices with SharePoint Foundation 2010
Learn the latest best practices and guidance that can help you create efficient custom applications in Microsoft SharePoint Foundation 2010 and help avoid common development problems.

Best Practices with SharePoint Server 2010
Learn the latest best practices and guidance that can help you create efficient custom applications in Microsoft SharePoint Server 2010 and help avoid common development problems.

SharePoint Guidance from the Microsoft patterns & practices Group
Learn how to make the right decisions, take advantage of new capabilities, and follow proven practices when building applications for SharePoint 2010.

Disposing Objects
Learn best practices to follow when using SharePoint objects, to avoid retaining objects in memory in the Microsoft .NET Framework.

Handling Large Folders and Lists
Design custom code that works with large folders and lists to optimize performance.

Object Caching Techniques
Learn how to weigh the benefits of caching against the need for thread safety, because some SharePoint objects are not thread safe and caching causes them to perform in unexpected ways.

Writing Efficient Code in SharePoint Server
Troubleshoot and improve the performance of existing and new SharePoint Server applications

 

Best Practices:
·        SharePoint 2010 Best Practices
Update [04 Mar 2013]: Adding another useful link from Microsoft on SharePoint 2010 Best Practices

It’s also important to develop an understanding of why something is a best practice, what are the implications if you don’t follow it. Read the available documentation, discuss with a peer, follow a Master’s blogs, Watch Channel 9 Training Videos, these are some ways to build the depth and breadth.

Update [18 Sep 2013]: Adding SharePoint 2013 Best Practices link
·        SharePoint 2013 Best Practices


Tools:


You can use code review tools for your ensuring the standards compliance in your projects.

·        MICROSOFT SHAREPOINT ONLINE CODE ANALYSIS FRAMEWORK (MSOCAF)
MSOCAF = SPDisposeCheck + Important FxCop Rules + SharePoint 2010 Specific Rules


MSOCAF is an important tool for SharePoint Development. Though it’s created and mandated for SharePoint Online team, it can be used for On Premise projects also.

Update [18 Sep 2013]: Adding SPCAF
·        SharePoint Code Analysis Framework (SPCAF)
SPCAF is another useful tool for SharePoint Developers and available here.
SPCAF has the following advantages over MSOCAF:
1.     SPCAF has 400+ rules that it analyses compared to 120+ rules of MSOCAF
2.     It is easy to integrate SPCAF with Visual Studio 2010/2012 (not yet available for VS 2013).  I don’t think its possible to integrate MSOCAF with Visual Studio.
3.     You don’t need to have SharePoint 2010 installed on a machine to run  SPCAF, which is a limitation of MSOCAF. However, it needs .Net Framework 4.5.
At the time of updating this blogpost, SPCAF is in beta and available as a free download. The authors of SPCAF plan to make it a paid utility in near future.

Update [11 Sep 2014]:
SPCAF is now paid tool.  SPCopCE, SPCop Community Edition, is the free version of  SPCAF and  available here:
http://visualstudiogallery.msdn.microsoft.com/c991a9ed-7a7b-465f-9be3-923443fd6e7b 
For .Net, you can leverage FxCop or Visual Studio Code Analysis or a 3rd Party tool of your choice.