Comment puis-je obtenir par programme le chemin d'accès à MSBuild à partir d'une machine sur laquelle mon .exe est exécuté?
Je peux obtenir la version .NET à partir de l'environnement, mais existe-t-il un moyen d'obtenir le dossier approprié pour une version .NET?
Vous pouvez également imprimer le chemin de MSBuild.exe sur la ligne de commande:
la source
/reg:32
ou/reg:64
sur les deux bitnessess decmd
(ou tout autre processus que vous exécutez) pour obtenir explicitement ce chemin.Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\4.0\MSBuildToolsPath
Si vous souhaitez utiliser MSBuild pour .Net 4, vous pouvez utiliser la commande PowerShell suivante pour obtenir le chemin de l'exécutable. Si vous voulez la version 2.0 ou 3.5, changez simplement la variable $ dotNetVersion.
Pour exécuter l'exécutable, vous devrez ajouter la variable $ msbuild avec &. Cela exécutera la variable.
la source
$dotNetVersion
12.0 (vs 2013) et 14.0 (vs 2015) (si installé bien sûr)HKLM:\software\Microsoft\MSBuild\ToolsVersions
clé. Au lieu de cela, vous devez obtenir le répertoire d'installation de VS2017HKLM:\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7\15.0
, puis l'ajouterMSBuild\15.0\Bin\MSBuild.exe
pour obtenir l'emplacement MSBuild EXE.Pour les scripts shell cmd dans Windows 7, j'utilise le fragment suivant dans mon fichier de commandes pour trouver MSBuild.exe dans le .NET Framework version 4. Je suppose que la version 4 est présente, mais je ne suppose pas la sous-version. Ce n'est pas totalement à usage général, mais pour les scripts rapides, cela peut être utile:
Pour mes utilisations, je quitte le fichier de commandes avec une erreur si cela n'a pas fonctionné:
la source
set bb.build.msbuild.exe=
? Est-ce nécessaire ou simplement un artefact de votre configuration?Vous pouvez utiliser cette commande PowerShell très d'essai pour obtenir le à
MSBuildToolsPath
partir du registre.PowerShell (à partir du registre)
Production
ou depuis le système de fichiers
PowerShell (à partir du système de fichiers)
Production
la source
Instructions pour trouver MSBuild :
&"${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -prerelease -products * -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -latest -prerelease -products * -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe
Instructions pour trouver VSTest :
&"${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -prerelease -products * -requires Microsoft.VisualStudio.PackageGroup.TestTools.Core -find Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -latest -prerelease -products * -requires Microsoft.VisualStudio.PackageGroup.TestTools.Core -find Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
(Notez que les instructions ci-dessus sont légèrement modifiées par rapport aux instructions officielles de Microsoft. En particulier, j'ai inclus l'
-prerelease
indicateur permettant de récupérer les installations d'aperçu et RC et-products *
de détecter les installations de Visual Studio Build Tools.)Cela n'a pris que deux ans mais finalement en 2019, Microsoft a écouté et nous a donné un moyen de trouver ces exécutables vitaux ! Si vous avez installé Visual Studio 2017 et / ou 2019, l'
vswhere
utilitaire peut être interrogé pour l'emplacement de MSBuild et al. Puisqu'ilvswhere
est toujours situé à%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe
, il n'y a plus d'amorçage ni de codage en dur du chemin.La magie est le
-find
paramètre, ajouté dans la version 2.6.2 . Vous pouvez déterminer la version que vous avez installée en exécutantvswhere
ou en vérifiant ses propriétés de fichier. Si vous avez une version plus ancienne, vous pouvez simplement télécharger la dernière et écraser l'existant%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe
.vswhere.exe
est un exécutable autonome, vous pouvez donc le télécharger et l'exécuter depuis n'importe quel endroit où vous avez une connexion Internet. Cela signifie que vos scripts de construction peuvent vérifier si l'environnement sur lequel ils s'exécutent est correctement configuré, pour ne nommer qu'une option.la source
msbuild
sur la ligne de commande (en particulier la ligne de commande Visual Studio si vous l'utilisez), c'est celle qui sera utilisée. Pour voir ce qui sera utilisé si vous tapezmsbuild
sur la ligne de commande, procédez comme suit:where msbuild
. Si ce n'est pas la même chose que VSWHERE dit que le dernier et le meilleur est, alors vous devez soit faire un chemin complet vers le quemsbuild.exe
vous voulez utiliser, soit apporter des ajustements à vos variables PATH en conséquence.vswhere.exe
et l'utiliser directement.@AllenSanborn a une excellente version PowerShell, mais certaines personnes ont l'obligation d'utiliser uniquement des scripts batch pour les builds.
Ceci est une version appliquée de ce que @ bono8106 a répondu.
msbuildpath.bat
build.bat
Pour Visual Studio 2017 / MSBuild 15, Aziz Atif (le gars qui a écrit Elmah ) a écrit un script batch
https://github.com/linqpadless/LinqPadless/blob/master/build.cmd
la source
Cela fonctionne pour Visual Studio 2015 et 2017:
la source
vswhere -products *
, comme spécifié dans github.com/Microsoft/vswhere/wiki/Find-MSBuild .Les emplacements du registre
donnez l'emplacement de l'exécutable.
Mais si vous avez besoin de l'emplacement où enregistrer les extensions de tâches, c'est sur
la source
Le moyen le plus simple pourrait être d'ouvrir PowerShell et d'entrer
la source
Un one-liner basé sur la réponse de @ dh_cgn :
(Resolve-Path ([io.path]::combine(${env:ProgramFiles(x86)}, 'Microsoft Visual Studio', '*', '*', 'MSBuild', '*' , 'bin' , 'msbuild.exe'))).Path
Il sélectionne tous les chemins de chemins existants, par exemple.
C:\Program Files (x86)\Microsoft Visual Studio\*\*\MSBuild\*\bin\msbuild.exe
.Les étoiles génériques sont:
Sachez que cette commande sélectionne le premier chemin qui correspond à l'expression classée par alphabet. Pour le réduire, remplacez simplement les caractères génériques par des éléments spécifiques, par exemple. l'année ou la version des outils.
la source
Sous Windows 2003 et versions ultérieures, tapez cette commande dans cmd:
Si rien n'apparaît, cela signifie que .NET Framework n'est pas inclus dans le PATH système. Le MSBuild doit être dans le dossier d'installation .NET, avec les compilateurs .NET (vbc.exe, csc.exe)
la source
À partir de MSBuild 2017 (v15), MSBuild est maintenant installé dans un dossier sous chaque version de Visual Studio
Voici quelques exemples où MSBuild.exe se trouve sur ma machine:
la source
Pour récupérer le chemin de msbuild 15 (Visual Studio 2017) avec un lot à partir du registre sans outils supplémentaires:
Meilleurs outils disponibles:
la source
Vous ne pensez pas qu'il y a beaucoup à ajouter ici, mais il est peut-être temps pour une manière unifiée de le faire dans toutes les versions. J'ai combiné l'approche de requête de registre (VS2015 et ci-dessous) avec l'utilisation de vswhere (VS2017 et plus) pour arriver à ceci:
la source
Il existe de nombreuses réponses correctes. Cependant, voici un One-Liner dans PowerShell que j'utilise pour déterminer le chemin MSBuild pour la version la plus récente :
la source
-last 1
(au lieu de-first 1
pour obtenir la dernière version) et concatène également le nom du fichier (pour obtenir correctement le chemin complet et pas seulement le dossier).Cette méthode PowerShell obtient le chemin vers msBuild à partir de plusieurs sources. Essayer dans l'ordre:
Première utilisation de vswhere (car Visual Studio semble avoir des versions plus à jour de msBuild), par exemple
Si non trouvé en essayant le registre (version du framework), par exemple
Code Powershell:
la source
Pour Visual Studio 2017 sans connaître l'édition exacte, vous pouvez l'utiliser dans un script batch:
La commande findstr consiste à ignorer certains exécutables msbuild (dans cet exemple, l'amd64).
la source
ajoutez la branche vswhere pour https://github.com/linqpadless/LinqPadless/blob/master/build.cmd , fonctionne bien sur mon ordinateur, et la branche vswhere fonctionne sur l'ordinateur de mon compagnon. Peut-être que la branche vswhere devrait avancer comme première vérification.
la source
Obtenez la dernière version de MsBuild. Meilleur moyen, pour tous les types d'installation de msbuild, pour différentes architectures de processeur (Power Shell):
la source
Si vous êtes aventureux, vous pouvez également obtenir le code source et la dernière version de MsBuild de GitHub maintenant à https://github.com/Microsoft/msbuild/releases/
la source
Si vous souhaitez compiler un projet Delphi, regardez "ERREUR MSB4040 Il n'y a pas de cible dans le projet" lors de l'utilisation de msbuild + Delphi2009
La bonne réponse est dite: "Il existe un fichier batch appelé rsvars.bat (recherchez-le dans le dossier RAD Studio). Appelez-le avant d'appeler MSBuild, et il configurera les variables d'environnement nécessaires. Assurez-vous que les dossiers sont corrects dans rsvars .bat si vous avez le compilateur dans un emplacement différent de celui par défaut. "
Cette batte mettra non seulement à jour la variable d'environnement PATH dans le dossier .NET approprié avec la version appropriée de MSBuild.exe, mais enregistrera également d'autres variables nécessaires.
la source