CKReleaser Preview
0 views
Skip to first unread message
Olivier Spinelli
Aug 5, 2014, 5:33:03 AM8/5/14
to civik...@googlegroups.com
Bonjour,
Ci-dessous des captures d'écrans de CKReleaser, nouvel élément de CK (rappel : « Le projet CK contient un ensemble de composants logiciels en .Net d'intérêt général créé par Invenietis et publié sous licence LGPL. CiviKey s'appuie sur ces composants, de même que d'autres projets (Open Source ou non). »).
Le but de la vie de ce truc est d'augmenter la qualité du logiciel ET de simplifier certains aspects, notamment les release...
Sa place est dans un package NuGet de Solution (comme NUnit.Runners).
Cela fait plusieurs choses qui sont disponibles dans un petit menu arborescent à 2 balles.
La première est sur la Home : c'est un vérificateur de Solution folder, avec pour certains problèmes la possibilité de les réparer (fix) automatiquement (mais pas tous, faut pas rêver).
Ce qui est implémenté à date :
- Nommage :
o Le ProjectFileName « XRQ.Toto.csproj » (ce que l'on voit dans VS) est le nom de référence.
o Si l'assembly name n'est pas « XRQ.Toto », c'est TOUJOURS mal (auto fix dispo).
o Si le nom de son de son répertoire n'est pas « /XRQ.Toto » (ou « XRQ.Toto.<<TargetFrameworkIdentifier>> »), c'est mal (pas de fix automatique), sauf s'il est CONTENU dans un projet de test (cf.ci-dessous).
o Si le projet référence nunit.framework, il est considéré comme un assembly de Test. Son nom doit donc se terminer par « .Tests » (pas de fix automatique).
==> Je pense ajouter la contrainte que TOUS les projets « .Tests » doivent se trouver dans un répertoire « Tests » (cas de CK.Core).
==> Et faire que tous les fichiers de NUnit soient dedans au lieu de nous polluer la racine comme aujourd'hui...
o Si le projet est CONTENU dans un assembly de Test (cas des plugins de test par exemple), alors le nom de son répertoire peut être n'importe quoi.
- Vérification de la SharedKey
o La SharedKey.snk existe à la racine. C'est EXACTEMENT LA SharedKey (PublicKeyToken = 731c291b31fb8d27). Si elle manque, ou que ce n'est pas elle, un fix corrige la chose.
o Tout projet qui n'est pas un test ou contenu dans un test doit être signé avec la SharedKey.snk (fix automatique).
ð Les tests peuvent être signés mais ce n'est pas une obligation.
- SharedAssemblyInfo.cs
o Un SharedAssemblyInfo.cs doit exister à la racine (fix automatique).
o Tous les projets doivent le référencer en alias (mais ça c'est pas check encore...)
- CK.Stamp.Fody
o Tout projet autre que « .Tests » doit avoir le package CK.Stamp.Fody (pas de fix automatique).
- Des trucs divers :
o Pas plus d'un .csproj par folder.
o Plusieurs .sln peuvent exister. Pour l'instant, pas de contraintes, mais je pense en ajouter une : ils doivent tous commencer par le nom de la Solution, avec des suffixes éventuelles : CK-Core.sln, CK-Core.Doc.sln, CK-Core.Net40.sln, etc.
A la racine, on retrouve un bon vieux Solution.ck (initialisé automatiquement) qui contient la « mémoire » de CKRelease.
Ce fichier doit être commit.
La page Home à date :
[cid:image0...@01CFB0A0.F88AB6D0]
Après application du fix:
[cid:image0...@01CFB096.53A1F660]
On peut refuser l'application d'un fix. Le refus est mémorisé (la case à cocher reste décoché) mais l'erreur continue à être affichée.
[cid:image0...@01CFB096.53A1F660]
Voici le Solution.ck (avec la mémoire du fix disabled ci-dessus):
<?xml version="1.0" encoding="utf-8"?>
<c:Solution xmlns:c="http://invenietis.net/ck-release">
<c:Version>2</c:Version>
<c:Fixes>
<c:Disabled>Assembly 'CK.Releaser' must be signed.</c:Disabled>
</c:Fixes>
<c:Versioning c:Mode="Simple">
<c:Master>
<c:Version c:Major="0" c:Minor="1" c:Patch="0" />
</c:Master>
<c:Develop>
<c:Version c:Major="0" c:Minor="1" c:Patch="0" c:PreRelease="develop" />
</c:Develop>
</c:Versioning>
</c:Solution>
Il y a un xml namespace (pour pouvoir « mélanger » d'autres infos à l'intérieur.
Le Versioning mode « Simple » est celui que nous utilisons : une version centrale pour tous les projets (le SharedAssembyInfo.cs contient alors les deux tags.
[assembly: AssemblyVersion( "4.0.0" )]
[assembly: AssemblyFileVersion( "4.0.0" )]
(Dans le mode « PAS simple », chaque projet pourraient avoir sa propre version... one day may be...)
Vu que je veux plier le problème de CK-Core en tout premier lieu (et, de fait, de tous les projets CiviKey), je considère un git-flow simple avec 2 « outputs » :
- On release des release depuis « master »
- On peut release des pre-release depuis la branche « develop »
- ==> D'où les deux configs simples qui suffisent à initialiser correctement les versions d'assemblies ET les versions de packages NuGet ET la version des ClickOnce.
Normalement, sauf erreur, ça devrait le faire.
La gestion des versions n'est PAS faites encore... juste commencée.
(L'idée est de finaliser toute la configuration dans « develop » et que tout ce qui est nécessaire à la release soit renseigné en avance de phase.)
En revanche, ce qui est fait est la gestion du Strong Naming et de la signature digitale...
Pour le Strong Naming, Le principe est le suivant :
- On travaille dans un projet avec la SharedKey. Celle-ci est toujours la même (731c291b31fb8d27) et publique.
- Quand on veut « sortir » un composant, on substitue cette SharedKey par une Official key (une .snk privé d'Invenietis, InvenietisPrivateKey.snk) : Public Key Token = edfa2f62fc978217
==> Cette clé n'existe QUE sur mon poste actuellement (cf. note ci-dessous).
- La substitution se fait sur tous les assemblies qui sont produits par une Solution et l'IDEE est que
o Les assemblies produits par la Solution QUI SONT SIGNES avec la SharedKey sont resignés avec l'Official key.
o TOUTES les références qui ont un PublicKeyToken de la SharedKey de TOUS les assemblies sont mises à jour avec le public key token de l'Official key.
- Et pouf ça marche nickel. Il y a 2 mondes :
o Celui, publique, unsafe, de la SharedKey.
o Celui, officiel, sécurisé, de l'Official key.
Pour la signature digitale, il suffit d'appeler signtool.exe en lui demandant de faire le boulot (of course, APRES avoir StrongNamifier avec l'Official key) avec le .pfx de verisign (Authenticode)
Note importante :
- Une fuite du InvenietisPrivateKey.snk est PLUS GRAVE qu'une fuite de la clé Authenticode !
o On ne peut pas révoquer un .snk... Il faut RELIVRER TOUT. ABSOLUMENT TOUT.
o Je vous laisse imaginer le boxon le jour où la partie privée de CELLE LA : b77a5c561934e089 est rendue publique... C'est celle de Microsoft !
o Pour info, Mono a un trick dans son noyau pour considérer SA publicKeyToken comme étant la « même » que Microsoft : http://www.mono-project.com/Assemblies_and_the_GAC#Public_Key_Token_Remapping
Pas con !
Concrètement, cela se fait en quelques clics :
[cid:image0...@01CFB09D.FF524710]
C'est celle-là, qu'il faut protéger le plus car, à la différence de l'Autenticode, elle ne peut pas être protéger par un mot de passe !
[cid:image0...@01CFB09D.FF524710]
Un petit trick : en cliquant sur le label « Private .snk file », une fenêtre affiche la PublicKey et son token.
[cid:image0...@01CFB09E.3464B410]
Un clic sur « Replace... » et pouf.
[cid:image0...@01CFB09E.C1413070]
Ensuite, l'authenticode, on choisit le .pfx, on clique sur « Digitally Sign... ». On rentre le password du pfx :
[cid:image0...@01CFB09E.C1413070]
Et pouf again : [cid:image0...@01CFB09E.F7E539F0]
Résultat :
[cid:image0...@01CFB0A0.F88AB6D0]
Voilà...
J'avance sur la gestion des versions (et aussi sur les checks afférents).
Ensuite, il faudra s'attaquer au Packaging (NuGet et ClickOnce).
Pour la CI, tout ce qui est fait ici est évidemment faisable en code pur (CK.Releaser.dll). Seul CKReleaser.exe doit contenir les éléments de GUI (là, il y a peut être du ménage à faire...).
A++
Olivier Spinelli
Gérant
Tél. : 06.20.41.47.14
[signature]
10 rue Mercoeur - 75011 Paris
Tél. : 01.84.16.19.99
www.invenietis.com<http://www.invenietis.com/>
Ci-dessous des captures d'écrans de CKReleaser, nouvel élément de CK (rappel : « Le projet CK contient un ensemble de composants logiciels en .Net d'intérêt général créé par Invenietis et publié sous licence LGPL. CiviKey s'appuie sur ces composants, de même que d'autres projets (Open Source ou non). »).
Le but de la vie de ce truc est d'augmenter la qualité du logiciel ET de simplifier certains aspects, notamment les release...
Sa place est dans un package NuGet de Solution (comme NUnit.Runners).
Cela fait plusieurs choses qui sont disponibles dans un petit menu arborescent à 2 balles.
La première est sur la Home : c'est un vérificateur de Solution folder, avec pour certains problèmes la possibilité de les réparer (fix) automatiquement (mais pas tous, faut pas rêver).
Ce qui est implémenté à date :
- Nommage :
o Le ProjectFileName « XRQ.Toto.csproj » (ce que l'on voit dans VS) est le nom de référence.
o Si l'assembly name n'est pas « XRQ.Toto », c'est TOUJOURS mal (auto fix dispo).
o Si le nom de son de son répertoire n'est pas « /XRQ.Toto » (ou « XRQ.Toto.<<TargetFrameworkIdentifier>> »), c'est mal (pas de fix automatique), sauf s'il est CONTENU dans un projet de test (cf.ci-dessous).
o Si le projet référence nunit.framework, il est considéré comme un assembly de Test. Son nom doit donc se terminer par « .Tests » (pas de fix automatique).
==> Je pense ajouter la contrainte que TOUS les projets « .Tests » doivent se trouver dans un répertoire « Tests » (cas de CK.Core).
==> Et faire que tous les fichiers de NUnit soient dedans au lieu de nous polluer la racine comme aujourd'hui...
o Si le projet est CONTENU dans un assembly de Test (cas des plugins de test par exemple), alors le nom de son répertoire peut être n'importe quoi.
- Vérification de la SharedKey
o La SharedKey.snk existe à la racine. C'est EXACTEMENT LA SharedKey (PublicKeyToken = 731c291b31fb8d27). Si elle manque, ou que ce n'est pas elle, un fix corrige la chose.
o Tout projet qui n'est pas un test ou contenu dans un test doit être signé avec la SharedKey.snk (fix automatique).
ð Les tests peuvent être signés mais ce n'est pas une obligation.
- SharedAssemblyInfo.cs
o Un SharedAssemblyInfo.cs doit exister à la racine (fix automatique).
o Tous les projets doivent le référencer en alias (mais ça c'est pas check encore...)
- CK.Stamp.Fody
o Tout projet autre que « .Tests » doit avoir le package CK.Stamp.Fody (pas de fix automatique).
- Des trucs divers :
o Pas plus d'un .csproj par folder.
o Plusieurs .sln peuvent exister. Pour l'instant, pas de contraintes, mais je pense en ajouter une : ils doivent tous commencer par le nom de la Solution, avec des suffixes éventuelles : CK-Core.sln, CK-Core.Doc.sln, CK-Core.Net40.sln, etc.
A la racine, on retrouve un bon vieux Solution.ck (initialisé automatiquement) qui contient la « mémoire » de CKRelease.
Ce fichier doit être commit.
La page Home à date :
[cid:image0...@01CFB0A0.F88AB6D0]
Après application du fix:
[cid:image0...@01CFB096.53A1F660]
On peut refuser l'application d'un fix. Le refus est mémorisé (la case à cocher reste décoché) mais l'erreur continue à être affichée.
[cid:image0...@01CFB096.53A1F660]
Voici le Solution.ck (avec la mémoire du fix disabled ci-dessus):
<?xml version="1.0" encoding="utf-8"?>
<c:Solution xmlns:c="http://invenietis.net/ck-release">
<c:Version>2</c:Version>
<c:Fixes>
<c:Disabled>Assembly 'CK.Releaser' must be signed.</c:Disabled>
</c:Fixes>
<c:Versioning c:Mode="Simple">
<c:Master>
<c:Version c:Major="0" c:Minor="1" c:Patch="0" />
</c:Master>
<c:Develop>
<c:Version c:Major="0" c:Minor="1" c:Patch="0" c:PreRelease="develop" />
</c:Develop>
</c:Versioning>
</c:Solution>
Il y a un xml namespace (pour pouvoir « mélanger » d'autres infos à l'intérieur.
Le Versioning mode « Simple » est celui que nous utilisons : une version centrale pour tous les projets (le SharedAssembyInfo.cs contient alors les deux tags.
[assembly: AssemblyVersion( "4.0.0" )]
[assembly: AssemblyFileVersion( "4.0.0" )]
(Dans le mode « PAS simple », chaque projet pourraient avoir sa propre version... one day may be...)
Vu que je veux plier le problème de CK-Core en tout premier lieu (et, de fait, de tous les projets CiviKey), je considère un git-flow simple avec 2 « outputs » :
- On release des release depuis « master »
- On peut release des pre-release depuis la branche « develop »
- ==> D'où les deux configs simples qui suffisent à initialiser correctement les versions d'assemblies ET les versions de packages NuGet ET la version des ClickOnce.
Normalement, sauf erreur, ça devrait le faire.
La gestion des versions n'est PAS faites encore... juste commencée.
(L'idée est de finaliser toute la configuration dans « develop » et que tout ce qui est nécessaire à la release soit renseigné en avance de phase.)
En revanche, ce qui est fait est la gestion du Strong Naming et de la signature digitale...
Pour le Strong Naming, Le principe est le suivant :
- On travaille dans un projet avec la SharedKey. Celle-ci est toujours la même (731c291b31fb8d27) et publique.
- Quand on veut « sortir » un composant, on substitue cette SharedKey par une Official key (une .snk privé d'Invenietis, InvenietisPrivateKey.snk) : Public Key Token = edfa2f62fc978217
==> Cette clé n'existe QUE sur mon poste actuellement (cf. note ci-dessous).
- La substitution se fait sur tous les assemblies qui sont produits par une Solution et l'IDEE est que
o Les assemblies produits par la Solution QUI SONT SIGNES avec la SharedKey sont resignés avec l'Official key.
o TOUTES les références qui ont un PublicKeyToken de la SharedKey de TOUS les assemblies sont mises à jour avec le public key token de l'Official key.
- Et pouf ça marche nickel. Il y a 2 mondes :
o Celui, publique, unsafe, de la SharedKey.
o Celui, officiel, sécurisé, de l'Official key.
Pour la signature digitale, il suffit d'appeler signtool.exe en lui demandant de faire le boulot (of course, APRES avoir StrongNamifier avec l'Official key) avec le .pfx de verisign (Authenticode)
Note importante :
- Une fuite du InvenietisPrivateKey.snk est PLUS GRAVE qu'une fuite de la clé Authenticode !
o On ne peut pas révoquer un .snk... Il faut RELIVRER TOUT. ABSOLUMENT TOUT.
o Je vous laisse imaginer le boxon le jour où la partie privée de CELLE LA : b77a5c561934e089 est rendue publique... C'est celle de Microsoft !
o Pour info, Mono a un trick dans son noyau pour considérer SA publicKeyToken comme étant la « même » que Microsoft : http://www.mono-project.com/Assemblies_and_the_GAC#Public_Key_Token_Remapping
Pas con !
Concrètement, cela se fait en quelques clics :
[cid:image0...@01CFB09D.FF524710]
C'est celle-là, qu'il faut protéger le plus car, à la différence de l'Autenticode, elle ne peut pas être protéger par un mot de passe !
[cid:image0...@01CFB09D.FF524710]
Un petit trick : en cliquant sur le label « Private .snk file », une fenêtre affiche la PublicKey et son token.
[cid:image0...@01CFB09E.3464B410]
Un clic sur « Replace... » et pouf.
[cid:image0...@01CFB09E.C1413070]
Ensuite, l'authenticode, on choisit le .pfx, on clique sur « Digitally Sign... ». On rentre le password du pfx :
[cid:image0...@01CFB09E.C1413070]
Et pouf again : [cid:image0...@01CFB09E.F7E539F0]
Résultat :
[cid:image0...@01CFB0A0.F88AB6D0]
Voilà...
J'avance sur la gestion des versions (et aussi sur les checks afférents).
Ensuite, il faudra s'attaquer au Packaging (NuGet et ClickOnce).
Pour la CI, tout ce qui est fait ici est évidemment faisable en code pur (CK.Releaser.dll). Seul CKReleaser.exe doit contenir les éléments de GUI (là, il y a peut être du ménage à faire...).
A++
Olivier Spinelli
Gérant
Tél. : 06.20.41.47.14
[signature]
10 rue Mercoeur - 75011 Paris
Tél. : 01.84.16.19.99
www.invenietis.com<http://www.invenietis.com/>
Reply all
Reply to author
Forward
0 new messages