HtmlToText
using system; // .net blog translate this page traduire cette page fournie par microsoft® translator rechercher recherche ./ blog technologique de matthieu nicolescu .net architect & developper me contacter 1 2 3 4 5 6 7 8 9 10 > >> 1 octobre 2015 4 01 / 10 / octobre / 2015 07:33 monter votre serveur nuget en 5 minutes pour gérer les dépendances des composants internes à votre entreprise ainsi qu'aux packages externes (si vous souhaitez contrôler l'accès des packages pour restreindre les packages pouvant être utilisé par vos développeurs), la meilleure solution qui s'offre à vous est de mettre en place un serveur nuget à votre entreprise... et cela se fait très facilement ! première étape créer une application web asp.net vide : ajouter ensuite le package nuget "nuget.server" à votre application web : dans les settings de votre web.config our sécuriser l'accès à votre serveur de packages, vous avez deux paramètres importants : <add key="requireapikey" value="true"/> <add key="apikey" value="mykey"/> le premier "requireapikey" permet de spécifier si une clef est nécessaire pour envoyer un package. le deuxième est la clef en question. il ne vous reste plus qu'à publier votre site sur votre infrastructure on-premise ou azure (ou autre !). repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 25 août 2015 2 25 / 08 / août / 2015 12:20 planifier votre migration tfs 2015 un point d'entrée intéressant si vous compter migrer votre serveur team foundation server dans sa version 2015 : http://blogs.msdn.com/b/visualstudioalm/archive/2015/08/14/team-foundation-server-2015-upgrade-planning.aspx . repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 25 août 2015 2 25 / 08 / août / 2015 11:33 release management : gérer vos releases path pour atteindre votre environnement cible (la production par exemple), votre release doit parcourir un chemin prédéfinis (ex : dev --> staging --> preprod --> prod), chemin qu'on appelle release path avec release management. avant de configurer votre release path, penser à bien définir vos stage type (menu administration>>manage pick lists) et environnements (menu configure paths>> envrionments). pour ce dernier (un environnement), il correspond à un ensemble de serveurs liés au stage type de votre release path. si vous êtes dans un environnement azure, vous pouvez lier vos serveurs via les boutons "link azure envrionment" et "link azure servers" (pensez à lier au préalable votre abonnement azure via le menu administration>>manage azure). vous êtes à présent prêt pour créer votre release path via le menu configure paths>>release paths>>new (azure pour un environnement azure ou standard pour un environnement on-premise). voici une copie d'écran un release path avec deux stages dev et staging : comme vous pouvez le voir, chaque stage est lié à un environnement, un approbateur, un propriétaire et un validateur. concernant les étapes d'approbation et de validation vous pouvez constater que concernant le stage dev, ces étapes sont automatique et ne nécessite pas d'opération manuelle utilisateur. votre release template (workflow qui définit le processus de livraison), il reprendra le chemin de votre release path (dans notre cas dev et staging) : pour lancer une nouvelle release, l'interface vous demandera votre stage cible et le processus de livraison suivra alors le chemin définit avec toutes les étapes nécessaire pour atteindre la cible. repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 13 août 2015 4 13 / 08 / août / 2015 11:58 tester votre analyseur de code nous avons vu dans cet article comment créer un analyseur de code c#. voyons comment à présent créer des test unitaires pour vos analyseurs. le plus simple est de partir sur les helpers générés par le template de projet "analyzer with code fix" qui va vous généré un projet de test unitaire (il vous faut installer le .net compiler sdk) : ajouter votre classe de test unitaire en héritant de la classe diagnosticverifier généré par le template du projet de test unitaire qui vous apporte la méthode verifycsharpdiagnostic que nous allons utiliser comme suit : [ testmethod ] public void methodnametoolongoktest() { var test = @"public static class helpers { public static void methodnameistoolong() { } }" ; var expected = new diagnosticresult { id = "methodnametoolong" , message = "the method name methodnameistoolong cannot exceed 15 characters" , severity = diagnosticseverity .warning, locations = new [] { new diagnosticresultlocation ( "test0.cs" , 4, 28) } }; verifycsharpdiagnostic(test, expected); } repost 0 published by matthieu nicolescu - dans microsoft.csharp commenter cet article 13 août 2015 4 13 / 08 / août / 2015 11:25 analyseur de code c# une des nouveautés apportées avec visual studio 2015 est la possibilité d'étendre l'analyseur de code plus facilement que ce soit en important une librairie ou avec vos packages vsix et nugget. pour créer votre analyseur, créer une librairie c# avec la configuration nuget suivante : <? xml version = " 1.0 " encoding = " utf-8 " ?> < packages > < package id = " microsoft.codeanalysis.analyzers " version = " 1.0.0 " targetframework = " net46 " /> < package id = " microsoft.codeanalysis.common " version = " 1.0.0 " targetframework = " net46 " /> < package id = " microsoft.codeanalysis.csharp " version = " 1.0.0 " targetframework = " net46 " /> < package id = " system.collections.immutable " version = " 1.1.36 " targetframework = " net46 " /> < package id = " system.reflection.metadata " version = " 1.0.21 " targetframework = " net46 " /> </ packages > une fois les packages téléchargés, créer votre premier analyseur. voici un exemple d'analyseur qui se déclenche sur une méthode et vérifie que le nom de la méthode ne dépasse pas 15 caractères : [ diagnosticanalyzer ( languagenames .csharp)] public class methodnameanalyzer : diagnosticanalyzer { public const string diagnosticid = "methodnametoolong" ; internal static readonly localizablestring title = "method name too long" ; internal static readonly localizablestring messageformat = "the method name {0} cannot exceed 15 characters" ; internal const string category = "syntax" ; internal static diagnosticdescriptor rule = new diagnosticdescriptor (diagnosticid, title, messageformat, category, diagnosticseverity .warning, true ); public override immutablearray < diagnosticdescriptor > supporteddiagnostics { get { return immutablearray .create(rule); } } public override void initialize( analysiscontext context) { context.registersymbolaction(analyzesymbol, symbolkind .method); } private static void analyzesymbol( symbolanalysiscontext context) { if (context.symbol.name.length > 15) { var diagnostic = diagnostic .create(rule, context.symbol.locations[0], context.symbol.name); context.reportdiagnostic(diagnostic); } } } vous pouvez partir d'un squelette prédéfinis en ajoutant un nouvel élément analyser "visual c# items>extensibility" (il vous faut pour cela installer le .net compiler sdk) : ajouter ensuite l'analyser (la dll) dans votre programmer principale ("references>analyzers>add") et tester ! le code suivant doit vous donner le rendu visual studio ci-dessous : public void methodnameistoolong() { } repost 0 published by matthieu nicolescu - dans microsoft.csharp commenter cet article 12 août 2015 3 12 / 08 / août / 2015 12:42 tfs backlog items workflow par défaut dans votre projet tfs, le backlog contient les états suivants : - new - approved - committed - done le workflow de gestion de vos items dans votre backlog est le suivant : new --> approved le product owner donne son accord new --> removed le product ower décide que l'item ne doit plus être développé approved --> committed quand l'équipe décide de développer l'item dans le sprint courant approved --> removed quand l'équipe décode de sortir la fonctionnalité du sprint removed --> new quand l'équipe reconsidère une fonctionnalité committed --> done quand l'équipe considère l'item comme finalisé done --> committed l'équipe a trouvé du travail à encore effectuer sur l'item committed --> approved changement de priorité : l'item sort du sprint courant ce backlog est une version simpliste : pas de notion de testé, déployé ou autre étape spécifique... nous verrons dans d'autres billets comment customiser votre backlog. repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 11 août 2015 2 11 / 08 / août / 2015 11:15 dsc resource kit nous avons vu dans ce billet que le module xwebadministration rajoute des ressources dsc powershell pour gérer iis dans vos scripts powershell de déploiement. il y a encore mieux : le dsc resource kit ! en plus d'inclure xwebadministration, le resourcekit inclut plus d'une centaine de resources dsc pour gérer notamment le cloud azure, serveur sql... un must to have ! [update] : le site github . repost 0 published by matthieu nicolescu commenter cet article 11 août 2015 2 11 / 08 / août / 2015 10:58 installer un site web avec release management nous allons voir dans cet article comment installer automatiquement un site web avec release management et le les ressources dsc powershell xwebadministration . ajoutez tout d'abord dans votre livrable votre script powershell d'installation du site web. dans notre exemple nous avons appelé le script "deploywebsite.ps1" et est sous la forme suivante : configuration installdemowebsite { import-dscresource -module xwebadministration node $allnodes . nodename { file copydeploymentbits { ensure = "present" type = "directory" recurse = $true sourcepath = $applicationpath destinationpath = $node . deploymentpath } windowsfeature aspnet45 { ensure = "present" name = "web-asp-net45" } windowsfeature iis { ensure = "present" name = "web-server" dependson = "[windowsfeature]aspnet45" } xwebapppool webapppool { name = $webapppoolname ensure = "present" state = "started" } xwebsite website { ensure = "present" name = $node . websitename state = "started" physicalpath = $node . deploymentpath applicationpool = $webapppoolname bindinginfo = msft_xwebbindinginformation { port = $websiteport } dependson = "[windowsfeature]iis" } } } installdemowebsite -configurationdata $configdata -verbose configuration installdemowebsite { import-dscresource -module xwebadministration node $allnodes . nodename { file copydeploymentbits { ensure = "present" type = "directory" recurse = $true sourcepath = $applicationpath destinationpath = $node . deploymentpath } windowsfeature aspnet45 { ensure = "present" name = "web-asp-net45" } windowsfeature iis { ensure = "present" name = "web-server" dependson = "[windowsfeature]aspnet45" } xwebapppool webapppool { name = $webapppoolname ensure = "present" state = "started" } xwebsite website { ensure = "present" name = $node . websitename state = "started" physicalpath = $node . deploymentpath applicationpool = $webapppoolname bindinginfo = msft_xwebbindinginformation { port = $websiteport } dependson = "[windowsfeature]iis" } } } installdemowebsite -configurationdata $configdata -verbose le script powershell copie tout d'abord les fichiers du site dans le répertoire root du site iis, vérifie la présence des features windows .net 4.5 et iis (sinon une installation de ces features sera effectuée automatiquement), pour enfin créer le pool et le site web. les variables de configuration (port, nom du pool, répertoire root iis) sont définis dans le script powershell de configuration "deploywebsiteconfigdata.ps1" : $configdata = @{ allnodes = @( @{ nodename = "*" } , @{ nodename = "localhost" ; websitename = "demosite" deploymentpath = $env:systemdrive + "\inetpub\demosite" } ) } il vous suffit pour terminer d'ajouter une nouvelle activité de déploiement powershell dans votre template de livraison releasemanagement avec les propriétés suivantes (sans oublier les variables custom telles que le nom du pool iis et le port) : repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 10 août 2015 1 10 / 08 / août / 2015 10:40 installer le module xwebadministration avec release management nous avons vu dans ce billet comment installer manuellement le module powershell xwebadministration. voyons à présent comment automatiser cette tâche avec release management pour s'assurer que le module et ses ressources dsc associées sont installés sur le serveur avant d'effectuer des opérations sur iis (comme une installation de site web par exemple). faîtes en sorte tout d'abord que dans votre build le module xwebadministration et son script de configuration dsc soit présent (ou présent sur un répertoire réseau) : le script "installxwebadministration.ps1" doit avoir la forme suivante : configuration installxwebadministration { param ( # target nodes to apply the configuration [string[]]$nodename = 'localhost', # source path for modules [string]$sourcepath = "$applicationpath\modules", # destination path for modules [string]$destinationpath = "$env:programfiles\windowspowershell\modules" ) node $nodename { # copy the modules file modulecontent { ensure = "present" sourcepath = $sourcepath destinationpath = $destinationpath recurse = $true type = "directory" } } } installxwebadministration le script de configuration powershell dsc se contente de copier les dossiers présents dans "modules" (dans notre exemple le dossier "xwebadministration") dans le répertoire des modules powershell du serveur. une fois que votre script de configuration et le(s) module(s) sont accessibles à partir du serveur, il vous suffit de déposer une nouvelle activité powershell dsc dans votre template de livraison release management : repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 4 août 2015 2 04 / 08 / août / 2015 21:28 gérer vos variables avec release management pour éviter de saisir des informations redondantes d'un serveur comme le nom utilisateur et mot de passe, il vous est possible avec release management de créer des variables attachées à votre serveur comme le montre le copie d'écran suivante : pour accéder à cet écran il vous suffit d'aller dans le menu "configure paths>>servers" et de cliquer sur le serveur à administrer. accéder ensuite à votre template de livraison. par exemple, pour exécuter un script powershell sur un serveur, le template détectera automatiquement les variables serveurs lors de la sélection de celui-ci : il vous est aussi possible d'ajouter des variables globales à votre environnement tfs à partir du menu "administration >> settings >> configuration variables" : que ce soit des variables serveur ou globale, pour les surcharger pour modifier leur valeur dans vos templates il suffit de redéfinir le nom de la variable au niveau de votre activité. repost 0 published by matthieu nicolescu - dans microsoft.alm commenter cet article 1 2 3 4 5 6 7 8 9 10 > >> articles récents monter votre serveur nuget en 5 minutes planifier votre migration tfs 2015 release management : gérer vos releases path tester votre analyseur de code analyseur de code c# tfs backlog items workflow dsc resource kit installer un site web avec release management installer le module xwebadministration avec release management gérer vos variables avec release management catégories microsoft.csharp (17) microsoft.alm (16) system.servicemodel (12) system.linq.expressions (10) system.qcm (8) system.web (7) system.cloud (6) system.dynamic (6) microsoft.practices (3) system.software.factory (3) using system; (3) microsoft.visualstudio (2) system.activities (2) system.badcodeexception (2) system.mobile (1) system.soa (1) liens wcf dev center scottgu's blog ron jacobs's blog b# .net blog dlr project blogs dotnet-france .net foundation my twitter least privilege suivez-moi suivez-moi sur facebook suivez-moi sur twitter s'abonner au flux rss blog de matthieu nicolescu, architecte .net voir le profil de matthieu nicolescu sur le portail overblog créer un blog gratuit sur overblog top articles contact signaler un abus c.g.u. rémunération en droits d'auteur offre premium cookies et données personnelles
Informations Whois
Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;
Domain Name: OVER-BLOG.COM
Registry Domain ID: 112622266_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gandi.net
Registrar URL: http://www.gandi.net
Updated Date: 2019-01-25T18:11:54Z
Creation Date: 2004-02-25T19:51:07Z
Registry Expiry Date: 2020-02-25T19:51:07Z
Registrar: Gandi SAS
Registrar IANA ID: 81
Registrar Abuse Contact Email: abuse@support.gandi.net
Registrar Abuse Contact Phone: +33.170377661
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS0.PROCEAU.NET
Name Server: NS1.PROCEAU.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2019-09-19T03:46:21Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
REGISTRAR Gandi SAS
SERVERS
SERVER com.whois-servers.net
ARGS domain =over-blog.com
PORT 43
TYPE domain
RegrInfo
DOMAIN
NAME over-blog.com
CHANGED 2019-01-25
CREATED 2004-02-25
STATUS
clientTransferProhibited https://icann.org/epp#clientTransferProhibited
NSERVER
NS0.PROCEAU.NET 83.243.21.30
NS1.PROCEAU.NET 77.87.104.10
REGISTERED yes
Go to top