WPF vs. Silverlight in .net
Both WPF and Silverlight use XAML (Extensible Application Markup Language) under the covers.
Let's look at some of the different characteristics of each technology:
WPF:
* Ships as part of the .NET Framework (version 3.0 and onward)
* Runs as Windows application or as web "browser application" (called XBAP, for "XAML Browser Application"). Note that XBAPs run only in Internet Explorer with .NET 3.0 and in both Internet Explorer and Firefox with .NET 3.5.
* Runs on Windows machines only (Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008)
* Richest functionality, including 3D graphics
Silverlight:
* Ships independently
* Runs in web browsers only (Internet Explorer, Firefox, Safari)
* Runs on Windows or Mac operating systems (also on Linux via Moonlight,which is an open source implementation of Silverlight based on Mono)
* Functionality is a subset of WPF's feature set
WPF is a more mature technology and was designed with a richer feature set. It also has the advantage of being able to run in a browser or as an installed Windows-Form-type app.
Silverlight has a broader reach.You can access Silverlight from many operating systems and web browsers.
The most important reason to choose one over the other should be based on the intended audience for the application. For example, if a corporation is designing an application for internal use only and every employee has Windows XP as the company standard OS, then go with WPF to leverage the richer feature set. If a corporation is designing an external-facing website, then Silverlight is the better choice because potential customers can access the website from a variety of different operating systems and browsers.
26 January 2011
Base Class of all classes in the .NET Framework
Base Class of all classes in the .NET Framework
Object Class is Base Class of all classes in the .NET Framework
Object Class is Base Class of all classes in the .NET Framework
Root Namespace of Dotnet
Root Namespace of Dotnet
The System namespace is the root namespace for fundamental types in the .NET Framework. This namespace includes classes that represent the base data types used by all applications
The System namespace is the root namespace for fundamental types in the .NET Framework. This namespace includes classes that represent the base data types used by all applications
What is WebService in asp.net?
What is Web Service in ASP.net?
A web service is a special kind of web site. It is different from a traditional ASP.NET web site that produces HTML code. In fact, a web service had no graphical user interface and produces XML. A web service exposes one or more methods that your application can call remotely. This is called a remote procedure call. It basically means that you can have web service A sitting on a web server and another ASP.NET web application B sitting on a different server, and application B can call or communicate with web service A, even though they are in separate physical machines.
It turns out that this feature of web services makes them very useful for many reasons: scalability, encapsulation of logic, and security.
Web services are implemented internally using an Internet protocol called SOAP, which passes XML messages back and forth between a web service client application and a web service. The SOAP protocol is an Internet standard which makes web services interoperable or cross-platform (e.g. Java can communicate with .NET and .NET can communicate with Java); the two can integrate with each other seamlessly by using web services. You don’t have to understand how SOAP works in order to program an ASP.NET web service, and a lot of programmers probably don’t. That is one of the strengths of the .NET framework and the Visual Studio IDE.
A web service is a special kind of web site. It is different from a traditional ASP.NET web site that produces HTML code. In fact, a web service had no graphical user interface and produces XML. A web service exposes one or more methods that your application can call remotely. This is called a remote procedure call. It basically means that you can have web service A sitting on a web server and another ASP.NET web application B sitting on a different server, and application B can call or communicate with web service A, even though they are in separate physical machines.
It turns out that this feature of web services makes them very useful for many reasons: scalability, encapsulation of logic, and security.
Web services are implemented internally using an Internet protocol called SOAP, which passes XML messages back and forth between a web service client application and a web service. The SOAP protocol is an Internet standard which makes web services interoperable or cross-platform (e.g. Java can communicate with .NET and .NET can communicate with Java); the two can integrate with each other seamlessly by using web services. You don’t have to understand how SOAP works in order to program an ASP.NET web service, and a lot of programmers probably don’t. That is one of the strengths of the .NET framework and the Visual Studio IDE.
10 January 2011
Difference Between Oracle and Sql Server 2008
Difference Between Oracle and Sql Server 2008
1.The FIRST biggest difference: Transaction control.
In Oracle EVERYTHING is a transaction and it is not permanent
until you COMMIT.In SQL Server, there is (by default) no transaction control.
2.SQL Server supports only windows based platforms.
Oracle:Its a platform independent
3.Oracle includes IFS (Internet File System), Java integration,
SQL is more of a pure database
1.The FIRST biggest difference: Transaction control.
In Oracle EVERYTHING is a transaction and it is not permanent
until you COMMIT.In SQL Server, there is (by default) no transaction control.
2.SQL Server supports only windows based platforms.
Oracle:Its a platform independent
3.Oracle includes IFS (Internet File System), Java integration,
SQL is more of a pure database
21 December 2010
Difference between const and static readonly keywords C#
Difference between const and static readonly keywords C#
If in your C# class you want to use a variable whose value will not change during the lifetime of that class, then you have
two options:
1. Use the "const" keyword: for e.g. public const int myVar = 100;
2. Use the "static readonly" keyword: for e.g. public static readonly int myVar = ConfigurationManager.AppSettings["value"];
The const variable has a limitation: it can ONLY be set during compile time. This means you cannot set its value using any code
logic, like getting its value from some config file, or from some "if" condition. Whereas the value of a static readonly field
can be set at run time, and can thus be modified by the containing class using any custom logic.
In the static readonly case, the containing class is allowed to modify it only
* in the variable declaration (through a variable initializer)
* in the static constructor (instance constructors, if it's not static)
If in your C# class you want to use a variable whose value will not change during the lifetime of that class, then you have
two options:
1. Use the "const" keyword: for e.g. public const int myVar = 100;
2. Use the "static readonly" keyword: for e.g. public static readonly int myVar = ConfigurationManager.AppSettings["value"];
The const variable has a limitation: it can ONLY be set during compile time. This means you cannot set its value using any code
logic, like getting its value from some config file, or from some "if" condition. Whereas the value of a static readonly field
can be set at run time, and can thus be modified by the containing class using any custom logic.
In the static readonly case, the containing class is allowed to modify it only
* in the variable declaration (through a variable initializer)
* in the static constructor (instance constructors, if it's not static)
What are the basic differences between user controls and custom controls?
What are the basic differences between user controls and custom controls?
User control
Deployment
Designed for single-application scenarios ,Deployed in the source form (.ascx) along with the source code of the application
If the same control needs to be used in more than one application, it introduces redundancy and maintenance problems
Custom control
Designed so that it can be used by more than one application Deployed either in the application's Bin directory or in the global assembly cache
Distributed easily and without problems associated with redundancy and maintenance.
Creation
User control
Creation is similar to the way Web Forms pages are created; well-suited for rapid application development (RAD)
Custom control
Writing involves lots of code because there is no designer support.
Content
User control
A much better choice when you need static content within a fixed layout, for example, when you make headers and footers
Custom Control
More suited for when an application requires dynamic content to be displayed; can be reused across an application,
for example, for a data bound table control with dynamic rows
Design
User Control
Writing doesn't require much application designing because they are authored at design time and mostly contain static data
Custom control
Writing from scratch requires a good understanding of the control's life cycle and the order in which events execute,
which is normally taken care of in user controls
How a user control is processed
When a page with a user control is requested, the following occurs:
The page parser parses the .ascx file specified in the Src attribute in the @ Register directive and generates a class that derives from the System.Web.UI.UserControl class.
The parser then dynamically compiles the class into an assembly.
If you are using Visual Studio, then at design time only, Visual Studio creates a code behind file for the user control, and the file is precompiled by the designer itself.
Finally, the class for the user control, which is generated through the process of dynamic code generation and compilation, includes the code for the code behind file (.ascx.cs) as well as the code written inside the .ascx file.
How to choose the base class for your custom control
To write a custom control, you should directly or indirectly derive the new class from the System.Web.UI.Control class or from the System.Web.UI.WebControls.WebControl class:
You should derive from System.Web.UI.Control if you want the control to render nonvisual elements. For example, and are examples of nonvisual rendering.
You should derive from System.Web.UI.WebControls.WebControl if you want the control to render HTML that generates a visual interface on the client computer.
User control
Deployment
Designed for single-application scenarios ,Deployed in the source form (.ascx) along with the source code of the application
If the same control needs to be used in more than one application, it introduces redundancy and maintenance problems
Custom control
Designed so that it can be used by more than one application Deployed either in the application's Bin directory or in the global assembly cache
Distributed easily and without problems associated with redundancy and maintenance.
Creation
User control
Creation is similar to the way Web Forms pages are created; well-suited for rapid application development (RAD)
Custom control
Writing involves lots of code because there is no designer support.
Content
User control
A much better choice when you need static content within a fixed layout, for example, when you make headers and footers
Custom Control
More suited for when an application requires dynamic content to be displayed; can be reused across an application,
for example, for a data bound table control with dynamic rows
Design
User Control
Writing doesn't require much application designing because they are authored at design time and mostly contain static data
Custom control
Writing from scratch requires a good understanding of the control's life cycle and the order in which events execute,
which is normally taken care of in user controls
How a user control is processed
When a page with a user control is requested, the following occurs:
The page parser parses the .ascx file specified in the Src attribute in the @ Register directive and generates a class that derives from the System.Web.UI.UserControl class.
The parser then dynamically compiles the class into an assembly.
If you are using Visual Studio, then at design time only, Visual Studio creates a code behind file for the user control, and the file is precompiled by the designer itself.
Finally, the class for the user control, which is generated through the process of dynamic code generation and compilation, includes the code for the code behind file (.ascx.cs) as well as the code written inside the .ascx file.
How to choose the base class for your custom control
To write a custom control, you should directly or indirectly derive the new class from the System.Web.UI.Control class or from the System.Web.UI.WebControls.WebControl class:
You should derive from System.Web.UI.Control if you want the control to render nonvisual elements. For example, and are examples of nonvisual rendering.
You should derive from System.Web.UI.WebControls.WebControl if you want the control to render HTML that generates a visual interface on the client computer.
Subscribe to:
Posts (Atom)