WCF error: could not find default end point element that references contract

Posted on June 23, 2012 by Sundar Narasiman

I was trying to consume an IIS hosted WCF service, got this error “could not find default end point element that references contract in the ServiceModel client configuration. This might be because no endpoint element matching this contract could be found in the client element”.

I fixed it by performing the following steps:-

1. Included the following namespace in the WCF client component

using System.ServiceModel;
using System.Runtime.Serialization;
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

If the WCF client project is of type .NET 3.5 or higher, it will have references to System.ServiceModel.dll and System.Runtime.Serialization.dll. It will not have references to those namespaces in the code, this needs to be added.

2. Changed the name of the client configuration file from ‘output.config’ to ‘app.config’. When I generated client proxy using svcutil.exe, I set the default name of output.config and this needs to be changed to ‘app.config’.If your client is a web application, you can copy the contents inside System.ServiceModel to the web.config

After doing the above 2 steps, my WCF client worked like a charm.

Subscribe to my blog

How to implement logging in SharePoint 2010–Part 3

Posted on June 21, 2012 by Sundar Narasiman

In this post, I’d be focusing on how to create custom log entries using the SharePoint Logger (ILogger) component.

The LogToOperations methods and its overload can be used to create the custom log entries to Windows event log and the SharePoint 2010 ULS log.

It is recommended that enough information is provided to IT professionals to remediate the problem, when an event is logged using SharePoint Logger component
The default implementation of the LogToOperations method will write the event to the Windows event log and the ULS log.
Do not log the events to the event source with limited information, like only the event message below :-

IServiceLocator oServiceLocator = SharePointServiceLocator.GetCurrent();
ILogger oLogger = oServiceLocator.GetInstance<ILogger>();

// Log an event with a message.
string message = "The current user does not have enough permissions for this operation";
oLogger.LogToOperations(message);

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

It is recommended to provide comprehensive information like Event Id, Error Message and Event Severity while logging.

// Log an event with a message and a severity level.
oLogger.LogToOperations(message, EventSeverity.Error);

// Log an event with a message, an event ID, and a severity level.
oLogger.LogToOperations(message, (int) EventLogEventId.MissingID,
 EventSeverity.Error);

This will help the administrator to filter the log entries based on security level.

For Sandbox solutions the event severity enumeration of SandboxEventSecurity should be used.
Do not use EventSeverity enumeration for Sandbox solutions, it will throw an error
It is also good to have the Event Category logged to the event source

// Log an event with a message, an event ID, a severity level, and a category.
string oArea = "New Custom Area"
string oCategory = "Operations";
string oAreaCategory = string.Format("{0}/{1}", oArea, oCategory);
logger.LogToOperations(msg, (int) EventLogEventId.MissingID,
                       EventSeverity.Error, oAreaCategory);

Do not leave the DiagnosticsArea and DiagnosticsCategory as unspecified.
Because the SharePointLogger will assign a default value of ‘Patterns and Practices’ to the area value and the default value of ‘SharePoint Guidance’ to the Category.
The exception messages can also be directly passed as the parameter to the LogToOperations method. This should be avoided as much as possible

Subscribe to my blog

How to implement logging in SharePoint 2010–part 2

Posted on June 20, 2012 by Sundar Narasiman

This post would focus on how to create & manage custom log areas and custom log categories.

It is always recommended to create custom logging areas and categories using SharePoint Logger. The custom logging areas and categories makes life easier for system administrators. So that the system administrator can apply throttling rules to the applications in the same way that they configure logging and reporting from the other SharePoint applications.

The AddAreas and RemoveAreas methods of DiagnosticsAreaCollection can be used to add/remove areas of the diagnostic logging. The AddCategory and RemoveCategory methods of DiagnosticsCategoryCollection can be used to add/remove categories of the diagnostics logging.
The following snippet illustrates how to add DiganosticsArea and DiagnosticCategory to the SharePoint Logger.

       //Creates a new Diagnostic Area
        DiagnosticsArea oDiagnosticsArea = new DiagnosticsArea("Any Area1");

        //Add 1’st Diagnostics Category   
        oDiagnosticsArea.DiagnosticsCategories.Add(new DiagnosticsCategory(
            UI", EventSeverity.Error, and TraceSeverity.Medium));

        //Add 2’nd Diagnostics Category
        oDiagnosticsArea.DiagnosticsCategories.Add(new DiagnosticsCategory(
           "DataAccess", EventSeverity.Warning, and TraceSeverity.Medium));

It is always recommended to assign the application name to the Diagnostics Areas, which is easier for troubleshooting.
To save the Diagnostics area and category to the SharePoint environment, pass the instance of IConfigManager to the DiagnosticsAreaCollection.
Then, invoke the SaveConfiguration method of DiagnosticArea class to save all the custom areas and categories (of your application) to the SharePoint environment.
Do not use the default constructor of DiagnosticsAreaCollection and invoke the SaveConfiguration method together, this will cause an InvalidOperationException.
It is always recommended to use the overloaded constructor of DiagnosticsAreaCollection and invoke the SaveConfiguration method together
Do not add an area that already exists on the DiagnosticsAreaCollection, this will throw an InvalidOperationException.
Leverage the Remove method of DiagnosticsAreaCollection to remove the individual areas

IConfigManager oIConfigurationManager =
    SharePointServiceLocator.GetCurrent().GetInstance<IConfigManager>();
DiagnosticsAreaCollection oDiagnosticsAreaCollection = new
    DiagnosticsAreaCollection(oIConfigurationManager);

foreach (DiagnosticsArea oDiagnosticsArea in MyAreas)
{
  DiagnosticsArea oAreaToRemove = oDiagnosticsAreaCollection[oDiagnosticsArea.Name];

  if (oAreaToRemove != null)
  {  
    oDiagnosticsAreaCollection.Remove(oAreaToRemove);
  }
}
oDiagnosticsAreaCollection.SaveConfiguration();

Leverage the Remove method of DiagnosticsCategoryCollection to remove the individual categories

foreach (DiagnosticsArea area in oMyAreas)
{
  DiagnosticsArea oAreaToRemove = oConfiguredAreas[area.Name];

  if (oAreaToRemove != null)
  {
    foreach (DiagnosticsCategory c in area.DiagnosticsCategories)
    {
      var oExistingCategory = oAreaToRemove.DiagnosticsCategories[c.Name];
      if (oExistingCategory != null)
        {
          oAreaToRemove.DiagnosticsCategories.Remove(oExistingCategory);
        }
      }
      if (oAreaToRemove.DiagnosticsCategories.Count == 0)
      {
        oConfiguredAreas.Remove(oAreaToRemove);
      }
    }
  }
}

Subscribe to my blog

How to implement logging in SharePoint 2010–part1

Posted on June 20, 2012 by Sundar Narasiman

Nowadays I’m doing lot of code review for SharePoint 2010 projects. One of the thing I’ve noticed is that the developers don’t understand the best practices for implementing logging with SharePoint 2010. This has compelled me to collate the guidance on SharePoint 2010 logging. I’ll be writing series of articles about SharePoint 2010 logging. In this article I’d be providing an overview of SharePoint Logger component and how to create an instance of ILogger object.

It is recommended to leverage the re-usable component SharePoint Logger(Logger) shipped with MSDN Patterns and Practices guidance for implementing logging capablities for SharePoint 2010 development. It provides the capability to write messages to the Windows event logs and ULS trace log. The interface ILogger exposes the following methods:-

ILogger method	Description
LogToOperations	This method can be used to write the Windows event logs and ULS trace logs. The overloaded parameters like identifiers, categories, severities and exception details can be provided
TraceToDeveloper	This method can be used to write to the ULS Trace log. The overloaded parameters like identifiers, categories, severities and exception details can be provided

The following code-snippet illustrates how to

ILogger oLogger = SharePointServiceLocator.GetCurrent ().Get Instance<ILogger> ();

oLogger.TraceToDeveloper ("Unexpected condition");

Creating a Logger object

The first step in logging message to the Windows event log or the ULS trace log is to create an object that implements ILogger interface. The SharePoint Logger provides a default implementation of this interface in a class named SharePointLogger. The SharePointLogger can be instantiated directly or it can be instantiated through the SharePoint Service Locator. It is recommended to leverage the SharePoint Service Locator pattern for getting the instance of SharePoint Logger, considering separation of concerns and test driven development in mind.

The next logical step is to add the reference to the required assemblies (Microsoft.Practices.SharePoint.Common.dll and Microsoft.Practices.ServiceLocation.dll).

Using Microsoft.Practices.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.Logging;

//Get the instance of Service Locator

IServiceLocator oServiceLocator = SharePointServiceLocator.GetCurrent();

//Get the instance of ILogger

ILogger oLogger = oServiceLocator.GetInstance<ILogger>();

In the next post, I’d be focusing on how to create and manage custom log areas and custom log categories.

Subscribe to my blog

Musings on Cloud, Machine Learning, Kubernetes, MLOps and Distributed Systems

Monthly Archives: June 2012

WCF error: could not find default end point element that references contract

How to implement logging in SharePoint 2010–Part 3

How to implement logging in SharePoint 2010–part 2

How to implement logging in SharePoint 2010–part1