Reprise du message précédent :
Ouais enfin là c'est un gros thread de rageux, honnêtement je pige pas l'intérêt sachant que l'ancien modèle est toujours supporté et n'a pas de décommissionnement prévu.
 
Je comprends qu'on trouve ça moche ou quoi, perso je trouve ça plus lisible et moins verbeux, mais je pige qu'on n'aime pas. Maintenant le thread que tu linkes est ridicule. Suffit de voir, y a 1 mec qui dit "ah perso je trouve ça pas mal" sans attaque ni rien et pan, 36 downvotes.

Je suis d'accord sur le fait que les mecs sont des excités pour certains, genre Mr "Microsoft veut tuer .Net, c'est pour ça qu'ils sortent des features de merde" . Mais ça n'empêche pas que si on va au delà de ceux là, les arguments sont généralement sensés.

C'est "supporté" mais à condition de rajouter à la main ce qui manque ou de créer son propre template : c'est pourri. Ca a plus de sens de laisser le choix comme beaucoup proposent.

La flemme de lire si c'est écrit, mais il y a en plus des limites à cette syntaxe.
 
J'ai galéré pas mal de temps pour comprendre comment refaire des tests d'intégration ASP. En gros pour ceux qui ne sont pas habitués, normalement tu fais ta classe de test qui étend WebApplicationFactory<Startup>. Du coup petite modif en .NET 6 : j’étends WebApplicationFactory<Program>. Sauf que j'avais une erreur cryptique à l'exécution du style "impossible de trouver testhost.deps.json".
 
En fait pour que tout se compile bien et que le runtime ait ce qu'il lui faut, il te faut rajouter en bas de ton Program.cs : public partial class Program { }, ce qui fait un peu verrue pour le coup, ou alors remettre le code flat dans un Main classique...

Toujours à propos de .Net 5/6, depuis ce matin j'ai activé <Nullable>enable</Nullable> dans mon projet du moment.
Sur le principe je suis convaincu de l'utilité de la fonctionnalité que j'espérais depuis longtemps (et d'ailleurs ça m'a permis de débusquer quelques cas limites), mais par contre, qu'est ce que c'est chiant de mettre en conformité un projet existant. Plus je corrige de warnings et plus j'en crée d'autres vu que ça fonctionne en cascade... J'y suis depuis ce matin 10h, et j'ai jamais usé autant les touches ! et ?

 
Quand je veux résoudre un petit truc j'ai souvent cette vidéo qui me vient en tête
https://www.youtube.com/watch?v=1cIX1XaISqg

Je viens de tomber sur cette vidéo : la FMWC, les championnats du monde d'Excel    
https://www.youtube.com/watch?v=ChtiWJmmCwo
 
Excel vu comme un jeu vidéo et faire une compétition de e-sport, fallait y penser !  

   
merci pour cette découverte !

M'sieurs !

Je suis en train de mettre en place un nouveau serveur web dans mon infra, pour remplacer la "vieille" VM sous WS 2012 que j'utilise depuis des lustres.

Au lieu de tenter de migrer la machine d'origine (qui tourne bien, mais dont de nombreux services ne servent plus / ont expiré), j'en profite pour faire un brin de ménage et partir sur une base propre, sous WS 2019 (je n'ai pas de licence plus récente).

Sur cette machine, devront continuer de tourner des applications Microsoft .NET Framework (4.5 à 4.8) et des applications Microsoft .NET Core (3.2 à 6.0), le tout, donc en toute logique, sous IIS 10. Ces applications sont toutes développées par mes associés ou moi-même, avec Visual Studio 2017 à 2022.

Question : maintenant que la plateforme WebPI tire sa révérence et que apparemment IIS / .NET Framework est considéré comme une plateforme "legacy", qu'est-ce que vous suggérez d'utiliser pour l'hébergement et le déploiement de mes applications .NET sachant que :

- nous utilisions jusqu'à maintenant MS Deploy / WebDeploy 3.5
- nous souhaitons rester "on premise" comme ça, à hoster nous même, pas de host cloud pour le moment
- nous n'avons pas énormément de compétence en sysadmin (je sais, c'est contradictoire, mais là n'est pas la question)
- les développeurs poussent les livrables eux-même (via WebDeploy donc)
- il n'y a pas (ou très peu) d'applications lourdes, et pour celles-ci, on fait historiquement avec Clickonce

Merci à vous

Docker

Et mes développeurs peuvent faire sous Visual Studio > clic-droit > publier ?

Je sais pas mais ça doit pas etre compliqué

Ca a pas l'air en effet : https://www.techrepository.in/publi [...] ual-studio
 
L'article date de 2016, si ça se trouve c'est même désormais intégré à VS2019/2022. Ca va nous faire pas mal bricoler nos projets, mais bon, ils sont assez modernes, et on a accès à toutes les sources, ça devrait pas être la mer à boire.
 
Reste plus qu'à me documenter sur la partie serveur (quoi installer / comment configurer côté serveur)

Tu ne peux pas en profiter pour moderniser vos processus de déploiement ? Avec une plateforme de CI-CD ?

Clair. Un gitlab c'est pas bien long à installer, et c'est simple à utiliser pour la CI/CD.

Je me ferai pas chier à installer gitlab perso.  
Il faut juste une machine avec un runner gitlab et son token et basta, le reste ça reste sur la plateforme en saas.

Alors justement, si.
J'ai demandé à des potes dans le métier, et la solution qui revient le plus souvent, c'est effectivement de déléguer cette tâche à un outil de CI/CD.
La plupart est passé sur Git désormais, mais en fouillant un peu, j'ai pu mettre en place la CI (automatique) et la CD (manuelle pour le moment) sur notre Azure DevOps

Va falloir qu'on retravaille un peu l'organisation de notre travail (on a un projet "Projets" dans lequel on a des dossiers par projet, avec des sous-dossiers (branches) Dev/Prod etc). Du coup, pour la CI c'est un peu de la bricole pour que seul le projet qu'on souhaite soit buildé, mais ça fonctionne.
Concernant la CD, j'en ai "un peu" chi* à faire tourner l'agent sur le serveur web (une histoire de domaine vs workgroup, vu que notre Azure DevOps est hosté sur Azure, mais le serveur web est chez nous hors domaine), mais une fois bricolé, ça roule parfaitement.
Pour le moment, j'ai automatisé uniquement la distribution sur un site de démos (daily, à 3h du matin), le temps de checker toutes les options que j'ai (fichiers de config, versionning, base de données etc...).

Les plus d'un tel pipeline :
- le developpeur n'a plus du tout la main sur le processus de livraison : il check-in (on est sous TFS ) et c'est tout. DevOps prend le relais (build, livraison...)
- plus de dépendance de version de framework local entre les développeurs qui pourrait empêcher la build
- plus de Web Deploy, ni de boite noire entre le moment où le deploy est lancé, et l'appli déployée

Les moins :
- quelques incompatibilités remarquées : .NET 6.0 / C# 10 n'est pas encore pris en compte nativement dans le template par défaut. C'est facilement réparable, mais faut le savoir.
- les évents post build ne sont pas tous gérés : la transfo TT n'est pas prise en charge, et mon versionning appli était basé dessus (génération d'un AssemblyInfo.tt -> AssemblyInfo.cs), donc ce projet ne build pas
- ça reste un peu obscur, on ne maîtrise pas la compilation, la génération de la base de données...
- y a un délai (court !), la livraison n'est pas immédiate
- le pipeline est franchement (inutilement) complexe je trouve... entre les pools d'agents, les groupes de déploiement, les releases, les artifacts... on s'y perd assez rapidement, y a pas d'ordre logique des actions à mener, même si ça s'est quand même vachement simplifié depuis 2016. C'est sûrement aussi parce qu'on déploie chez nous, et pas sur Azure, qui doit simplifier la partie déploiement.

J'imagine que sur un environnement Git c'est assez similaire, mais en tout cas ça va simplifier notre boulot, et notre infra (WS + IIS et c'est tout, pas de Docker pour le moment)
De notre côté, on va tranquillement basculer nos projets un par un sur ce système.

Merci pour vos réponses en tout cas

Pour moi, que le dev n'ait plus la main après avoir poussé son code, c'est un moins et pas un plus Ça le dégage de toute responsabilité, ça promeut la com à base de "chez moi ça marche", et c'est contraire à l'esprit DevOps (c'est une philosophie, pas un nom de poste https://en.wikipedia.org/wiki/DevOps ) dans la mesure où ça contribue à renforcer un mur entre les devs et les ops.
 
Quant à la durée du pipeline, celle-ci sera corrélée au temps de build et de tests. Le déploiement c'est rarement ce qui bouffe le plus ; de toute façon, avec un pipeline CI/CD, ce qui t'intéresse c'est la ceinture de sécurité apportée par la normalisation : les binaires sont construits toujours de la même façon, livrés de la même façon par la même personne ou le même outil. C'est pas à l'arrache, t'es sûr que tous les tests sont rejoués avant livraison, bref perso pour rien au monde je ne repartirai sur un modèle avec livraison depuis un PC perso de dev.

Hello
 
J'ai fait la migration, tout fonctionne
J'en ai un peu chi* avec le versionning de mes applis (j'utilisais une transfo TT en pre-build event), mais finalement j'aime bien la solution que Azure propose nativement, donc j'ai basculé sur ça.
 
Petite question bonus à ceux qui utilisent cette façon de bosser  développement de code en local avec Visual Studio > push vers Azure DevOps > attente que la compilation aboutissent sur Azure (gate trigger))
 
En faisant ainsi, je me retrouve avec des changes en local en attente, même une fois le pipeline Azure abouti (build > release > deploy).
Qu'est-ce que je dois en faire dans la best practice ?
 
Si je les re-archive, ils sont tous annulés un par un par résolution auto de conflit (logique, puisqu'ils ont déjà été poussés, buildés et livrés), est-ce ça la bonne façon de faire ?

Pas pigé, ça se passe comment dans ton outil de versioning (Git si je comprends bien) ?
 
Y a 2 workflows possibles : feature branching et trunk based.
 
1) feature branching, tu as une branche principale (souvent nommée main ou master) qui est la référence, qui est celle à partir de quoi tout est buildé/livré, mais sur laquelle aucun contributeur ne peut faire de modif. On doit faire une branche, faire son dev dessus, pousser son dev et sa branche sur le remote (ici Azure DevOps) et faire une Pull Request pour que la branche soit mergée dans main/master (puis supprimée si l'option est choisie). Suite à ça, la branche main/master est buildée et livrée de façon plus ou moins automatique. En local, il te faut alors puller le remote pour récupérer les dernières modifs du repo (main/master à jour, suppression éventuelle de la branche de dev).
 
2) trunk based : tout le monde peut modifier main/master, chaque push vers le remote est pris en compte et buildé automatiquement puis livré.
 
Comment ça se passe pour toi ? Comme tu parles de résolution de conflit, j'ai l'impression que tu ne pulles pas régulièrement la branche sur laquelle tu bosses. Si tu as des changements en local en attente, pourquoi as-tu pushé/intégré ta branche dans la branche principale ?
 
Je te conseille aussi de faire ce tuto sur Git, pour bien en piger le fonctionnement pas toujours évident : https://learngitbranching.js.org/

Ok ouais j'ai un fonctionnement un peu différent.

Déjà pour ma part, je n'utilise pas et n'ai jamais utilisé Git.
Tous mes projets sont hébergés sur dev.azure.com, au pattern TFVC depuis des quelques années.
Auparavant, j'utilisais un serveur TFS 2015 local (j'ai migré pour des raisons de licence, je ne suis plus éligible aux licences étudiant).

Tous mes projets sont organisés de la sorte (côté serveur, dans dev.azure.com donc) :
/$
---/Projets
------/Projet1
---------/Development
---------/Production
------/Projet2
---------/Development
---------/Production
... et ainsi de suite

Les pipelines sont configuré pour :
- aucune action sur les "branches" Development.
- build automatique en cas de check-in sur les "branches" Production
- deploy automatique en cas de réussite du build de la "branche" Production

Sur mon poste de travail, j'utilise Visual Studio (2019 puis 2022, mais bon, osef je pense pour ce sujet), qui est connecté à ce serveur DevOps :

Je ne GetLatest que les "branches" de Development, sur lesquelles je fais mes développements en local, en faisant de temps en temps des check-in sur Development des modifications en attente.
Je ne Get jamais les branches "Production", que je garde comme un checkpoint en cas de nécessité.
Une fois que tout est validé, testé, check-in sur Dev, et prêt à partir en prod : je merge la branche Development sur la branche Production.
-->
Ce qui déclenche les mécanismes du pipeline Azure.

Problème : en faisant ainsi, une fois le pipeline exécuté et l'application déployée, je reste avec des modifications locales en attente sur Production.
Donc soit je les archive à nouveau (auquel cas elles sont toutes refusées dans la résolution auto de conflits).
Soit je les annule (j'ai pas osé, est-ce que ça ne rollback pas aussi côté pipeline ?)

EDIT : Ok bon je viens de voir que sur cet écran, il y a une option pour "Conserver les modifications en attente en local" qui est cochée par défaut.
Je viens d'essayer, en la décochant, ça archive bien, et ça lance le pipeline Azure.
C'était donc ça qui me manquait

C'est dégueulasse surtout
Un projet = Un repo déjà
Ensuite tu dupliques pas ton code en fn de ton environnement
Tu as une source et éventuellement une branch dev pour ton dev (ou comme dit plus haut ça peut être plus compliqué)

 
Je me doutais que c'était un peu tordu comme façon de faire.

Comme dit, il te faut une codebase unique qui est déployée sur des environnements différents, avec une config différente par environnement si besoin (via les librairies de config d'Azure DevOps en faisant du remplacement de variable, par exemple).

D'ac, je vais réorganiser ça proprement.
 
Donc, si je suis la logique, je pars de ça (situation actuelle) :
/$
---/Projets
------/Projet1
---------/Development
---------/Production
------/Projet2
---------/Development
---------/Production
... et ainsi de suite
 
... pour arriver à quelque chose comme ça :
/$
---/Projet1
------/Main
---/Projet2
------/Main
... et ainsi de suite
 
C'est bien ça ?
Je ne comprends pas, du coup, comment je distingue mes branches ?
Je plugge le pipeline Azure directement sur Main ?

Tu distingues tes branches avec ton outil de versioning. Tu lui dis "utilise la branche machin" et tes fichiers se transforment en ceux qui sont sur la branche machin.

Et oui, tu branches ton pipeline Azure sur ta branche de référence. Tu fais en sorte que ça builde et livre main quand main est modifiée.

EDIT : et tu fais un repository par projet, tu mets pas tout dans le même, sinon c'est le bordel. Documente-toi sur comment utiliser un outil de versioning sérieux, comment on fait des branches, etc...

Bof pour le repo / projet. Les monorepos ça marche bien aussi, cf. Google.

Par contre dib91 va falloir abandonner TFS et passer à Git, c'est quand même la reco MS. Et au passage au delà des principes de base (branches, remotes, merge vs rebase etc), bien étudier les façons de travailler / workflows (Git flow / trunk based comme cités, qui sont les plus célèbres). Ça t'évitera bien des galères de merge.

Tes projets ils ont des liens entre eux ou pas du tout ?

Il connaît à peine le principe des branches, de Git, des pipelines Azure, etc... on est pas chez Google, on parle d'un gars avec ses projets persos On démarre simple, et quand on en sera à causer monorepo, on y viendra.

 
Le monorepo, ça marche bien surtout avec Piper, pas avec Git (Android est pas en monorepo par exemple, et utilise Git)

Ok, merci les gars. Je vais me renseigner

bonjour
 
depuis une nouvelle install de vs2022 j'ai toujours la fenetre diagnostic qui se lance au premier debug de la journée, même si je la ferme direct, on dirait qu'elle n'est pas sauvée dans le layout
 
ya que moi ?

Pas chez moi en tout cas.

fichtre

Je ne garantie pas que ça fonctionne. Modifier cette option quand une solution est déjà ouverte ne s'applique en théorie qu'à la solution actuelle (via le fichier .suo). Tu peux essayer de modifier cette option avant d'avoir ouvert une solution (puis redémarrer VS)

Bonjour, avant de réinventer la roue, existe-il déjà des moyens simples pour enregistrer l'historique d'une base de donnée ?
 
Par exemple avec EntityFrameworkCore si on a  
 

 
Peut-il par exemple créer automatiquement  
 

 
Et qu'à chaque sauvegarde d'addition, modification ou suppression dans Person cela enregistre aussi dans PersonHistory avec la date.  
 
   

 
Ce que tu veux c'est un système d'audit trail... ça n'existe pas de base (ce serait trop beau ) mais voici un article comment l'implémenter en EFCore :
 
https://codewithmukesh.com/blog/aud [...] pnet-core/
 
 
 
A noter que cette implémentation est moins souple que celles utilisées habituellement à base de trigger dans la BDD car là, tu n'audites QUE ce qui passe dans ton app .NET core et pas ce qui viendrait de l'extérieur.
 

Si tu veux faire ça a la main, avec l'Ef Core ça doit être assez simple de surcharger les méthodes de sauvegarde et d'aller voir ce qui traine dans le ChangeTracker pour alimenter ton historique.
 
Mais je te conseille plutôt de regarder du côté des Temporal Tables, qui sont faites pour ça.
 
Ou regarde les fonctions d'Audit dans des librairies comme EF Core Plus.
 

En même temps, seulement une seule app est censé avoir accès en écriture à un repo de données quel qu'il soit, sans quoi il faut l'abstraire.

 
Les temporal Tables, j'y pensais plus depuis que je suis obligé de me coltiner des vieux SQL 2012/2014    
 
C'est effectivement la meilleure solution native