La propriété OutputPath n'est pas définie pour ce projet.
Lorsque j'essaie de compiler mon projet à partir du mode de débogage x86 dans Visual Studio 2008. Ce message d'erreur s'affiche. Quand j'ai regardé le groupe de propriétés du projet qui s'est plaint, je vois le chemin de sortie est défini.
Voici la section du groupe de propriétés pour ce fichier .csproj
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<BaseAddress>285212672</BaseAddress>
<FileAlignment>4096</FileAlignment>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>Prompt</ErrorReport>
Quelqu'un peut-il nous éclairer?
Remarque: lorsque j'ai compilé ce débogage et n'importe quel processeur cela a fonctionné.
UPDATED: Error 1 La propriété OutputPath n'est pas définie pour ce projet. Veuillez vérifier que vous avez spécifié une combinaison Configuration/Plate-forme valide. Configuration = 'Debug' Platform = 'x86'
L'erreur affichée dans Visual Studio pour le projet (disons A) n'a pas de problèmes. Lorsque j'ai consulté la fenêtre de sortie ligne par ligne de construction pour chaque projet, j'ai constaté qu'il se plaignait d'un autre projet (B) qui avait été référencé sous Assembly dans le projet A. Le projet B ajouté à la solution. Mais il n’avait pas été référencé dans le projet A comme référence de projet mais comme référence d’assemblée à partir d’un autre emplacement. Cet emplacement contient l'assembly qui a été compilé pour Platform AnyCpu. Ensuite, j'ai supprimé la référence Assembly du projet A et ajouté le projet B en tant que référence. Il a commencé à compiler. Je ne sais pas comment ce correctif a fonctionné.
Avait exactement la même erreur après avoir ajouté une nouvelle configuration via ConfigurationManager dans VisualStudio.
Apparu lorsque la configuration 'Production' a été ajoutée pour la solution entière (et chaque projet), élément OutputPath n'était pas ajouté aux fichiers csproj.
Pour résoudre ce problème, je suis allé dans un onglet Générer des propriétés du projet, j'ai changé OutputPath de \bin\Production\ à \bin\Production (\ après l'avoir supprimé) et enregistré les modifications. Cette création forcée de l’élément OutputPath dans le fichier csproj et le projet a été créée avec succès.
Cela ressemble à un petit problème pour moi.
Vous pouvez voir cette erreur dans VS 2008 si votre solution contient un projet faisant référence à un assemblage introuvable. Cela peut se produire si l’Assemblée provient d’un autre projet qui ne fait pas partie de votre solution mais qui devrait l’être. Dans ce cas, il vous suffira d'ajouter le projet correct à la solution.
Consultez la section Références de chaque projet dans votre solution. Si l'un d'entre eux a une référence avec un x rouge à côté, alors vous avez trouvé votre problème. Cette référence à l’Assemblée ne peut être trouvée par la solution.
Le message d'erreur est un peu déroutant mais je l'ai déjà vu plusieurs fois.
Si vous utilisez WiX, regardez ceci (il y a un bogue) http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html
Parfois, les nouvelles configurations de construction sont ajoutées au fichier .wixproj plus loin dans le fichier, c'est-à-dire qu'elles sont séparées de leurs définitions de configuration frères par d'autres éléments XML non liés.
Modifiez simplement le fichier .wixproj de sorte que toutes les sections <PropertyGroup> qui définissent vos configurations de construction soient adjacentes les unes aux autres. (Pour modifier le .wixproj dans VS2013, cliquez avec le bouton droit de la souris sur le projet dans l'Explorateur de solutions, Déchargez le projet, cliquez à nouveau avec le bouton droit de la souris -> Modifier votre projet.
J'ai rencontré la même erreur, mais le problème s'est avéré car j'avais créé une nouvelle configuration dans ma solution qui n'existait pas dans les assemblys référencés d'une autre solution.
Cela peut être résolu en ouvrant la solution associée et en y ajoutant également la nouvelle configuration.
Cet article m'a donné l'idée de vérifier les assemblys référencés après avoir déjà confirmé que la configuration de tous les projets de ma solution était correcte:
http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/
Cela m'est arrivé parce que j'avais déplacé la ligne suivante près du début du fichier .csproj:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>
Il doit être placé après les PropertyGroups qui définissent votre Configuration | Platform.
J'ai eu la même erreur, alors j'ai regardé sur les paramètres du projet et là-bas dans la section "Construction" est l'option "Construire le chemin de sortie". Et la valeur était vide. Donc j'ai rempli "bin \" valeur une erreur a disparu. Cela a résolu mon problème.
J'ai rencontré ce problème lors de l'ajout d'un projet à une solution, puis de son référencement dans un autre projet de la même solution: l'icône d'avertissement jaune sur la référence signalait que le chemin était vide.
La solution était similaire à celle suggérée par @Amzath: mes projets étaient compilés avec différents cadres cibles, par exemple. .NET 4.0 vs 4.5.
Une autre possibilité insensée: Si vous suivez un simple arrangement de contrôle des sources consistant à placer Branch\Main, Main et Release les uns à côté des autres, vous finissez par ajouter un projet existant depuis Main au lieu de Branch\Main est Branch\Main), vous pouvez voir cette erreur.
La solution est simple: référencer le bon projet!
J'ai eu le même problème après avoir ajouté de nouvelles configurations et supprimé les configs "debug" et "release" . Dans mon cas, j'utilisais un fichier cmd pour exécuter le processus de construction et de publication, mais la même erreur a été renvoyée. La solution pour moi: Dans le fichier csproj, ce qui suit:
<Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>
définissait la configuration sur "Debug" si je n’en spécifiais pas explicitement. Après avoir changé la valeur du nœud de "débogage" à ma configuration personnalisée, tout s'est bien déroulé. J'espère que cela aidera aussi celui qui lit ceci :)
Si vous obtenez cette erreur uniquement lorsque vous essayez de compiler votre projet à partir de la ligne de commande en utilisant MSBuild (comme dans mon cas), la solution consiste à transmettre manuellement le chemin de sortie à MSBuild avec un argument tel que /p:OutputPath=MyFolder.
Dans mon cas, l'adresse construite de mon application a été configurée sur un autre ordinateur qui a été désactivé. Je l'ai donc activée et redémarré VS et le problème résolu.
J'ai:
- Faites un clic droit sur le projet avec le problème -> Décharger le projet
- Faites un clic droit sur le projet et choisissez Éditer * .csproj
Copier-coller La configuration de la configuration existante qui fonctionne avec un nom spécifique et une plate-forme de ciblage (j'avais Release | X64 ):
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'"> <OutputPath>bin\x64\Release\</OutputPath> <DefineConstants>TRACE</DefineConstants> <Optimize>true</Optimize> <DebugType>pdbonly</DebugType> <PlatformTarget>x64</PlatformTarget> <ErrorReport>Prompt</ErrorReport> <CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet> <Prefer32Bit>true</Prefer32Bit> </PropertyGroup>- Faites un clic droit sur le projet -> Reload Project
- Reconstruire projet/solution
Une autre cause: vous ajoutez une référence de projet du projet A au projet B dans la solution X. Cependant, la solution Y qui contient déjà le projet A est maintenant interrompue, jusqu'à ce que vous ajoutiez également le projet B à la solution Y
J'ai eu le même problème, Il suffit d'éditer le .wixproj pour que tous les éléments <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > soient côte à côte.
Cela a résolu mon problème
J'ai eu ce problème après avoir ajouté une nouvelle plate-forme à mon projet. Dans mon cas, le fichier .csproj était sous contrôle de source Perforce et était en lecture seule. Je l'ai vérifié, mais VS n'a pas détecté le changement jusqu'à ce que je le redémarre.
Le projet WiX que j'utilisais était paramétrable dans le gestionnaire de configuration pour x64 dans son ensemble. Lors de la création du projet d'action personnalisée pour la solution, le tout a été remplacé par défaut par x86 dans le fichier .csproj. J'ai donc déchargé le projet, l'ai édité en changeant tous les x86 en x64, enregistré, rechargé, et j'étais prêt à partir ensuite.
Je ne comprends pas pourquoi je devais faire ça. Le gestionnaire de configuration était configuré pour générer en tant que x64, mais ne serait tout simplement pas défini dans le fichier csproj :(
avait ce problème en sortie d'Azure DevOps après avoir défini de générer le fichier .csproj au lieu du fichier .sln du pipeline de génération.
La solution pour moi: éditez le fichier .csproj du projet concerné, puis copiez-le en entier
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCpu' ">
Noeud, collez-le, puis modifiez la première ligne comme suit:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|any cpu' ">
La raison en est que dans mon cas l'erreur a été dite
Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='release' Platform='any cpu'.
Pourquoi Azure veut utiliser "n'importe quel cpu" au lieu de la valeur par défaut "AnyCpu" est un mystère pour moi, mais ce hack fonctionne.
Après avoir essayé toutes les autres suggestions publiées ici, j'ai découvert que la solution pour moi consistait à supprimer la section suivante du fichier .csproj:
<ItemGroup>
<Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
</ItemGroup>
Apparemment, ce service du projet original (non disponible sur la machine locale) interrompait tout le processus de construction, même s'il n'était pas essentiel pour la compilation.