Attached Property in Silverlight 4.0

Hi Friends,

In this article you will learn attached property in silverlight 4.0

There are two types of properties in Silverlight

1.     Dependency Property:  In the last article you learn dependency property briefly

2.   Attached Property: In this article you will learn briefly attached property.

In this article I will cover following topics about attached property

1.     Introduction of attached property

2.    What is attached property?

3.     Why we need attached property?

4.    How to register custom attached property in silverlight

5.     Some Attached properties in silverlight

1. Introduction of attached property

An attached property is a new concept that is defined by Extensible Application Markup Language (XAML). The attached properties are intended to be used as global properties that are settable on any type of object. In WPF/Silverlight, attached properties are typically defined as a form of a dependency property that does not have the conventional property 'wrapper'.

           

2. What is attached Property??

Attached properties are a specialized type of dependency property that is immediately

recognizable in markup due to the TypeName.AttachedPropertyName syntax. For example,

Canvas.Left is an attached property defined by the Canvas type. What makes

attached properties interesting is that they’re not defined by the type you use them

with; instead, they’re defined by another type in a potentially different class hierarchy.

Attached properties allow flexibility when defining classes because the classes

don’t need to take into account every possible scenario in which they’ll be used and

define properties for those scenarios. Layout is a great example of this. The flexibility

of the Silverlight layout system allows you to create new panels that may never have

been implemented in other technologies—for example, a panel that lays elements out

by degrees and levels in a circular or radial fashion versus something like the built-in

Canvas that lays elements out by Left and Top positions.

3.   3.   Why we need attached properties?

The attached properties are a very powerful tool for dynamic extension of classes without inheritance. They also allow us to keep the properties located at their logical places – use what you need only when you need it. Moreover they allow the place, where the property is defined and the place, where it is stored, to be completely different classes that know nothing about each other. Like in the above example the Dock property value is stored in the button instance not in the DockPanel itself.

With the attached properties you can make your classes structure much more comprehensible for the developer by using only the properties that are valid in the specific context.

The good news is that many advantages from the dependency properties model are coming out of the box for the attached properties such as caching, data binding, default values, expressions, styling (which is nothing more than a set of predefined property values), property invalidation and more.

4.  How to create Attached property with example

1. Declare the attached property as static and readonly field in your class.

public static readonly DependencyProperty DockProperty = DependencyProperty.RegisterAttached

(“Dock”, // property name

typeof(Dock), // property type

typeof(DockPanel), // type of the property provider

new PropertyMetadata(Dock.Left, new PropertyChangedCallback(DockPanel.OnDockChanged))); // Property Metadata

2. Create GetDock and SetDock methods that are associated to the attached property.

public static Dock GetDock(UIElement element)

{

   if (element == null)

   {

      throw new ArgumentNullException(“element”);

   }

  

   return (Dock)element.GetValue(DockProperty);

}

public static void SetDock(UIElement element, Dock dock)

{

   if (element == null)

   {

      throw new ArgumentNullException(“element”);

   }

   element.SetValue(DockProperty, dock);

}

3. Create a callback method invoked when the property value is changed.

private static void OnDockChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

{

   // Do something when the property is changed.

   UIElement reference = d as UIElement;

   if (reference != null)

   {

   }

}

The following example code demonstrates how to set the attached property in the xaml markup:

<Button  x:Name=”Item1″  Text=”Item1″  DockPanel.Dock=”Top”/>

The code assumes that the Dock property is an attached property declared in the DockPanel class. 

5.    5.   List of some attached properties in Silverlight

Below you can find a list of some of the attached properties available in .NET Framework. This list is a short reference that was not meant to be complete. I decided to put it here to give you an idea about the way Microsoft uses the attached properties.

Canvas.Top – Define the distance for a control from the top edge of its container;
Canvas.Left – Define the distance for a control from the left edge of its container;
Canvas.ZIndex – Z Index of the control;
Grid.Row – Define the row index for a control placed in a Grid container;
Grid.Column – Define the row index for a control placed in a Grid container;
ScrollViewer.HorizontalScrollBarVisibility – Define the visibility of the horizontal scrollbar;
ScrollViewer.VerticalScrollBarVisibility – Define the visibility of the vertical scrollbar;
ToolTipService.ToolTip – Define the tool tip associated with a control;
and many more….

Hi friends In the next article you will learn routed events briefly .................

Dependency Properties

Hi Friends,

In Silverlight there are some topics are very important but never used in real applications Such as

1. Dependency Property
2. Routed Events
3. Attached Property
4. Custom Control

In this article I am giving brief description of dependency property means

1. What are dependency properties?
2. Creating Dependency Properties?
3. How to use dependency properties?

What are Dependency Properties?

              In silverlight application all the UI made up of XAML. XAML provides a great way to define layout controls, user input controls, shapes, colors and data binding expressions in a declarative manner. There’s a lot that goes on behind the scenes in order to make XAML work and an important part of that magic is the use of dependency properties. If you want to bind data to a property, style it, animate it or transform it in XAML then the property involved has to be a dependency property to work properly. If you’ve ever positioned a control in a Canvas using Canvas.Left or placed a control in a specific Grid row using Grid.Row then you’ve used an attached property which is a specialized type of dependency property. Dependency properties play a key role in XAML and the overall Silverlight framework.

Any property that you bind, style, template, animate or transform must be a dependency property in Silverlight applications. You can programmatically bind values to controls and work with standard CLR properties, but if you want to use the built-in binding expressions available in XAML (one of my favorite features) or the Binding class available through code then dependency properties are a necessity. Dependency properties aren’t needed in every situation, but if you want to customize your application very much you’ll eventually end up needing them. For example, if you create a custom user control and want to expose a property that consumers can use to change the background color, you have to define it as a dependency property if you want bindings, styles and other features to be available for use. Now that the overall purpose of dependency properties has been discussed let’s take a look at how you can create them.

Creating Dependency Properties

        When .NET first came out you had to write backing fields for each property that you defined as shown next:

Brush _ScheduleBackground;

public Brush ScheduleBackground

{

    get { return _ScheduleBackground; }

    set { _ScheduleBackground = value; }

}

Although .NET 2.0 added auto-implemented properties (for example: public Brush ScheduleBackground { get; set; }) where the compiler would automatically generate the backing field used by get and set blocks, the concept is still the same as shown in the above code; a property acts as a wrapper around a field. Silverlight dependency properties replace the _ScheduleBackground field shown in the previous code and act as the backing store for a standard CLR property.

The following code shows an example of defining a dependency property named ScheduleBackgroundProperty:

public static readonly DependencyProperty ScheduleBackgroundProperty =

  DependencyProperty.Register("ScheduleBackground", typeof(Brush),

  typeof(Scheduler), null);

Looking through the code the first thing that may stand out is that the definition for ScheduleBackgroundProperty is marked as static and readonly and that the property appears to be of type DependencyProperty. This is a standard pattern that you’ll use when working with dependency properties. You’ll also notice that the property explicitly adds the word “Property” to the name which is another standard you’ll see followed. In addition to defining the property, the code also makes a call to the static DependencyProperty.Register method and passes the name of the property to register (ScheduleBackground in this case) as a string. The type of the property, the type of the class that owns the property and a null value (more on the null value later) are also passed. In this example a class named Scheduler acts as the owner.

The code handles registering the property as a dependency property with the call to Register(), but there’s a little more work that has to be done to allow a value to be assigned to and retrieved from the dependency property. The following code shows the complete code that you’ll typically use when creating a dependency property. You can find code snippets that greatly simplify the process of creating dependency properties out on the web. The MVVM Light download available from http://mvvmlight.codeplex.com comes with built-in dependency properties snippets as well.

public static readonly DependencyProperty ScheduleBackgroundProperty =

  DependencyProperty.Register("ScheduleBackground", typeof(Brush),

  typeof(Scheduler), null);

public Brush ScheduleBackground

{

    get { return (Brush)GetValue(ScheduleBackgroundProperty); }

    set { SetValue(ScheduleBackgroundProperty, value); }

}

The standard CLR property code shown above should look familiar since it simply wraps the dependency property. However, you’ll notice that the get and set blocks call GetValue and SetValue methods respectively to perform the appropriate operation on the dependency property. GetValue and SetValue are members of the DependencyObject class which is another key component of the Silverlight framework. Silverlight controls and classes (TextBox, UserControl, CompositeTransform, DataGrid, etc.) ultimately derive from DependencyObject in their inheritance hierarchy so that they can support dependency properties.

Dependency properties defined in Silverlight controls and other classes tend to follow the pattern of registering the property by calling Register() and then wrapping the dependency property in a standard CLR property (as shown above). They have a standard property that wraps a registered dependency property and allows a value to be assigned and retrieved. If you need to expose a new property on a custom control that supports data binding expressions in XAML then you’ll follow this same pattern. Dependency properties are extremely useful once you understand why they’re needed and how they’re defined.

How to use Dependency Proprties

           When working with dependency properties there will be times when you want to assign a default value or detect when a property changes so that you can keep the user interface in-sync with the property value. Silverlight’s DependencyProperty.Register() method provides a fourth parameter that accepts a PropertyMetadata object instance. PropertyMetadata can be used to hook a callback method to a dependency property. The callback method is called when the property value changes. PropertyMetadata can also be used to assign a default value to the dependency property. By assigning a value of null for the final parameter passed to Register() you’re telling the property that you don’t care about any changes and don’t have a default value to apply.

Here are the different constructor overloads available on the PropertyMetadata class:

PropertyMetadata Constructor Overload	Description
PropertyMetadata(Object)	Used to assign a default value to a dependency property.
PropertyMetadata(PropertyChangedCallback)	Used to assign a property changed callback method.
PropertyMetadata(Object, PropertyChangedCalback)	Used to assign a default property value and a property changed callback.

There are many situations where you need to know when a dependency property changes or where you want to apply a default. Performing either task is easily accomplished by creating a new instance of the PropertyMetadata class and passing the appropriate values to its constructor. The following code shows an enhanced version of the initial dependency property code shown earlier that demonstrates these concepts:

public Brush ScheduleBackground

{

    get { return (Brush)GetValue(ScheduleBackgroundProperty); }

    set { SetValue(ScheduleBackgroundProperty, value); }

}

public static readonly DependencyProperty ScheduleBackgroundProperty =

DependencyProperty.Register("ScheduleBackground", typeof(Brush),

  typeof(Scheduler), new PropertyMetadata(new SolidColorBrush(Colors.LightGray),

  ScheduleBackgroundChanged));

private static void ScheduleBackgroundChanged(DependencyObject d,

  DependencyPropertyChangedEventArgs e)

{

    var scheduler = d as Scheduler;

    scheduler.Background = e.NewValue as Brush;

}

The code wires ScheduleBackgroundProperty to a property change callback method named ScheduleBackgroundChanged. What’s interesting is that this callback method is static (as is the dependency property) so it gets passed the instance of the object that owns the property that has changed (otherwise we wouldn’t be able to get to the object instance). In this example the dependency object is cast to a Scheduler object and its Background property is assigned to the new value of the dependency property. The code also handles assigning a default value of LightGray to the dependency property by creating a new instance of a SolidColorBrush.

What you learn in this post

In this post you’ve seen the role of dependency properties and how they can be defined in code. They play a big role in XAML and the overall Silverlight framework. You can think of dependency properties as being replacements for fields that you’d normally use with standard CLR properties. In addition to a discussion on how dependency properties are created, you also saw how to use the PropertyMetadata class to define default dependency property values and hook a dependency property to a callback method.

The most important thing to understand with dependency properties (especially if you’re new to Silverlight) is that they’re needed if you want a property to support data binding, animations, transformations and styles properly. Any time you create a property on a custom control or user control that has these types of requirements you’ll want to pick a dependency property over of a standard CLR property with a backing field.

In the next article you will learn Attached properties...

Silverlight Application Life Cycle

In the previous article I attempted to explain What Silverlight is and how it is being used more and more to develop business applications. In this article I will try to explain Silverlight Application Life Cycle. Building apps with Silverlight is more or less similar way of building Desktop apps, for example WinForms or WPF apps.
When you embed the Silverlight plug-in in a Web page, you specify the location of the application package that the plug-in should download. The whole process is as follows:

1. A User requests a Web page that hosts the Silverlight plug-in.
2. If the correct version of Silverlight has been installed, the Web browser loads the Silverlight plug-in and creates the Silverlight content region. The plug-in then begins downloading your .xap file.
3. The plug-in extract the contents of the .xap file and read the AppManifest.xaml file from the XAP to determine the assemblies your application uses.
4. The plug-in loads the Silverlight core services and the Silverlight runtime environment (CLR) which then creates an Application Domain for your application.
5. When the package is downloaded, the plug-in then loads your application assemblies and dependencies (if any) into the AppDomain. The CLR uses the metadata in .xap to instantiate your Application class and the default constructor of the Application class raises its Startup event.
6. The Startup event handler is handled to display a user interface page and that is how you view your UI. This event occurs once the Silverlight plug-in has finished loading the .xap file. Once the UI is loaded, other events occur in response to user actions.

ASP.NET and Silverlight

There are many differences between ASP.net and Silverlight.
ASP.net generates the control (client side scripts to build UI) and send to client for rendering. It requires two processes, dynamic generation of code at server, rendering of server generated code at client inside the browser. Even the code is generated at server by ASP.net worker process, it gets executed as script on the client as it gets downloaded in form of script (html, CSS, js etc).
On other hand, Silverlight contains pre-compiled intermediate language code (MSIL) for controls and only create instance to display that. A single process of instantiation of control is sufficient to render the information in browser. All Silverlight codes are pre-compiled so loading is faster than ASP.net. It requires less data transfer between server and client. There are no "server round trip", no javascript, no Ajax.
Silverlight is just like a Flash app... A server file is request by the plug-in on client computer, your server sends this file (.xap for Silverlight) and the plug-in runs it locally.
ASP.NET is stateless and everything is executed and handled on the server-side, Silverlight is not stateless and everything that is executed is executed by default on the client-side, only when you make call to the server, code on the server-side will be executed. So no refresh, no reloading of pages, no page life cycle, ViewState, just a beautiful rich client that holds state;

Page Life Cycle

Remember that Silverlight is running on the client, not on the server as normal ASP.NET pages... there is no such as Page Life Cycle in Silverlight. But there are some events that will be executed on the client side in a specific order.

1. First the App constructor in the App.xaml file.
2. The App's Applicaiton_Startup event which will be executed every time you open your Silverlight app.
3. The Main page's Constructor..  It will be the constructor of the page assigned to the RootVisual properly within the App's Application_Startup event.
4. InitializeCompnent, only to make sure the components are singed to variables so you can use them. I hope this one will be removed in the future and be handled elsewhere.
5. If you have hooked up to the Loaded event within the Main Page Constructor, that event will then be executed, same with the rest event listen in the order they will be executed if you have hooked up to them.
6. Then the SizeChanged event.
7. Then the LayoutUpdated event.
8. Then GotFocus if you mark the Silverlight app.
9. If you navigate from your Silverlight app or close the Browser the App's Application_Exit event will be executed.

As you may figure out, There is No Life Cycle. If you have a button control on the Silverlight app and press it, there will never we a post back, back to the server. The click event will just simply be fired of on the client-side; it's where the code is executed. To get data from a server, you can for use a WCF service, Web Service, Web Client, .NET RIA Services etc... They will make the call to the server from the client side for you.

Control Initialization Order

There are some subtle differences between instantiating a control in XAML, and instantiating it via code that I've called out, but most of the lifecycle is the same. 

A Short History of Silverlight


The development of Silverlight has been consistently incremental. Silverlight 4 is a superset
of Silverlight 3, which is a superset of Silverlight 2. Some of the code might not be
completely compatible between versions, mostly because when some things were missing
developers had to use workarounds. After a feature has been added in a later version,
however, the workarounds might not work properly anymore, and it is time to upgrade
the code to the proper implementation.
In some rare cases, the interface to some functionality might have changed because the
team came up with a better implementation. These occurrences are rare, however, and
upgrading an application to a newer version of Silverlight should be easy enough.




Silverlight 1.0
This early release of Silverlight (May2007) was far from complete, and in fact did not support any .NET code; it had to be programmed in JavaScript. It did, however, support a small subset of
XAML (eXtensible Application Markup Language), the language used to define
the user interface of Silverlight applications.


Silverlight 2
For a very short time, this version was named Silverlight 1.1, but considering the major
changes implemented (and also to simplify the versioning process), it made sense to
change the version number to a full digit instead.
Silverlight 2 (released shortly before the Professional Developer Conference in October
2008) was revolutionary because it brought for the very first time the .NET framework (as
a subset) to other platforms than Windows. It also included a rich set of controls,
enhanced video, new tool support, and many other exciting features



Silverlight 3
This version (again a full-digit increment) was released in July 2009, a mere nine months
after Silverlight 2. In this short time, the team managed to bring Silverlight to a more
mature version.



And Silverlight 4…
And here we are! Silverlight 4 will not be the final version of this technology, but one
thing is sure: If you were still hesitating to invest in Silverlight, now is a great time to
start. We know a lot about what Silverlight is, what it can do and cannot do, and we have
a quite clear vision of what will happen in the near future. We also have Silverlight
experts with (in some cases) two or three years of experience with this technology.
Silverlight 4 is a very stable release. What we predicted when Silverlight 2 was published is
proven true today: Silverlight is here to stay, and Microsoft is betting a lot on this technology.
In these three years, it went from “Flash contender” to major user interface technology.
According to recent numbers, the Silverlight installation basis grew very fast since
Silverlight 2 was released, and you can count on approximately 60% of all the connected
computers having Silverlight 3 or Silverlight 4 already installed

Hi Friends ,,,


Wait for Few Days ... I am coming with new SilverLight  4.0 tutorial from beginner to Advance ..




Regards 


Sujeet Bhujbal
Senior Software Engineer 

Difference between web services and WCF

These days all the projects that are upgrading from .net 2.0 to .net 3.5 or to .net 4.0 are facing the issue of choosing between web-services and WCF (Windows Communication Foundation). In this post I am going to discuss the difference between them and look at points which would make clear what to choose and throw light to web-service vs WCF issue. .

WCF Definition

WCF is a part of the .NET Framework that provides a unified programming model for rapidly building service-oriented applications that communicate across the web and the enterprise.

The following figure shows the features that the WCF provides compared to other technology in .net:

ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP. The structure of the messages can be defined using an XML Schema, and a tool is provided to facilitate serializing the messages to and from .NET Framework objects. The technology can automatically generate metadata to describe Web services in the Web Services Description Language (WSDL), and a second tool is provided for generating clients for Web services from the WSDL.

WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol. The structure of the messages can be defined using an XML Schema, and there are various options for serializing the messages to and from .NET Framework objects. WCF can automatically generate metadata to describe applications built using the technology in WSDL, and it also provides a tool for generating clients for those applications from the WSDL.

There are different points to consider for WCF:

1.    WCF is architecturally more robust and promotes best practices.

2.    If you know what you are doing its "silky smooth" if not you are in for a ride.

3.    Do you have enough time to complete the conversion of your services?

Two further aspects:
1) No matter how you decide this for the server-side, you can easily consume Webservices and WCF Services using only WCF on the client-side. This is of value, if you consume multiple services with a single client.
2) If you consider Cloud Computing: It is possible to host WCF Services on Windows Azure.

Finally I would say that, if you have the time, the bling and the muscle to do the upgrade. Its worth it. If asmx is satisfying all the needs, you may persist with web services.

ASMX is great and simple - but it's very limited in many ways:

·         you can only host your web services in IIS

·         you can only reach your web services over HTTP

·         security is very limited

WCF remedies this - and offer much more beyond that. You can host your WCF services in IIS - or self-host in a console app or Win NT Service, as need be. You can connect your WCF services using HTTP, TCP/IP, MSMQ, Peer-to-peer protocols, named pipes for on-machine communications and much more.

I'd definitely recommend you go with WCF. It's a tad more complex than ASMX, but it also offer just sooo much more capabilities and choices!

Major difference between the two is that Web Services use XmlSerializer but WCF uses DataContractSerializer which is better in performance as compared to XmlSerializer. Some key issues with XmlSerializer to serialize .NET types to XML are:

* Only Public fields or Properties of .NET types can be translated into XML.
* Only the classes which implement IEnumerable interface.
* Classes that implement the IDictionary interface, such as Hash table can not be serialized.

Important difference between DataContractSerializer and XMLSerializer:

* A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer.

* XML Serialization does not indicate the which fields or properties of the type are serialized into XML where as DataCotratSerializer Explicitly shows the which fields or properties are serialized into XML.

* The DataContractSerializer can translate the HashTable into XML.
Quick benefits of WCF over Web-Services (ASMX):

1) For internal (behind firewall) service-to-service calls we use the net:tcp binding, which is much faster than SOAP

2) We enabled both a net:tcp endpoint and a "web" endpoint on the same service with only a configuration file update (no code changes)

3) We were able to create AJAX-supporting RESTful web services with only configuration changes and using the DataContractJsonSerializer that's already built in. To do this otherwise, we would have had to write an HTTP Handler (ashx) and handle most of the Json serialization and url parsing by hand.

4) As our site needs to scale for performance optimization and stability, we are looking at converting to using an MSMQ-based messaging structure that is asynchronous AND guaranteed and participates in transactions; WCF provides an MSMQ bindng that requires little-to-no code change in our services--just reference updates and setting up MSMQ properly with the existing services (and adding attributes for Transactional boundaries).

BUT BE WARNED: Really invest in learning this. There are things like argument-name-changes during development that actually don't break the service references but result in null arguments being passed (built-in version skew handling), hosting models to consider (Windows Service vs. IIS), and instantiation models and FaultExceptions to all REALLY understand. We didn't going in and we had some pains. But we plowed ahead and are VERY happy with our learnings and the flexibility and growth opportunities we have not being tied to ASMX anymore!

wcf for beginners

The WCF Service

The WCF Interface you expose can not be particularly complex if you want to use the Service Moniker – I’ve found it best to keep top primitive types, and arrays of primitive types.  Data Contracts seem to be a no-go.
Start by creating a new WCF Service using File|New|Project and selecting WCF Service Library:

Double-click on IService1.cs in the Solution Explorer, and replace the default contents with this simple interface:

using System;
using System.ServiceModel;

namespace WcfService1
{
    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        string GetData(int value);

        [OperationContract]
        object[] GetSomeObjects();
    }
}

Next replace the contents of the service implementation, Service1.cs, with the following:

using System;

namespace WcfService1
{
    public class Service1 : IService1
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }

        public object[] GetSomeObjects()
        {
            return new object[] { "String", 123, 44.55, DateTime.Now };
        }
    }
}

Configuring the WCF Service

By default the WCF Service is configured to use HTTP as the transport protocol.  I generally switch it to use TCP, because I am operating within a corporate intranet, and HTTP seems like overkill.
You’ll also find that by default your WCF Service exposes two endpoints.  The first exposes as you’d expect, the IService1 interface you defined above.  The second exposes Metadata about your service, which the Service Moniker uses to know what operations are available on your service.  You’ll need both.
Right-click on the App.config file in the Solution Explorer, and select Edit WCF Configuration:

Switch the first endpoint to use TCP:

Also change the second to use mexTcpBinding:

Change the base address that the service will use, to use a TCP address instead of a HTTP Address by selecting the Host node on the left hand tree, and then selecting the base address and clicking on Edit, and changing the text to be net.tcp://localhost:7891/Test/WcfService1/Service1/

Finally, because you are using TCP instead of HTTP, change the MetataData service to not expect to expose the metadata via HTTP, by changing HttpGetEnabled to False under Advanced|Service Behaviours…

Save the changes and exit the WCF Editor.  Your App.config should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
    <compilation debug="true" />
  </system.web>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="WcfService1.Service1Behavior"
        name="WcfService1.Service1">
        <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
          contract="WcfService1.IService1">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""
          contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:7891/Test/WcfService1/Service1/" />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="WcfService1.Service1Behavior">
          <serviceMetadata httpGetEnabled="False"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

To start running your service you can hit Ctrl-F5 in Visual Studio.  This will start a test service host, and a test client.  We will ignore the client, but you can check that the service host has started by clicking on the message in the notification area:


Eventually you’ll want to host your service somewhere else, such as a Windows Service.