Monday, 15 August 2011


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


Thursday, 4 August 2011





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 

Wednesday, 20 July 2011

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!

Tuesday, 12 July 2011

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:
image
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:
image
Switch the first endpoint to use TCP:
image
Also change the second to use mexTcpBinding:
image
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/
image
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…
image
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:
image
image
Eventually you’ll want to host your service somewhere else, such as a Windows Service.

Sunday, 26 June 2011

WCF Hosting with Different ways


       The host can be provided by Internet Information Services (IIS), by the Windows Activation Service (WAS) on Windows Vista or Windows Server 2008, Windows 7 or later, on the Windows Server AppFabric, or by the developer as part of the application.
       In-process (or in-proc) hosting, where the service resides in the same process as the client, is a special case. By definition, the developer provides the host for the in-proc case.

IIS 5/6 Hosting

       The main advantage of hosting a service on the Microsoft IIS web server is that the host process is launched automatically upon the first client request, and IIS 5/6 manages the lifecycle of the host process.
       The main disadvantage of IIS 5/6 hosting is that you can only use HTTP.
       With IIS 5, you are further restricted to having all services use the same port number.
       Hosting in IIS is very similar to hosting a classic ASMX web service.
       You need to create a virtual directory under IIS and supply an .svc file.
       The .svc file functions similarly to an .asmx file and is used to identify the service code behind the file and class.

Using Visual Studio 2010

       You can use Visual Studio 2010 to generate a boilerplate IIS-hosted service.
       From the File menu, select New Web Site, then select WCF Service from the New Web Site dialog box. Visual Studio 2010 creates a new website, a service code, and a matching .svc file.
       You can also use the Add New Item dialog box to add another service later.

Self-Hosting

       Self-hosting is the technique in which the developer is responsible for providing and managing the lifecycle of the host process.
       Use self-hosting when you want a process (or machine) boundary between the client and the service and when you are using the service in-proc—that is, in the same process as the client.
       You can provide any Windows process, such as a Windows Forms application, a WPF application, a Console application, or a Windows NT Service.
       You can provide a host with only a few lines of code.
       A self-hosted service can use any WCF transport protocol, and you can take advantage of all the WCF features, including the service bus, discovery, and utilize a singleton service.
       Hosting application config file (app.config) typically lists the types of the services you wish to host and expose to the world.
       You need to provide the constructor of ServiceHost with the service type and optionally with default base addresses.
       The set of base addresses can be an empty set, and even if you provide base addresses, you can configure the service to use different base addresses.
       Having a set of base addresses enables the service to accept calls on multiple addresses and protocols and to use only a relative URI.


WAS Hosting

       The problem with hosting in IIS 5/6 is that it is a web server, not a hosting engine.
       It therefore requires you to masquerade your service as a website
       While ASP.NET encapsulates this step for you, it causes a significant increase in internal complexity, involving the HTTP modules and the ASP.NET pipeline.
       The problem is that the more moving parts involved, the higher the likelihood of something going wrong.
       As a result, hosting in IIS 5/6 is notorious for instability and the frequent need to reset the server or IIS 5/6. Moreover, limiting the service to using only HTTP makes IIS 5/6 ill-suited for intranet applications.







Sunday, 19 June 2011

What Is WCF?


WCF is a software development kit for developing and deploying services on Windows.
WCF provides a runtime environment for your services, enabling you to expose Common Language Runtime (CLR) types as services and to consume other services as CLR types.
WCF is Microsoft’s implementation of a set of industry standards defining service interactions, type conversions, marshaling, and the management of various protocols.
Consequently, WCF provides interoperability between services
WCF provides developers with the essential off-the-shelf plumbing required by almost all applications and, as such, it greatly increases productivity.
The first release of WCF 3.0 provided many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security.
The second release of WCF 3.5 provided additional tools and extended the original offering with additional communication options.
The third release 4.0 includes configuration changes, a few extensions, and the new features of discovery and routers. While not directly related, WCF is also extended to support the Windows Azure Platform AppFabric Service Bus.
WCF has an elegant extensibility model you can use to enrich the basic offering. 
In fact, WCF itself is written using this extensibility model. 
WCF is part of .NET 4.0, so it can run only on operating systems that support it.
Presently, this list consists of Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7 or later.
Most of the WCF functionality is included in a single assembly called System.Service-Model.dll, located in the System.ServiceModel namespace.
Visual Studio 2010 allows you to add a WCF service to any application project by selecting WCF Service from the Add New Item dialog box. 
A service added this way is, of course, in-proc toward the host process, but out-of-proc clients can also access it.

Monday, 13 June 2011

WCF Exam 70-503 TS: Microsoft .NET Framework 3.5 - Windows Communication Foundation Application Development: Preparation

If you want to prepare for the above exam for WCF; you might want to observe the following:
The exams is (as one might expect) quite heavy on security related questions; so you might want to investigate CardSpace and SAML-tokens beforehand.

The exam is 43 questions and running for 140 minutes. To my great surprise, no questions related to netTcpBinding; which is a binding that I use almost exclusively in production systems, but all bindings in the exam revolved around the more “traditional” webservice bindings like basicHttpBinding and wsHttpBinding. A question on Federation was also present. In addition – you should investigate how impersonation/delegation is working out of the box with WCF.

But – basically do know your “ABC” of WCF (Address-Binding-Contract) and get to know the XML-schema for configuring a WCF service. There are a lot of configuration questions  with “select the appropriate configuration for a service that supports these requirements…”.

I have so many dumps for 70503 Exam.. But first study from Microsoft Study material then give the exam

If you want a study material mail me sujeet.bhujbal@gmail.com