Un debugger graphique intégré c’est effectivement sympa la plupart du temps. Jusqu’au jour où tu veux automatiser une session de debugging en combinaison avec git bisect.
Pour appeler le débogueur en dehors de l'IDE, c'est :
Devenv /debugexe ExecutableFile
On peut aussi l'utiliser depuis la ligne de commande pour bien d'autres choses (déployer, builder, ...) :
Je rappelle à toute fin utile que VS est utilisé depuis longtemps pour développer des petits projets méconnus tels que Windows, DirectX, et MS Office.
Donc l'automatisation du déboguage, du déploiement, et tout le reste, existe depuis bien longtemps.
Même si c'est un IDE. L'un n'empêche pas l'autre (au contraire !)
Une chaine de build automagique intégré à l’IDE c’est sympa la plupart du temps. Jusqu’au jour où tu veux automatiser le déploiement sur une instance de recette avec docker.
Cette extension de Microsoft pour intégrer Docker semble le permettre :
Par ailleurs, rien n'est caché. Par exemple quand tu fais du natif, il est trivial de récupérer les options passées aux compilateur et de mettre ça dans un script.
Et quand on fait du .NET, soit (pour les besoins avancés) on peut utiliser l'API du namespace Microsoft.Build, soit :
[^] # Re: VSC
Posté par xcomcmdr . En réponse au journal Le débat est clos. Évalué à -1.
Pour appeler le débogueur en dehors de l'IDE, c'est :
On peut aussi l'utiliser depuis la ligne de commande pour bien d'autres choses (déployer, builder, ...) :
https://docs.microsoft.com/fr-fr/visualstudio/ide/reference/devenv-command-line-switches
Je rappelle à toute fin utile que VS est utilisé depuis longtemps pour développer des petits projets méconnus tels que Windows, DirectX, et MS Office.
Donc l'automatisation du déboguage, du déploiement, et tout le reste, existe depuis bien longtemps.
Même si c'est un IDE. L'un n'empêche pas l'autre (au contraire !)
Cette extension de Microsoft pour intégrer Docker semble le permettre :
https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker
Par ailleurs, rien n'est caché. Par exemple quand tu fais du natif, il est trivial de récupérer les options passées aux compilateur et de mettre ça dans un script.
Et quand on fait du .NET, soit (pour les besoins avancés) on peut utiliser l'API du namespace Microsoft.Build, soit :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)