Normes De Développement .NET

Directorate General of Administration Directorate of Information Technology

STANDARDS

DOTNET DEVELOPMENT STANDARDS

Document type:  working  validation in progress  approved for distribution

Reference: 03011a5809e948dd89d9f482009dc1a0.doc

Purpose of the document:

The purpose of this document is to describe the standards for developing an application using Microsoft's .NET technology at the CoE

This version of the document is provided as an example. The version applicable at the time of signing the contract shall be the reference.

NB: Any failure to comply with the standards or practices described in this document must be reported by the supplier prior to the start of works and validated by the Council of Europe (DIT).

This document is the property of the Council of Europe. It may not be reproduced or communicated without the prior agreement of the author.

03011a5809e948dd89d9f482009dc1a0.doc [Normes]

Dernière modification 22 五月 2014 à 23:36:00

Auteur DIT Version : 3.5 Page 1 / 31 Standards dotnet development standards

Contents

1. INTRODUCTION...... 5 1.1 Purpose...... 5 1.2 Warning signs used in this document...... 5 1.3 Reference documentation...... 5

2. CHOICE OF TECHNOLOGY...... 6 2.1 Programming language...... 6 2.2 Development environment...... 6

3. NAMING RULES...... 6 3.1 General rules...... 6 3.2 Casing styles...... 6 3.3 Casing of Different Development Elements...... 7 3.4 Graphic controls...... 7 3.5 Language Used in the Code...... 8 3.6 Files...... 8 3.7 Namespaces...... 8 3.8 Source documentation...... 9 3.8.1 General points...... 9 3.8.2 Rules to follow...... 9

4. STRUCTURING OF APPLICATIONS...... 10 4.1 Organisation of Projects...... 10 4.1.1 "Web" Projects...... 10 4.1.2 "Library" Projects...... 10 4.2 Organisation of the Solution...... 11 4.3 Data access layer (Coe.MyProject.Dal)...... 12 4.3.1 Using Entity Framework...... 12 4.3.2 Using stored PROCEDURES...... 12 4.3.3 Objects returned by the data access layer...... 12 4.4 Business layer (Coe.MyProject.Bll)...... 12 4.5 Presentation layer (Coe.MyProject.Web)...... 13 4.5.1 Code factorisation...... 13 4.5.2 Validation of data...... 13 4.6 Localisation and globalisation...... 13 4.7 Resource files...... 14

5. PARAMETERING THE APPLICATION...... 15

5.1 Connection strings...... 15 5.2 SMTP Server...... 15 5.3 Application parameters...... 15 5.3.1 General points...... 15 5.3.2 User manual...... 16 5.3.3 Links external to the application...... 16 5.3.4 Executables...... 16

6. APPLICATION ROBUSTNESS...... 17 6.1 Optimisation...... 17 6.2 Security...... 17 6.3 Managing application logs...... 17 6.4 Error processing...... 17 6.4.1...... 17 6.4.2...... 17 6.4.3 Raising application exceptions...... 17 6.4.4 Handling specific exceptions...... 18 6.4.5 Handling exceptions at global level...... 18 6.4.6 Error log...... 19 6.5 Obsolete methods...... 19 7. ORGANIZATION OF SQL SCRIPTS...... 20 8. ORGANIZATION OF SSRS REPORTS...... 22

9. TESTS AND CODE REVIEW...... 23 9.1 Setting up unit tests...... 23 9.2 The Sanity Test page...... 23

10. MODULES SUPPLIED BY THE COE...... 24 10.1 Web Service...... 24 10.1.1 WS_FileManager...... 24 10.1.2 WS_ADSearch...... 24 10.1.3 WS_Authenticate...... 25 10.1.4 Thunderstone Web Service...... 25 10.2 Libraries...... 25 10.2.1 Error Manager...... 25 10.3 Other components...... 26 10.3.1 CAS authentication module...... 26 10.3.2 Access to the meta-directory via the database...... 26

11. AVAILABLE RESOURCES...... 26 11.1 Frameworks and Libraries...... 26 11.1.1 Microsoft Ajax Library and Microsoft Ajax Toolkit...... 26

11.1.2 Button preventing double clicks...... 26 11.1.3 Enterprise Library...... 27 11.1.4 WebService Enhancements...... 27 11.1.5 Library for creating Excel documents...... 27 11.1.6 Libraries for creating Pdf documents...... 27 11.1.7 Library for compressing files in different Formats...... 27 11.1.8 Library for creating mobile web applications running on all mobile devices, telephones etc...... 27 11.2 Sample Application...... 27

1. INTRODUCTION

1.1 PURPOSE

This document sets out the standards to be applied when developing a .Net application for the Council of Europe. All the rules described in this document must be scrupulously complied with, and corresponding checks will be made on each delivery.

For the standards governing implementation of applications in general, please refer to the document describing the Council of Europe information system standards enclosed with the developer's toolkit.

Failure to comply with the standards and norms of the Council of Europe may result in a delivery being rejected.

1.2 WARNING SIGNS USED IN THIS DOCUMENT

The pictograms below are used throughout this document to emphasise important points or notions.

Important information

Specific action

Action to be avoided

Mandatory action

1.3 REFERENCE DOCUMENTATION

It is imperative that the following documentation be taken into account for developments:

JS/CSS/HTML documentation SVN documentation Graphic charter

2. CHOICE OF TECHNOLOGY

2.1 PROGRAMMING LANGUAGE

All the applications developed (Web Application, Windows Application, Web Services, Windows Service) must use C# language. All ASP.Net pages must use Code-behind technology.

2.2 DEVELOPMENT ENVIRONMENT

Microsoft Visual Studio 2010, the .Net 4.0 framework and SQL Server 2008 R2 are to be used for new developments.

For evolutions of an existing project, the framework used will be the one used by the project, unless the Council of Europe decides to migrate to a more recent version of the product.

For a SharePoint development, the framework to be used is the one recommended for the target SharePoint version.

3. NAMING RULES

3.1 GENERAL RULES

The naming convention recommended by Microsoft must be scrupulously followed: http://msdn2.microsoft.com/fr-fr/library/ms229043.aspx

3.2 CASING STYLES

Three different casing styles are used.

Pascal casing: The first letter of each word is capitalised. Example: PascalCasing

Camel casing: The first word is in lowercase, and all the following words in Pascal casing Example: camelCasing

Uppercase: All the letters are capitalised. By convention, it is used only for words or acronyms less than three characters long. However, an exception may be made for indicators used for the main Namespace. Example: IO

3.3 CASING OF DIFFERENT DEVELOPMENT ELEMENTS

Development Casing Example element Class Pascal Public class FileStream Interface Pascal Public interface IFacade prefixed with an uppercase I Attributes Pascal [EntitySetAttribute("MyPersonalAttribute")] with the suffix Attribute Properties Pascal public bool NewProperty { get; set; } Parameters Camel String myVariable and variables Methods Pascal Public void GetUser() Components Camel txtNom Enumerations Pascal Public enum MyEnum Events Pascal Public event MyEventHandler TriggerIt;

3.4 GRAPHIC CONTROLS

To make the source code easier to read, all the names of graphic controls must be prefixed by their type: [TYPE_CONTROL][NAME_CONTROL]

Control Example

label lblMyLabel textBox txtMyTextBox drop-down list ddlMyList checkBox cbMyCheckBox panel pnlMyPanel update panel upnlMyUpdatePanel gridView gvMyGridView TreeView tvMyTreeView ListView lvMyListView link button lnkMyLink object data source odsMyDataSource radio button rbMyRadioButton required field validator rfvMyValidator regular expression validator regvMyValidator range validator rngvMyValidator hidden field hidMyHiddenField image imgMyImage User control ucMyUserControl Div divMyDiv Form formMyForm

Example:

3.5 LANGUAGE USED IN THE CODE

For the classes representing business objects and also for the rest of the code, one language only - English - must be used throughout the project, and the use of accents and other special characters must of course be excluded.

Clear, concise terms must be used to indicate roles and actions consistently throughout the application.

The following list of verbs covers the most common actions:

Verb or Keyword Meaning Example

Get Retrieval of an object getAgentsById()

Update Updating of an object updateAgent()

Create Creation of an object createAgent()

Delete Deletion of an object deleteAgent()

Is (Can, or similar prefix) Boolean value (variable, function isUpToDate(), or method) isAdministror(), canDeleteItem()

In general, care must be taken to correctly compile the name of a method:  it always begins with a verb describing the action  the verb is followed by one or more names of objects and/or properties if necessary

3.6 FILES

Pascal casing must be used for filenames. The filename must be consistent with the class name (example: file UserService.cs and class UserService). For a substantially sized class, the code could be broken down into several files using the partial keyword.

Example: with our UserService class UserService.cs UserService.AccessRights.cs UserService.UserData.cs

3.7 NAMESPACES

Namespaces are used to group functionalities or applications with common features, in sets.

Approach taken for Web projects (international standard):

 the namespaces root must contain the name "Coe" to clearly identify the packages produced by or for the Council of Europe;  the first suffix designates the application;  the second suffix corresponds to the name of the project (domain, see section on structuring of applications);  the following suffixes are optional for defining sub-categories; they usually correspond to the file's position in the project tree structure.

Examples:

A model in the HCMS application: Coe.Hcms.Business.Models A web page in HCMS: Coe. Hcms.Web.WebForms An encryption class in HCMS: Coe.Hcms.Utils.Security Error management class developed at the Coe: Coe.WebModules.ErrorManager.ExceptionHandler

3.8 SOURCE DOCUMENTATION

3.8.1 GENERAL POINTS

The application source code must be accompanied by comments in French or English using the Visual Studio automatic documentation tool. One of these 2 languages must be chosen and used throughout the application.

The comments associated with the code are important. It should be noted that the point of the comments is not to paraphrase the code or to reproduce it in pseudo-code, but to provide all the information needed for efficient maintenance and swift familiarisation. It should be noted that if the structure and functions of the application's different components are not clear from a quick read-through of the names of classes, methods and short descriptions, it may be a good idea to review the naming of those classes or methods rather than writing lengthy comments. Where algorithms are used, it is important to specify the limits and/or constraints associated with the algorithm as well as the references (name of the algorithm, similar method etc) so that it may be swiftly appropriated.

3.8.2 RULES TO FOLLOW

 All the classes must be commented on using the "summary" tag. The comment must contain an explicit description of the class:

 All the functions must be commented on and the input and output parameters must be indicated in detail;

 In the code-behind of the ASP.Net pages, the comments on functions corresponding to events (OnClick, PageLoad etc) are optional. However, they are mandatory for all functions added by developers;  Any portion of complex code must be commented on.

It is important to use .NET tools such as regions (#region … #endregion) to make the code easier to read, but also to simplify maintenance. It is recommended, therefore, that the code be organised in the form of well differentiated logic regions.

4. STRUCTURING OF APPLICATIONS

All the applications developed for the Council of Europe must implement an n-tier architecture, with each layer corresponding to a separate project of the solution.

4.1 ORGANISATION OF PROJECTS

4.1.1 "WEB" PROJECTS

"Web" projects must be Web Applications and not Websites.

The different directories that could be present in a "Web" project are listed below:

Directory Description App_Code Directory containing the shared classes of the Web project App_Data Directory containing one or more databases (used during the development, to be deleted before integration) App_GlobalResources Directory containing the project resource files App_Themes Directory containing the project themes and stylesheets App_WebReferences Directory containing the references to WebServices Help Directory containing the contextual help files Images Directory containing the images used in the MMI Js Directory containing the Javascript scripts WebForms Directory containing the application's ASPX pages UserControls Directory containing the user controls Properties Directory containing the assembly.cs file References Directory containing the project references

It is imperative that the different elements of the application are organised according to this structure: each Web project must contain a "Properties" directory containing an "AssemblyInfo.cs" file.

THE JAVASCRIPT / CSS / HTML DEVELOPMENT ARE DESCRIBED IN A SEPARATE DOCUMENT AND MUST BE TAKEN INTO ACCOUNT IN THE SAME WAY AS THE PRESENT DOCUMENT.

4.1.2 "LIBRARY" PROJECTS Each "Library" project must contain a "Properties" directory containing an "AssemblyInfo.cs" file. The library version must be updated upon each delivery.

Example:

[assembly: AssemblyTitle("Coe.Passport.BLL")] [assembly: AssemblyDescription("")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("Council of Europe")] [assembly: AssemblyProduct("Coe.Passport.BLL")] [assembly: AssemblyCopyright("Copyright © Council of Europe 2010")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")]

[assembly: ComVisible(false)] [assembly: Guid("03ac60a6-777d-482d-b00f-b0f61b828172")] [assembly: AssemblyVersion("1.4.3.0")] [assembly: AssemblyFileVersion("1.4.3.0")]

The versions number will be automatically updated during deployment, it is not necessary to update

4.2 ORGANISATION OF THE SOLUTION

All the solutions developed for the Council of Europe must be organised as follows:

 the solution file (.sln) must be located at the root of the SVN repository (see SVN documentation referenced in § 1.3) of the version (eg: 2.0.3.x) and this file will have the same name as the project (example: Coe.SiteManager.sln);  one directory must be created per project in the root directory. Each directory will contain a project file whose name will consist of the name of the project followed by the project type extension (example: Coe.SiteManager.Dal).

The different project directories which might be created in the root directory are:

 Entities project: containing the business objects (example: Customer object, Product object, Supplier object etc);  Dal project: containing the data access layer;  Bll project: containing the business layer;  Utils project: containing the classes of utilities;  Web project: containing the application presentation layer.

If necessary, other projects could be created, with the agreement of the Council of Europe architect.

An example of project organisation is given below:

D:\sources\Coe.SiteManager\ D:\sources\Coe.SiteManager\Coe.SiteManager.sln D:\sources\Coe.SiteManager\Coe.SiteManager.Web\ D:\sources\Coe.SiteManager\Coe.SiteManager.Web\Coe.SiteManager.Web.csproj D:\sources\Coe.SiteManager\Coe.SiteManager.Bll\ D:\sources\Coe.SiteManager\Coe.SiteManager.Bll\ Coe.SiteManager.Bll.csproj D:\sources\Coe.SiteManager\Coe.SiteManager.Dal\ D:\sources\Coe.SiteManager\Coe.SiteManager.Dal\ Coe.SiteManager.Dal.csproj

NB: The elements in bold are directories, and the other elements correspond to files.

4.3 DATA ACCESS LAYER (COE.MYPROJECT.DAL)

For data access, either Entity Framework or a more classic data access layer based on the use of stored procedures will be used.

4.3.1 USING ENTITY FRAMEWORK

.NET LINQ query language may be used, with Entity Framework recommended for managing the data access layer.

The EDMX model will have to be kept up to date from the database.

On the other hand, LINQ to SQL is to be avoided. Any use of LINQ to SQL will have to be justified and expressly validated (example: database without any constraint).

4.3.2 USING STORED PROCEDURES

In this case, it is imperative for the data access layer to use the "Data Access Application Block" libraries of "Enterprise Library 5" supplied by Microsoft (available from the following link): http://entlib.codeplex.com/

All database access must be via stored procedures.

No query must appear in the source code.

4.3.3 OBJECTS RETURNED BY THE DATA ACCESS LAYER

The data access layer must return only business objects or typed DataSets to the upper layers.

4.4 BUSINESS LAYER (COE.MYPROJECT.BLL)

This corresponds to the functional part of the application, which implements the logic and describes the operations performed by the application on data in response to users' queries, forwarded by the presentation layer.

The different rules for managing and controlling the system are implemented in this layer.

The business layer provides application and business services to the presentation layer. To provide those services, it relies, where applicable, on the system data, accessible through the services of the lower layer, and then sends the results it has computed to the presentation layer.

Depending on the application architecture, this layer could be broken down into several projects (for example: a project for services, a project for interface contracts and a project for business objects).

4.5 PRESENTATION LAYER (COE.MYPROJECT.WEB)

In addition to the imperative need to take account of the different points detailed in this section for the implementation of the presentation layer, it is imperative that the

Auteur DIT Version : 1.0 Page 14 / 31 Standards dotnet development standards service provider refers to the graphic charter supplied by the CoE in the developer's toolkit.

4.5.1 CODE FACTORISATION The code must be factorised as much as possible: for this, we recommend using MasterPages and user controls.

You are also advised not to make direct use of System.Web.UI.Page and System.Web.UI.Control classes, but to go through intermediate classes specific to the project (CoE.xxxx.Web.BasePage & CoE.xxx.Web.BaseControl for example), which themselves inherit from System.Web.UI.Page and System.Web.UI.Control respectively.

4.5.2 VALIDATION OF DATA The values input must be checked on both the client side and the server side, to maximise application security.

Client side Checks must be run on all input fields.

- either through validation components supplied by the framework:  RequiredFieldValidator: check on the presence of required data;  CompareValidator: comparison of the input value with the reference value;  RangeValidator: the input value is within a given range of values;  RegularExpressionValidator: validation of data through a regular expression;  CustomValidator: validation of data through a function.

Each page containing a validator check must also contain a "ValidationSummary" component to alert the user to errors during validation.

- or through the "Validation" jQuery plug-in (cf. JavaScript/CSS/HTML development standards).

Server side Each of the values input by the user must be validated on the server side. These checks should preferably be run in the business layer, with clear management of any errors reported to the presentation layer.

4.6 LOCALISATION AND GLOBALISATION

All applications developed for the Council of Europe must provide for multilingual management (which will mostly entail creating the application in English and French, but it must be possible to add new languages easily even if only one language is initially envisaged).

The application's users must be able to change the interface language when more than one language is defined.

Their choice of language must be memorised and updated, for both authenticated users and anonymous users, in a "coe_language" cookie with a lifespan of one year.

This cookie must cover the coe.int domain, meaning that it will be the same for all CoE applications. It must be used as a priority when the application is accessed to determine

Auteur DIT Version : 1.0 Page 15 / 31 Standards dotnet development standards the user interface language. Whenever the user logs in, the cookie will be updated for a fresh duration of one year. The value of this cookie must correspond to a locale supported by the CultureInfo class (http://msdn.microsoft.com/en- us/library/abeh092z.aspx).

If this cookie is not present, the application must determine the language to be used in the light of the language preferences set at the level of the browser. If none of those languages are listed at the level of the browser, English will be selected by default.

To facilitate the translation of applications, global resource files must be used, and not local resource files. In the project, there must be only one resource file per language, except for a very high-volume application for which the resources could be split between 2 and 10 files maximum, organised on a logical basis (one file for help, one for error messages etc).

4.7 RESOURCE FILES

The information displayed in the MMI must come from a resource file, and must not be hard-coded in the application.

To facilitate the translation of applications, global resource files must be used, and not local resource files. In the project, there must be only one resource file per language, except for a very high-volume application for which the resources could be split between 2 and 10 files maximum, organised on a logical basis (one file for help, one for error messages etc).

The resource files must be named using the following nomenclature: resources.language_code.resx

Example:

 resources.en.resx  resources.fr.resx

5. PARAMETERING THE APPLICATION

5.1 CONNECTION STRINGS

All connection strings must be in a configuration file called "connectionString.config" in the project root WEB. This file will be referenced in the web.config file like describe bellow

Only accounts with db_datawriter or db_datareader rights are allowed for applications web.config ... ... connectionString.config

5.2 SMTP SERVER

The SMTP server used by the application to send e-mails must be defined in the configuration file, in the "mailSettings" section.

Example:

... ...

It is possible to define a single address for all e-mails sent by the application by filling in the "from" property of the "smtp" tag.

5.3 APPLICATION PARAMETERS

5.3.1 GENERAL POINTS All the parameterisable elements of each of the application's projects must be located in the configuration file (web.config). They will be defined in the "applicationSettings" section.

Example:

the value ...

It should be noted that each project of the solution has its own applicationSettings block in web.config.

The keys used to define the settings must have explicit names. Each setting must be accompanied by a comment making the configuration file easier to read.

The AppSettings section is outmoded and must no longer be used.

5.3.2 USER MANUAL

The User Manual for web applications must be accessible via a link in English and in French.

This documentation link must be defined in a configuration key of the web.config file: http://Url_du_Site/DOC/nom_application/MU_nom_application_FR.pdf and http://Url_du_Site/DOC/nom_application/MU_nom_application_EN.pdf

Here is an example:

http://liv.dit.coe.int/DOC/Passeports/MU_Passeports_FR.pdf

5.3.3 LINKS EXTERNAL TO THE APPLICATION

Generally speaking, all the links external to the application present in the master page will be defined in configuration keys of web.config.

5.3.4 EXECUTABLES All the parameterisable elements concerning executables must be located in the Exe.config configuration file.

6. APPLICATION ROBUSTNESS

6.1 OPTIMISATION

In general, there must be heavy emphasis on the performances of applications being created. Depending on the tasks carried out by the application, global response times and response times specific to each activity will be monitored in order to guarantee correct operation within a reasonable execution time.

Regardless of the application type, it must be ensured that the resources common to all the application's instances are set as a static variable (therefore shared). If common resources are modified, secure concurrent access must be ensured.

6.2 SECURITY

The application must be designed in accordance with good application security practices.

The good practices to be taken into account include:

 Remember to always test the permissions and access rights on the server side (in the code-behind or the business layer) for all the pages. Use PrincipalPermission for role-based securing of the business methods.  Use role-based security for directories in web.config  Prevent SQL injection by using SqlParameters and, more generally, validate the different inputs coming from the MMI without blindly trusting them.  Prevent Cross-Site Scripting by using HtmlEncode and HtmlDecode.

6.3 MANAGING APPLICATION LOGS

Any application should provide logs. At the minimum, the errors that are fatal to the functioning of the application are to be logged. Depending on the needs, other logging levels could be added (debugging, information on the technical process, functional information etc)

For error logs, use of the "Error Manager" library is mandatory (see § 8.2.1).

6.4 ERROR PROCESSING

6.4.1 RAISING APPLICATION EXCEPTIONS For exceptions raised by the application, application error classes inheriting from the Exception class in all cases are to be used.

However, since internal processing of exceptions is more costly in runtime, care must be taken to raise exceptions only where absolutely necessary.

6.4.2 HANDLING SPECIFIC EXCEPTIONS

Care must be taken to manage certain potential specific errors in the code. Any code block potentially posing a known problem must be managed accordingly using try, catch, finally blocks. A clear error message must be displayed to the user, and the error must be logged with all the information of use in resolving it.

Example of a case requiring specific exception handling:

 Try-catch for an error in connecting to a DB or LDAP or any other component external to the code, resulting in a clear error message being returned to the user and the error being logged.  Try-catch to manage an error recovery (example: retrying an operation presenting random errors and raising the exception only on the second crash)

Recommendations:

 Prevention is better than cure: protect against cases of errors by "defensive programming", for example by always testing the case where a nullable object is null before accessing one of its properties or methods, and provide for appropriate management of this case.  Run an existence test before an INSERT.  Set up catches on specific exception classes, and avoid catches for the Exception generic class.  Avoid writing try-catch blocks as part of a large code block. It is preferable to have several separate try-catch blocks covering specific errors if needed.  For a throw of the original error in the catch block, use the throw instruction; if the exception is not specified, the error's original "call stack" is preserved.  Do not set up a try-catch block if no specific handling or specific message is necessary. Exception handling at global level will take care of tracing the error.  "Error recovery" must be preferred whenever feasible.

Never catch an exception without doing anything about it. It must at least be logged.

6.4.3 HANDLING EXCEPTIONS AT GLOBAL LEVEL The aim here is to trace all the exceptions not managed by specific exception handling:

 For ASP.NET projects, the "Global.asax" file must centralise error handling by capturing any error not managed in the web application (Application_Error method). This makes it possible, for example, to redirect the web user to a customised page managing the current error according to its type. protected void Application_Error(object sender, EventArgs e) { LogException exceptionLog = new LogException(); Exception ex = Server.GetLastError().GetBaseException(); if (ex != null) { exceptionLog.HandleException(ex, HttpContext.Current); } }

 For the other projects, exception handling must be via a try catch encapsulating the main sub-code (or the equivalent).

6.4.4 ERROR LOG Errors must be logged as they occur by "Error Manager" as stipulated in the section on log management above. This library ensures uniform management of errors returned by the CoE's applications. Its use is mandatory.

6.5 OBSOLETE METHODS

All obsolete methods are to be excluded from application developments. These methods are signalled by the .NET Framework when they are used.

7. ORGANIZATION OF SQL SCRIPTS

The SQL part tree in SVN is as follows

• Functions: contains all the SQL database functions (1 script for 1 functions) • Stored Procedures: Contains all the SQL database stored procedures (1 script for 1 Stored Procedure) • Queries: Contains scripts to update data. After each Go Live, the scripts in the root of this directory will be moved to a directory MEPyyyymmdd by the integrator • Tables contains tables change scripts: After each Go Live, the scripts in the root of this directory will be moved to a directory MEPyyyymmdd by the integrator • Views: contains scripts modifying views: After each Go Live, the scripts in the root of this directory will be moved to a directory MEPyyyymmdd by the integrator • Index: contains index creation scripts: After each Go Live, the scripts in the root of this directory will be moved to a directory MEPyyyymmdd by the integrator

When deploy, all the scripts in the root directories mentioned will be execute on the database, which is why they are moved to a directory after each integration cycle except for Functions and Stored Procedures because each script should drop and create the object.

It is necessary that the scripts in the same directory are numbered to designate the order to be executed 001_...... sql 002_...... sql

Example :

/****** Object: UserDefinedFunction [dbo].[Func_GEDAdoptedTextsListing] Script Date: 09/06/2012 11:58:30 ******/ IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo]. [Func_GEDAdoptedTextsListing]') AND type in (N'FN', N'IF', N'TF', N'FS', N'FT')) DROP FUNCTION [dbo].[Func_GEDAdoptedTextsListing] GO

/****** Object: UserDefinedFunction [dbo].[Func_GEDAdoptedTextsListing] Script Date: 09/06/2012 11:58:30 ******/ SET ANSI_NULLS ON GO

SET QUOTED_IDENTIFIER ON GO

CREATE FUNCTION [dbo].[Func_GEDAdoptedTextsListing] ( -- Add the parameters for the function here @Param1 int = 1900, @Param2 int = 0 ) RETURNS TABLE AS RETURN ( -- Add the SELECT statement with parameter references here ……………… )

No script must contain the statement "Use database" or the name of a server

8. ORGANIZATION OF SSRS REPORTS

The SSRS part tree in SVN is as follows

The solution containing the reports must be in the root of SQLReports directory with the rpt.proj files, the Datasource files and the Reports Files. The Rtp.proj file should not be part of the global project solution unless it is necessary and justified

It is also necessary to have an impersonification level code to access the server Reports. The server is configured as follows in terms of security

Below a code example to access Reports :

//initialisation du Reporting Service ReportExecutionService rs = new ReportExecutionService(); System.Net.ICredentials netCredential = new System.Net.NetworkCredential(ConfigurationSettings.AppSettings["reportUserN ame"].ToString(), ConfigurationSettings.AppSettings["reportUserPassword"].ToString(), ConfigurationSettings.AppSettings["reportUserDomain"].ToString()); rs.Credentials = netCredential;

Et ceci dans le fichier de config

9. TESTS AND CODE REVIEW

9.1 SETTING UP UNIT TESTS

Unit tests are a highly effective means of testing the code.

The tools provided by Visual Studio (professional version) are to be used for unit testing. The procedure is simply to create test projects which must be integrated in the solution.

This page will be preferably here: webforms\tools\Sanitests.aspx

These may be used in several cases, the most common one being simply to ensure that a method returns the expected result in relation to the parameters it is given.

Unit tests might also be used for "Test-Driven Development", which involves writing tests as the application is developed. Accordingly, it is the test that makes it possible to develop classes, methods etc. There is strong emphasis on the "Test-Driven Development" technique in the 2010 version of Visual Studio.

The creation of "Unit tests" is mandatory. The tests must cover at least 80% of the application's functionalities.

9.2 THE SANITY TEST PAGE

A fixed web URL, with no parameters or authentication, must supply a test report on the application's different components. These tests, known as sanity tests, must ensure that the application works.

In particular, this URL will be called up by the Nagios supervision tool at regular intervals, which means that this test page must be generated at sufficient speed.

This page will be preferably here: webforms\tools\Sanitests.aspx

List of sanity tests to be included:

 Database connection test. One for each connection.  LDAP directory binding test  Test of permissions required for the application (eg writing test on the fileSystem)  Webservices connection test  E-mailing test  Test for the presence of parametered directories and files in the application configuration files  Other tests useful for ensuring that the application is properly installed

The return from this page is in XML format.

The complete list of methods is available in the COE.SanityTest.dll which is at the root of the directory in the common_dll folder at the root of SVN repository

Example:

Machine-comprehensible code (optional) Human-comprehensible description of test Human-comprehensible message ...

This page must not be accessible from the Internet. (For security reasons, no information must be given on the CoE's IS)

10. MODULES SUPPLIED BY THE COE

The CoE supplies a number of modules which must be used for specific actions within the different applications.

The user manuals for the different applications are available among the resources provided by the developer's toolkit.

10.1 WEB SERVICE

10.1.1 WS_FILEMANAGER WS_FileManager is a Web Service for carrying out operations on files (sending, deleting, recovering information) from the Client application via SOAP queries.

This Web Service must be integrated in the CoE web applications requiring file management.

10.1.2 WS_ADSEARCH WS_ADSearch is a Web Service for running a search in the LDAP based on a name, an account name or a group name or a name-based search in the Meta-directory. It also enables retrieval of an employee's e-mail address from their identifier.

This Web Service may be integrated in the CoE web applications requiring LDAP searches to be run. An alternative is to use SQL queries on the Meta-directory database.

10.1.3 WS_AUTHENTICATE This authentication service is obsolete. For new applications, use CAS for authentication.

WS_Authenticate is a Web Service for authenticating a CoE user with the Meta-directory.

10.1.4 THUNDERSTONE WEB SERVICE The Thunderstone Web Service must be used if an indexing service / search engine must be set up in the application.

10.2 LIBRARIES

10.2.1 ERROR MANAGER

This manager makes it possible to trace errors uniformly when they occur.

This dll must be integrated in CoE web applications. All errors must be traced by "Error Manager".

10.2.2 CAS AUTHENTICATION MODULE

CAS (Central Authentication Service) is the single sign-on system used at the Council of Europe.

It must be implemented for the authentication of any new ASP.NET application.

10.2.3 ACCESS TO THE META-DIRECTORY VIA THE DATABASE

This method of accessing meta-directory information may be integrated in the CoE's web applications requiring the running of LDAP searches. An alternative is to use the WS_ADSearch web service

11. AVAILABLE RESOURCES

Use of these resources must be a priority: the service provider must not use other libraries or modules equivalent to those proposed here without first notifying the CoE and clearly justifying the need. All these resources are available in subversion at: http://versioning.coe.int/svn/common_tools/trunk/common_dll To facilitate integration of these resources in projects and ensure that everyone uses the same version of the libraries, each SVN repository will contain an external link pointing to the link given above.

11.1 FRAMEWORKS AND LIBRARIES

11.1.1 MICROSOFT AJAX LIBRARY AND MICROSOFT AJAX TOOLKIT

Microsoft Ajax Library consists of an Ajax Framework on the server side and an Ajax Framework on the client side (set of JavaScript files). This part is included in the .NET 3.5 Framework. Microsoft Ajax Toolkit: set of controls for improving the ergonomics and performances of Web applications.

11.1.2 BUTTON PREVENTING DOUBLE CLICKS

ClickOnceButton.dll

11.1.3 ENTERPRISE LIBRARY

Used in particular to access data, thanks to a module encapsulating the ADO.NET objects specific to the databases.

Microsoft.Practices.EnterpriseLibrary.Common.dll Microsoft.Practices.EnterpriseLibrary.Data.dll Microsoft.Practices.EnterpriseLibrary.Logging.dll

11.1.4 WEBSERVICE ENHANCEMENTS

WSE helps to simplify the development and deployment of secure Web Services. Microsoft.Web.Services.dll

11.1.5 LIBRARY FOR CREATING EXCEL DOCUMENTS

EPPlus.dll

11.1.6 LIBRARIES FOR CREATING PDF DOCUMENTS

PdfSharp.Charting-WPF.dll PdfSharp-WPF.dll PdfSharp-WPF.resources.dll

11.1.7 LIBRARY FOR COMPRESSING FILES IN DIFFERENT FORMATS

ICSharpCode.SharpZipLib.dll

11.1.8 LIBRARY FOR CREATING MOBILE WEB APPLICATIONS RUNNING ON ALL MOBILE DEVICES, TELEPHONES ETC

FiftyOne.Foundation.dll

11.2 SAMPLE APPLICATION

A NET.4 solution including good practice to call COE WebService, using FileManager (document storage), an example of sanityTest and integration of CAS (authentication system) is available to developers at the following address: http://versioning.coe.int/svn/vdd/trunk/3_RESOURCES_DISPONBLES/COE.Sample

End of document

Auteur DIT Version : 1.0 Page 31 / 31