HTML syntax is the format suggested for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with an HTML MIME type, such as text/html, then it will be processed as an HTML document by Web browsers. This specification defines version 5 of the HTML syntax, known as “HTML5″.

XHTML syntax is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5 of the XHTML syntax, known as “XHTML5″.

The DOM, the HTML syntax, and XML cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in XML. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in XML. Comments that contain the string “–>” can only be represented in the DOM, not in the HTML and XML syntaxes.

The term MIME type is used to refer to what is sometimes called an Internet media type in protocol literature. The term media type in this specification is used to refer to the type of media intended for presentation, as used by the CSS specifications.

In WPF A resource can be referenced as either a static resource or a dynamic resource. This is done by using either the StaticResource Markup Extension or the DynamicResource Markup Extension. A markup extension is a feature of XAML whereby you can specify an object reference by having the markup extension process the attribute string and return the object to a XAML loader. For more information about markup extension behavior, see Markup Extensions and WPF XAML.

When you use a markup extension, you typically provide one or more parameters in string form that are processed by that particular markup extension, rather than being evaluated in the context of the property being set. The StaticResource Markup Extension processes a key by looking up the value for that key in all available resource dictionaries. This happens during loading, which is the point in time when the loading process needs to assign the property value that takes the static resource reference. The DynamicResource Markup Extension instead processes a key by creating an expression, and that expression remains unevaluated until the application is actually run, at which time the expression is evaluated and provides a value.

When you reference a resource, the following considerations can influence whether you use a static resource reference or a dynamic resource reference:

• The overall design of how you create the resources for your application (per page, in the application, in loose XAML, in a resource only assembly).
• The application functionality: is updating resources in real time part of your application requirements?
• The respective lookup behavior of that resource reference type.
• The particular property or resource type, and the native behavior of those types.

A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored.

A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.

So, Static resources are resolved at compile time, whereas dynamic resources are resolved at runtime. Use DynamicResources when the value of the resource could change during the lifetime of the Application. Use StaticResources when it’s clear that you don’t need your resource re-evaluated when fetching it – static resources perform better than dynamic resources.

Key characteristics of VIEW
? The view is a visual element, such as a window, page, user control, or data template. The view defines the controls contained in the view and their visual layout and styling.
? The view references the view model through its DataContext property. The controls in the view are data bound to the properties and commands exposed by the view model.
? The view may customize the data binding behavior between the view and the view model. For example, the view may use value converters to format the data to be displayed in the UI, or it may use validation rules to provide additional input data validation to the user.
? The view defines and handles UI visual behavior, such as animations or transitions that may be triggered from a state change in the view model or via the user’s interaction with the UI.
? The view’s code-behind may define UI logic to implement visual behavior that is difficult to express in XAML or that requires direct references to the specific UI controls defined in the view.

Key characteristics of’ ‘VIEWMODEL’
? The view model is a non-visual class and does not derive from any WPF or Silverlight base class. It encapsulates the presentation logic required to support a use case or user task in the application. The view model is testable independently of the view and the model.
? The view model typically does not directly reference the view. It implements properties and commands to which the view can data bind. It notifies the view of any state changes via change notification events via the INotifyPropertyChanged and INotifyCollectionChanged interfaces.
? The view model coordinates the view’s interaction with the model. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model. It may also implement data validation via the IDataErrorInfo or INotifyDataErrorInfo interfaces.
? The view model may define logical states that the view can represent visually to the user.

Key characteristics of ‘MODEL’
? Model classes are non-visual classes that encapsulate the application’s data and business logic. They are responsible for managing the application’s data and for ensuring its consistency and validity by encapsulating the required business rules and data validation logic.
? The model classes do not directly reference the view or view model classes and have no dependency on how they are implemented.
? The model classes typically provide property and collection change notification events through the INotifyPropertyChanged and INotifyCollectionChanged interfaces. This allows them to be easily data bound in the view. Model classes that represent collections of objects typically derive from the ObservableCollection<T> class.
? The model classes typically provide data validation and error reporting through either the IDataErrorInfo or INotifyDataErrorInfo interfaces.
? The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.

WPF is a set of .NET Framework classes that you can use to build attractive and functional UIs for Windows-based client applications.

WPF uses the DirectX graphics engine to provide sophisticated graphics and efficient rendering.

WPF enables you to develop applications by using both declarative markup and managed code.

Typically, you use XAML to implement the appearance of your application and you use a .NET Framework managed programming language, such as C#, to implement behavior.

This separation of appearance from behavior offers many advantages when you build graphical applications.

For example, designers can work on the appearance of an application at the same time as developers independently work on the code-behind functionality.

You can use WPF to create stand-alone applications and applications that are hosted in a Web browser.

When you create stand-alone applications, you use the Window class and you use menu bars, toolbars, and dialog boxes as the building blocks of your application.

When you create browser-hosted applications, you use the Page class as your foundation and you provide hyperlinks to enable users to navigate between the pages in your application.

In both cases, you can use the Application class to share session data, properties, and resources across your application.

WPF includes many other features that enhance the experience of the developer and the end user.

For example, the WPF layout system makes it easy for you to develop controls and layouts that adapt to differing window sizes and display settings.

This is an essential part of the modern user experience.

The WPF data-binding system makes it easy for you to implement two-way data binding between controls and data sources.

Finally, the graphics system includes support for highly sophisticated two-dimensional graphics, three-dimensional graphics, and animations that you can use to create genuinely engaging applications.

Overview of SMO

SQL Server Management Objects (SMO) are objects designed for programmatic management of Microsoft SQL Server. You can use SMO to build customized SQL Server management applications. Although SQL Server Management Studio is a powerful and extensive application for managing SQL Server, there might be times when you would be better served by an SMO application.

SMO in SQL Server 2008 is compatible with SQL Server 2000, SQL Server 2005, SQL Server 2008 and SQL Server 2008 R2. SMO in SQL Server 2005 is compatible with SQL Server 2000, SQL Server 2005. So, you can easily manage a multi-version environment with a higher version of SMO.

Install SMO

Microsoft SQL Server 2008 Management Objects Collection (a component of Feature Pack for Microsoft SQL Server 2005/2008)

The Management Objects Collection package includes several key elements of the SQL Server 2008 management API, including Analysis Management Objects (AMO), Replication Management Objects (RMO), and SQL Server Management Objects (SMO). Developers and DBAs can use these components to programmatically manage SQL Server 2008.

By default, the SMO assemblies are installed in the C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies, you can track this folder to see whether SMO installed successfully.

Call SMO in C#

These are the minimum files that are required to build an SMO application, and they are under the C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\ folder

Microsoft.SqlServer.ConnectionInfo.dll

Microsoft.SqlServer.Smo.dll

Microsoft.SqlServer.Management.Sdk.Sfc.dll

Microsoft.SqlServer.SqlEnum.dll

Here is a demo of script all jobs in sql server

   1:  Server server = new Server(ServerName);

   2:  JobServer server2 = server.JobServer;

   3:  foreach (Job job in server2.Jobs)

   4:  {

   5:      WriteToFile(job, PathToWriteScripts);

   6:  }

The restrictions on default values for optional parameters may remind you of the restrictions on const fields or attribute values, and they behave very similarly. In both cases, when the compiler references the value, it copies it directly into the output. The generated IL acts exactly as if your original source code had contained the default value. This means if you ever change the default value without recompiling everything that references it, the old callers will still be using the old default value. To make this concrete, imagine this set of steps:

1. Create a class library  with a class like this:

   public class MyDemo
   {
   	public static void PrintValue(int value = 10)
   	{
   		System.Console.WriteLine(value);
   	}
   }

2. Create a console application (Application.exe) that references the class library:

   public class Program
   {
   	static void Main()
   	{
   		MyDemo.PrintValue();
   	}
   }

3. Run the application—it’ll print 10, predictably.
4. Change the declaration of PrintValue as follows, then recompile just the class library:

   public static void PrintValue(int value = 20)

5. Rerun the application—it’ll still print 10. The value has been compiled directly into the executable.
6. Recompile the application and rerun it—this time it’ll print 20.

This versioning issue can cause bugs that are hard to track down, because all the code looks correct. Essentially, you’re restricted to using genuine constants that should never change as default values for optional parameters. There’s one benefit of this setup: it gives the caller a guarantee that the value it knew about at compile-time is the one that’ll be used. Developers may feel more comfortable with that than with a dynamically computed value, or one that depends on the version of the library used at execution time.

Of course, this also means you can’t use any values that can’t be expressed as constants anyway—you can’t create a method with a default value of “the current time,” for example.