lundi 6 octobre 2008

File Types supported for solution items

Category Item Type File Extension

General Text file

.txt

Style sheet

.css

XML schema

.xsd

Bitmap file

.bmp

Cursor file

.cur

Visual C# class

.cs

Visual Basic class

.vb

HTML page

.html

XML file

.xml

XSLT file

.xsl

Icon file

.ico

Native resource template

.rct

Test Run Configuration Test run configuration

.testrunconfig

--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

Solution Items

Solution Items

In practice, the content you will add most often to a solution is project related. But items

can be added directly to a solution as well. Collectively, the term

solution items refers to

any nonproject file that is attached to a solution. Because we know that solutions can't be

compiled, it stands to reason that files added at the solution level serve no practical

purpose from a compilation perspective. There are various reasons, however, that you may

want to add solution items to your solution. For instance, this is a convenient way to store

documentation that applies to the solution as a whole. Because you can add any type of

file to a solution, this could take the form of documents, notes to other developers, design

specifications, or even source code files from other solutions that may have some impact

or bearing on the work at hand.

By default, Visual Studio supports a few types of solution items that can be created directly

from within the IDE. They are grouped within four categories. Within each category are

various file types that can be generated by Visual Studio. Table 4.1 shows the supported

types.



--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

Synchronization Datas

Architecture and Classes for Client and Server Synchronization

Sync Services for ADO.NET 2.0 enables synchronization between a SQL Server Compact 3.5 client database and a server database or any other data source, such as a service that provides stock quotes in XML. For synchronizing two databases, Sync Services supports two-tier and N-tier architectures that use any server database for which an ADO.NET provider is available. For synchronizing between a client database and other types of data sources, Sync Services supports a service-based architecture. This architecture requires more application code than two-tier and N-tier architectures; however, it does not require a developer to take a different approach to synchronization.

The following illustrations show the components that are involved in two-tier, N-tier, and service-based architectures. Each illustration shows a single client, but there are frequently multiple clients that synchronize with a single server. Sync Services uses a hub-and-spoke model. Synchronization is always initiated by the client. All changes from each client are synchronized with the server before the changes are sent from the server to other clients. (These are clients that do not exchange changes directly with one another.)

Sync Services provides snapshot, download-only, upload-only, and bidirectional synchronization:

  • Snapshot and download-only synchronization are typically used to store and update reference data, such as a product list, on a client. Data changes that are made at the server are downloaded to the client database during synchronization. Snapshot synchronization completely refreshes data every time that the client is synchronized. This is appropriate when you do not want to track incremental changes or the server cannot do so. Download-only synchronization downloads only the incremental changes that have occurred since the previous synchronization.

  • Upload-only synchronization is typically used to insert data, such as a sales order, on a client. Inserts and other changes to data that are made in the client database are uploaded to the server during synchronization.

  • Bidirectional synchronization is typically used for data, such as customer contact information, that can be updated at the client and server. Any conflicting changes must be handled during synchronization.

For more information about the types of synchronization, see How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization. The Sync Services architecture for client and server synchronization is asymmetric: This means that change-tracking is built into the client database, but you must track changes in the server data store if you want incremental changes to be downloaded. For more information about change tracking, see Tracking Changes in the Server Database.

Components in the Architecture Illustrations

The components in the architecture illustrations include the client and server databases and a set of classes from the Sync Services API. The N-tier and service-based architectures also include Web Service and Transport components that you must write.

Two-Tier Architecture

The first illustration shows a two-tier architecture that has a client database and a server database.

Two-tier synchronization topology

Except for the two databases, all items in the illustration correspond to Sync Services classes. These classes are contained in the following DLLs:

  • Microsoft.Synchronization.Data.dll contains Synchronization Agent, Synchronization Tables, and Synchronization Groups.

  • Microsoft. Synchronization.Data.SqlServerCe.dll contains the Client Synchronization Provider.

  • Microsoft. Synchronization.Data.Server.dll contains the Server Synchronization Provider and Synchronization Adapters.

All the DLLs depend on System.dll and System.Data.dll from .NET Framework 2.0 or later versions. Microsoft.Synchronization.Data.SqlServerCe.dll also depends on System.Data.SqlServerCe.dll from SQL Server Compact 3.5. For two-tier applications, all Sync Services DLLs reside on the client. For N-tier applications, Microsoft.Synchronization.Data.dll and Microsoft.Synchronization.Data.Server.dll reside on a separate computer that provides a synchronization service.

N-Tier Architecture

The second illustration shows an N-tier architecture. This requires a proxy, a service, and a transport mechanism to communicate between the client database and the server database. This architecture is more common than a two-tier architecture, because an N-tier architecture does not require a direct connection between the client and server databases.

N-tier synchronization topology

Service-based Architecture

The third illustration shows a service-based architecture. This architecture includes a client database, but does not include a server database or the corresponding Server Synchronization Provider and Synchronization Adapters. To use this kind of architecture, an application must be able to communicate to the Synchronization Agent through a custom proxy and custom service. These must provide the same functionality that the Server Synchronization Provider and Synchronization Adapters usually provide, such as retrieving changes to synchronize.

Service-based synchronization topology

Client Database

The client database for Sync Services applications is SQL Server Compact 3.5 Service Pack 1 (SP1) and later versions. Sync Services provides an infrastructure to track incremental changes in the client database. This infrastructure is enabled the first time any table is synchronized by using a method other than snapshot synchronization. By default, the metadata that Sync Services requires in the client database is stored for 10 days. For more information about metadata retention, see RetentionInDays.

Server Database

The server database can be any database for which an ADO.NET provider is available. If you want to track incremental changes in the server database, you must prepare the database to do this. For more information, see Tracking Changes in the Server Database.

Sync Services Classes

The following classes are represented in the previous illustration: SyncAgent, SqlCeClientSyncProvider, DbServerSyncProvider, SyncTable, SyncGroup, and SyncAdapter. For an example of how to use these classes in an application, see Getting Started: Client and Server Synchronization.

Synchronization Agent

The synchronization agent drives synchronization in the following ways:

  • Loops through each of the tables to be synchronized.

  • Calls the client synchronization provider to retrieve and apply changes at the client database.

  • Calls the server synchronization provider to retrieve and apply changes at the server database.

The synchronization agent also maintains session-level information for the synchronization and provides success messages, errors, and statistics to the application on the client. For more information, see SyncAgent and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.

Client Synchronization Provider

The client synchronization provider communicates with the client and shields the synchronization agent from the specific implementation of the client database. Sync Services includes a provider for the SQL Server Compact 3.5 database. The principal activities of the client synchronization provider are as follows:

  • Stores information about tables on the client that are enabled for synchronization.

  • Retrieves changes that occurred in the client database since the last synchronization.

  • Applies incremental changes to the client database.

  • Detects conflicting changes.

For more information, see SqlCeClientSyncProvider and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.

Server Synchronization Provider

The server synchronization provider communicates with the server and shields the synchronization agent from the specific implementation of the server database. The principal activities of the server synchronization provider are as follows:

  • Stores information about tables on the server that are enabled for synchronization.

  • Enables applications to retrieve changes that occurred in the server database since the last synchronization.

  • Applies incremental changes to the server database.

  • Detects conflicting changes.

For more information, see DbServerSyncProvider and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.

Synchronization Table and Synchronization Group

A synchronization table is defined for each table that is synchronized. It stores settings, such as the direction of synchronization. Each client can request only the tables it needs. This might not include all the tables that the server synchronization provider makes available. For example, there might be 20 tables, 10 of which are configured for bidirectional synchronization in the Server Synchronization Provider. A client might request only 12 of the tables as download-only. Although the server supports upload, the client does not have to make changes or to synchronize all tables. For more information, see SyncTable.

After a synchronization table is defined, it can be added to a synchronization group. A synchronization group is a mechanism to ensure consistent application of changes for a set of tables. If tables are included in a synchronization group, changes to those tables are transferred as a unit and applied at the server in a single transaction. If any change in the group fails, changes for the whole group are retried on the next synchronization. For more information, see SyncGroup and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.

Synchronization Adapter

Modeled after the data adapter in ADO.NET, the synchronization adapter is defined for each table that is synchronized. The synchronization adapter provides the server synchronization provider with the specific commands that are required to interact with the server database, such as the InsertCommand that applies inserts from the client database to the server database. Because synchronization adapters use the ADO.NET DbCommand object, you can use any command structure that is supported by ADO.NET. This includes inline Transact-SQL, stored procedures, views, functions, and so on. The commands only require a single result that defines the structure and data to be transferred and applied. For more information, see SyncAdapter and How to: Specify Snapshot, Download, Upload, and Bidirectional Synchronization.

Proxy, Service, and Transport

Proxy, Service, and Transport are used in N-tier and service-based architectures. In N-tier applications, Microsoft.Synchronization.Data.Server.dll is used but it does not reside on the client. Typically, the DLL resides on a middle tier that has a direct connection to the server database. In this case, a proxy and service are required to communicate between the client and the middle tier:

  • On the client, application code references a proxy for the server synchronization provider (ServerSyncProviderProxy) instead of directly referencing the provider. The proxy communicates with a service on the middle tier.

  • On the middle tier, the service inherits from and exposes the same methods as ServerSyncProvider (the abstract class from which DbServerSyncProvider inherits). The server synchronization provider methods are then executed over a direct connection to the server database. The results are routed through the middle tier and back to the client.

For more information, see How to: Configure N-Tier Synchronization.

In service-based applications, Microsoft.Synchronization.Data.Server.dll is not used on the client. The application code must provide the same functionality that the server synchronization provider and synchronization adapters usually provide:

  • On the client, application code references a proxy for the application code that handles server synchronization provider tasks, such as retrieving changes from the data source. The proxy communicates with a service on the middle tier.

  • On the middle tier, the service inherits from and exposes the same methods as ServerSyncProvider (the abstract class from which DbServerSyncProvider inherits). The methods are then executed by the application code over a direct connection to the server database. The results are routed through the middle tier and back to the client.

Additional Classes in the API

The illustrations in this topic show the major classes in the API. However, there are many classes that are not shown. To obtain information about all the available classes, see Microsoft.Synchronization, Microsoft.Synchronization.Data, Microsoft.Synchronization.Data.SqlServerCe, and Microsoft.Synchronization.Data.Server. The following sections provide introductions to four other important classes that you should be familiar with.

Synchronization Anchor

A synchronization anchor is a reference point in time for a set of tables that are synchronized from the server. Synchronization anchors enable an application to determine which changes should be synchronized during a specified session. During synchronization, the client synchronization provider stores the following reference points in the client database:

Last received anchor

Identifies the last change that was downloaded from the server.

Last sent anchor

Identifies the last change that was uploaded from the client.

On the next synchronization, an application can use these anchors to identify the starting point for synchronizing the next set of changes. For more information, see SyncAnchor and Tracking Changes in the Server Database.

Synchronization Session Statistics

Session statistics are a set of statistics that the Synchronization Agent provides for each synchronization session. The statistics include information about synchronization times, the number of changes processed, and any conflicts or exceptions that occurred. For more information, see SyncStatistics and How to: Work with Events and Program Business Logic.

Synchronization Session Variables

Session variables are variables that are provided for a developer to use as parameters for the select, insert, update, and delete commands executed at the server. The variables can be used in several ways: to provide support for conflict detection and to avoid downloading changes to a client more than one time. For more information, see SyncSession and How to: Use Session Variables.

SQL Server Synchronization Adapter Builder

Modeled after the command builder in ADO.NET, the synchronization adapter builder helps you develop code for the synchronization commands that are executed by the server synchronization provider. The synchronization adapter builder produces SELECT, INSERT, UPDATE, and DELETE statements for SQL Server databases. These statements are based on information that you provide about the tables that are involved in synchronization. For more information, see SqlSyncAdapterBuilder and Tools to Help You Develop Applications (Sync Services).



--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

Powerful .Net Framework 3.5 new features I)

Time Zone Additions—There are two new types that help you work with applications
that need to understand multiple time zones. These classes are
System.DateTimeOffset and TimeZoneInfo. The DateTimeOffset structure represents
an exact point in time. The offset indicates how the time differs from UTC
(Universal Coordinated Time). You use this new class when you need precision and
date/time arithmetic.
The TimeZoneInfo class is a welcome enhancement that represents a date and time
in a given time zone. You can use this class to reliably represent the same date and
time in any other time zone. In addition, you can use the class to create custom
time zones if needed.
. Peer-to-Peer Networking Support—The .NET Framework finally has its own
peer-to-peer networking support. This can be found in the System.Net.PeerToPeer
namespace. With it, you can create an application that works without a server and
instead communicates from one client (peer) to another (similar to Microsoft’s
Groove application). Application scenarios supported by this new namespace include
tracking where peers are (online or offline), what they might be doing, interacting
(messaging) with peers, managing peer contacts, discovering new peers, and more.
. Sync Services for ADO.NET—Shipping with Visual Studio 2008 is Microsoft’s
Sync Services. With it you can build an application that works both online and
offline. These types of applications are referred to as occasionally connected applications
(OCA). You use Sync Services (and its related tools) to indicate which data
should be available when a user is offline. When connected, the Sync Services works
to synchronize user changes with database changes.

DataPager control in ASP .NET 3.5

Another new control in 2008 that we’d like to highlight is the DataPager control. This
control allows you to manage the paging of data and the UI associated with that paging.
You can use this control by itself or embed it as part of another control you create. You can
associate other, data-bound controls to a DataPager by using the DataPager’s PagedControlID property (the given control must implement the IPageableItemContainer interface).

You have full control over the customization, layout, and behavior of the DataPager.
Figure 1.17 shows the DataPager Fields editor (accessed from the control’s Tasks window).
Notice that you can set appearance and behavior for all items associated with a given
DataPager layout.

SilverLight

Microsoft’s Silverlight is another exciting client technology for the Web. Silverlight
allows for an even greater user experience delivered through the browser. You use it to
create media-rich, highly interactive experiences. Silverlight requires a browser add-on
(or plug-in). It works with Windows, Mac, and Linux in a wide variety of browsers.
Silverlight does not ship with Visual Studio 2008; however, the Silverlight extensions
for Visual Studio are available as a plug-in to the tool.

Create a richer web interface

AJAX represents the capability to leverage the ubiquitous support for JavaScript in web
browsers to create a more interactive user experience. Client applications built to leverage
AJAX still have a client-server paradigm. However, with AJAX the client can update
portions of a given page without appearing to have posted back to the server (of course, it
typically does). In addition, most AJAX-enabled applications put more processing on the
client for things like toggling sections of a page, working with tabs, auto-completing data
entry, popping up dialogs, and more. The result is a step forward in interactivity for a user.

Enhancing the Web Developer's Productivity with Visual Studio 2008

The vast majority of applications built these days involve some semblance of a web
component—be it a full-blown browser-based, web application; a smart client that works
across the Web; a web service; or otherwise. In fact, the line between a traditional rich
client and a web application is blurring. Technologies such as AJAX (Asynchronous
JavaScript and XML), Web Services, Smart Clients, and XAML (Extensible Application
Markup Language) have ensured this. You can now build rich user experiences as your
needs dictate. Of course, Microsoft has remained suitably focused on expanding Visual
Studio’s capabilities with respect to web development.