Le OutputPath propriété n'est pas définie pour ce projet

Lorsque j'essaie de compiler mon projet de x86 en mode de débogage dans Visual Studio 2008. J'obtiens cette erreur. Quand j'ai regardé le groupe de propriétés du projet qui se plaint, je vois chemin de sortie est réglé.

Ici est la propriété du groupe de la section pour ça .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>

Peut-on jeter la lumière sur cette?

REMARQUE: Lorsque j'ai compilé cette Débogage et le CPU il a travaillé.

Mise à JOUR: Erreur 1 Le OutputPath propriété n'est pas définie pour ce projet. Vérifiez que vous avez spécifié une Configuration valide/Plate-forme de combinaison. Configuration='Debug' Platform='x86'

  • Ok et quelle configuration de la plateforme et utilisez-vous? Debug + x86 ou autre chose?
  • Oui VS gestionnaire de configuration-je choisir debug + x86
  • Quel est le message d'erreur?
  • mise à jour du message d'erreur
  • Il semble correct. Est-il un autre projet de la solution qui peut provoquer l'erreur?
  • vous avez raison c'est un autre projet qui avait un problème. Mais VS plaints au sujet du projet qui est en cours de compilation

InformationsquelleAutor Amzath | 2012-01-31
  1. 156

    Eu exactement le même message d'erreur après l'ajout de la nouvelle configuration via ConfigurationManager dans VisualStudio.

    S'est avéré lors de la "Production" de la configuration a été ajoutée pour l'ensemble de la solution (et de chaque projet) OutputPath élément n'était pas ajouté à csproj fichiers.

    Pour résoudre ce problème, je suis allé à une construction d'onglet de propriétés du projet, changé OutputPath de \bin\Production\ à \bin\Production (supprimé fuite \) et les changements enregistrés. Cela a forcé la création de OutputPath élément dans le fichier csproj de projet et intégré avec succès.

    Sonne comme un glitch pour moi.

    • Belle prise sur cette mercurial erreur. Elle n'aurait jamais deviné qu'une seule barre oblique pourrait faire que le gros de la différence. Avoir une Bonne Réponse badge.
    • Dans mon cas, la construction d'un proj fichier, la différence entre any cpuet anycpu était le problème, mais ton post m'a aidé à voir que.
    • Merci Romain, vous avez sauvé ma journée...si seulement je pouvais upvote votre réponse 100 fois! 🙂
    • Juste rencontré ce en VS 2017 v15.6.6, bacon enregistré, merci!
    • Drake, c'est un problème important lors de l'utilisation de VSTS. En ligne de Visual studio utilise le cpu', tandis que visual studio utilise le anycpy'. Important pour les scripts de compilation.
    • C'est exactement mon problème. Quelle belle réponse! nous devons nous adresser au MS devs sur l'Inde à propos de ce! il hurle "patch!".
    • C'est incroyable que cela résout le problème. Parfois je me demande à propos de la facilité d'utilisation de VS au-delà de "Hello World!" apps!

    InformationsquelleAutor Roman Gudkov
  2. 26

    Vous pouvez voir cette erreur dans VS 2008 si vous avez un projet dans votre solution qui fait référence à une assemblée qui ne peut pas être trouvé. Ce qui pourrait arriver si l'assemblée vient d'un autre projet qui ne fait pas partie de votre solution mais devrait l'être. Dans ce cas, simplement en ajoutant le bon projet à la solution résoudre.

    Vérifier la section Références de chaque projet dans votre solution. Si l'un d'eux a une référence avec un x rouge à côté d'elle, puis il vous avez trouvé votre problème. L'assemblée de référence ne peut pas être trouvé la solution.

    Le message d'erreur est un peu confus, mais je l'ai vu à de nombreuses reprises.

    • Dans mon cas, c'était un "avertissement jaune"
    InformationsquelleAutor dblood
  3. 21

    Si vous utilisez WiX regardez ceci (il y a un bug)
    http://www.cnblogs.com/xixifusigao/archive/2012/03/20/2407651.html

    Parfois de nouvelles configurations de génération ajoutés à la .wixproj fichier plus bas dans le fichier, c'est, séparés de leur frère ou leur sœur config définitions par d'autres sans rapport avec les éléments XML.

    Il suffit de modifier le .wixproj fichier, de sorte que tous les <PropertyGroup> sections qui définissent votre construire des configs sont adjacents l'un à l'autre. (Pour modifier les .wixproj dans VS2013 clic droit sur le projet dans l'Explorateur de solutions, Décharger le projet, faites un nouveau clic droit->Modifier Votreprojet.wixproj. Recharger après l'édition du fichier.)

    • merci, c'fixe pour moi. J'ai eu beaucoup de bizarre le comportement le plus de configurations que j'ai ajoutés au projet. Dès que j'ai nettoyé le fichier de projet tout a bien fonctionné. (Ce bug a été signalé en 2012? génial...)
    InformationsquelleAutor george
  4. 9

    L'erreur indiqué dans visual studio pour le projet (disons A) ne pas avoir de problèmes. Quand j'ai regardé à la fenêtre de sortie pour les construire, ligne par ligne, pour chaque projet, j'ai vu qu'il a été se plaindre à propos d'un autre projet (B) qui a été évoqué lors du montage du projet A. le Projet B ajouté à la solution. Mais il n'avait pas été visée dans le projet, Un projet de référence au lieu de l'assemblée de référence de différents endroits. Cet emplacement contient de l'assemblée qui les a rassemblées pour la Plate-forme AnyCpu. Puis j'ai enlevé la référence d'assembly du projet et ajouté du projet B comme une référence. Il a commencé à établir.
    Pas sûr que la manière dont ce correctif travaillé.

    • Reviendrais sans aucun doute essayer avec \p:Plate-forme="AnyCPU" au lieu de \p:Plate-forme="Any CPU". Qui a travaillé formulaire de moi! Était à la recherche à ce pour les âges!
    • AnyCPU (Sans l'espace) a également travaillé pour moi. Merci Lee.
    • J'ai rencontré l'erreur lors de l'exécution d'un processus de construction sur TFS 2017, après j'ai changé le "Chemin de la solution ou des paquets.config" depuis un .la sln à un .vbproj. Changer BuildPlatform à AnyCPU a fonctionné pour moi aussi. Voir la note à la "Plate-forme" ici: docs.microsoft.com/en-us/vsts/build-release/tasks/build/...
    InformationsquelleAutor Amzath
  5. 9

    J'ai rencontré la même erreur, mais le problème s'est avéré être parce que j'avais créé une nouvelle configuration dans ma solution qui n'existait pas dans les assemblys référencés à partir d'une autre solution.

    Ce problème peut être résolu par l'ouverture de la solution liée et l'ajout de la nouvelle configuration à elle aussi.

    Ce post m'a donné l'idée de vérifier les assemblys référencés après que j'ai déjà confirmé que tous les projets au sein de ma solution a la configuration correcte:

    http://gabrielmagana.com/2010/04/solution-to-the-outputpath-property-is-not-set-for-this-project/

    InformationsquelleAutor B-K
  6. 8

    Ce qui m'est arrivé parce que j'avais déplacé la ligne suivante au début de la .csproj fichier:

      <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets"/>

    Il doit être placé après le PropertyGroups qui définissent votre Configuration|Plate-forme.

    InformationsquelleAutor Philip Atz
  7. 3

    J'ai eu la même erreur, alors j'ai regardé les paramètres du projet et dans la "construction" de la section est de Construire "chemin de sortie" option. Et la valeur est vide. J'ai donc rempli "bin\" valeur une erreur a disparu. Il a résolu mon problème.

    InformationsquelleAutor Lukas Dvorak
  8. 2

    Un autre fou possibilité:
    Si vous suivez un simple contrôle de la source de l'arrangement de la mise Branche\Main, Main, et la Libération uns à côté des autres et de vous en quelque sorte et s'ajoutent un projet existant de la Principale au lieu de la Succursale\Principale (en supposant que votre solution de travail est Branch\Principale), vous pouvez voir cette erreur.

    La solution est simple: référence du droit projet de!

    InformationsquelleAutor Keith Hoffman
  9. 2

    J'ai rencontré ce problème lors de l'ajout d'un projet à une solution de référencement de encore un autre projet dans la même solution,-- et il est devenu l'icône d'avertissement jaune sur la référence, vous remarquerez que le chemin était vide.

    La solution est semblable à ce que @Amzath suggéré, mes projets étaient en cours d'élaboration avec les différentes Cibles des Cadres, par exemple. .NET 4.0 vs 4.5.

    InformationsquelleAutor StuTheDog
  10. 2

    Dans mon cas, le construit de l'adresse de mon application a été fixé à un autre ordinateur était éteint donc je l'ai activée et redémarrez VS et le problème est résolu.

    InformationsquelleAutor Jesus Manuel
  11. 2

    J'ai eu le même problème après j'ai ajouté de nouvelles configurations et supprimé le "debug" et "release" configs.
    Dans mon cas, j'ai été en utilisant un fichier cmd pour exécuter le construire et publier des processus, mais la même erreur a été levée.
    La solution pour moi:
    Dans le fichier csproj suivantes:

    <Configuration Condition=" '$(Configuration)' == '' ">Debug< /Configuration>

    était réglage de la Configuration de "Debug" si je n'indiquez pas explicite. Après la modification de la valeur du nœud de "debug" pour ma configuration personnalisée, tout a fonctionné sans problème. Espérons que cela aidera également celui qui est à la lecture de ceci 🙂

    InformationsquelleAutor MihaiB
  12. 2

    J'ai:

    1. Cliquez-droit sur le projet avec la question -> Décharger le Projet
    2. Cliquez-droit sur le projet et choisissez Edit *.csproj

    3. Copier-coller
      la configuration de la configuration existante, qui travaille avec le nom spécifique et de la plateforme de ciblage (j'ai eu de presse |
      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>
    4. Cliquez-droit sur le projet -> Recharger Projet
    5. Reconstruire projet/solution
    InformationsquelleAutor Janis S.
  13. 1

    Une autre cause: vous ajoutez une référence de projet de projet de projet B dans la solution X. Cependant, la solution de Y qui contient déjà Un projet est aujourd'hui brisé, jusqu'à ce que vous ajoutez également le projet B de solution Y.

    InformationsquelleAutor David White
  14. 1

    J'ai eu le même problème,
    Il suffit d'éditer le .wixproj d'avoir toutes les
    <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... > éléments côte à côte.

    Qui a résolu mon problème

    InformationsquelleAutor Sharon
  15. 1

    Le WiX projet que j'utilisais était dur dans le gestionnaire de configuration pour x64 travers le conseil d'administration. Lors de la réalisation du projet d'Action Personnalisé pour être la solution, il fait défaut tout à x86 dans le .csproj fichier. Donc j'ai déchargé le projet, modifié par la modification de toutes les x86 à x64, enregistré, reloaded, et il était bon d'aller après.

    Je ne comprends pas pourquoi j'ai eu à le faire. Le gestionnaire de configuration a été mis à construire x64, mais juste de ne pas se mettre dans le csproj fichier 🙁

    InformationsquelleAutor kayleeFrye_onDeck
  16. 1

    Si vous obtenez cette erreur uniquement lorsque vous essayez de compiler votre projet à partir de la ligne de commande à l'aide de MSBuild (comme dans mon cas), alors la solution est de passer le outputpath manuellement à MSBuild avec un argument comme /p:OutputPath=MyFolder.

    InformationsquelleAutor anion
  17. 0

    Après avoir essayé toutes les autres suggestions posté ici, j'ai découvert la solution pour moi a été de supprimer la section suivante de la .csproj fichier:

      <ItemGroup>
    <Service Include="{808359B6-6B82-4DF5-91FF-3FCBEEBAD811}" />
  </ItemGroup>

    Apparemment ce service du projet d'origine (non disponible sur la machine locale) a été l'arrêt de l'ensemble du processus de construction, même si elle n'était pas essentielle pour la compilation.

    InformationsquelleAutor Special Sauce