2017-10-07 1 views
0

je passais des heures maintenant, mais je ne comprend tout simplement pas:MSBuild, chemin_sortie dans un répertoire lib n'est pas honoré

Pourquoi un lib sous-répertoire non honoré par le VS « rapide mise à jour vérifier"? Si un répertoire de sortie lib pour les bibliothèques est défini, la solution est toujours reconstruite - si les modifications ont été effectuées ou non. Si \ lib sous dir est supprimé, cela fonctionne. Pourquoi?

Voici ce que je l'ai testé à ce jour:

Référez-vous au prochain extrait de code. Celui-là fonctionne parfaitement. Si plusieurs projets dépendants doivent construire plusieurs fois, ils ne construisent réellement qu'une seule fois si aucun changement n'a été fait. Visual Studio FastUpToDateCheck entre en jeu.

Mais si vous changez la ligne

<OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)</OutputPath>

à

<OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)\lib\</OutputPath>

il reconstitue en permanence. Des idées pourquoi?

ComponentBuild.props situé à côté de .sln fichier

<?xml version="1.0" encoding="utf-8"?> 
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 

    <PropertyGroup> 
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> 
    <IntermediateOutputPath>$(SolutionDir)obj\$(Configuration)\$(MSBuildProjectName)\</IntermediateOutputPath> 
    <UseCommonOutputDirectory>False</UseCommonOutputDirectory> 
    <DisableFastUpToDateCheck>false</DisableFastUpToDateCheck> 
    </PropertyGroup> 

    <PropertyGroup Condition=" '$(OutputType)' == 'Library' "> 
    <!-- To distinguish by \lib\ does not work, a rebuild is triggered since the up-to-date check fails --> 
    <!-- <OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)\lib\</OutputPath> --> 
    <OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)</OutputPath> 
    <OutDir>$(OutputPath)</OutDir> 
    </PropertyGroup> 

    <PropertyGroup Condition=" '$(OutputType)' == 'Exe' "> 
    <OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)\</OutputPath> 
    <OutDir>$(OutputPath)</OutDir> 
    </PropertyGroup> 
</Project> 

Le fichier est inclus dans les fichiers csproj juste avant Import Microsoft.CSharp.targets:

fichier .csproj:

<!-- position of include is important, OutputType of project must be defined already --> 
    <Import Project="$(SolutionDir)ComponentBuild.props" Condition="Exists('$(SolutionDir)ComponentBuild.props')" /> 
    <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> 
    <PropertyGroup> 
     <PostBuildEvent> 
     </PostBuildEvent> 
    </PropertyGroup> 

Le comportement devient plus bizarre, plus je teste. J'ai créé deux projets de bibliothèque simples A et B. B dépend de A. J'ai ajouté l'importation mentionnée ci-dessus et les travaux FastUpToDateCheck. Après avoir ajouté le chemin d'accès lib au type de sortie de la bibliothèque, il fonctionne lorsque rien d'autre n'est modifié. Mais quand lib projet B est nettoyé, tous les générations suivantes ne projet de reconstruction B.

Lorsque vous ajoutez chemin lib à l'exe outputtype ainsi. Le FastUpToDateCheck fonctionne à nouveau.

Puis j'ai enlevé le chemin lib nouveau de type de sortie exe, mais le FastUpToDateCheck fonctionne étonnamment encore - toujours. Même lors du nettoyage de la construction, de la modification d'une classe ou de la suppression de tous les dossiers obj et bin.

mais dès que je l'ai enlevé le chemin lib de la lib OutputType ainsi, à savoir I en retrait tout à l'état initial, il échoue. Il reconstruit à chaque fois. La première ligne de la sortie de diagnostic est

Le projet 'ClassLibrary1' n'est pas à jour. Fichier manquant de sortie 'c: \ Users \ hg348 \ Documents \ Visual Studio 2015 \ Projects \ BuildTest \ bin \ Debug \ AnyCPU \ lib \ ClassLibrary1.dll'

Il semble encore dans le chemin lib, même si elle n'est plus défini. Je pense que la mise en cache est mauvaise.

Quelqu'un peut-il s'il vous plaît vérifier?

+0

Impossible de reproduire. La différence clé pour autant que je sache est que vous ajoutez \ lib * only * pour les bibliothèques, alors que le chemin de sortie pour l'exe reste le même. Que se passe-t-il si vous ajoutez aussi \ lib à celui-là? En relation avec cela, une autre configuration dans votre projet que vous ne montrez pas ici pourrait être le coupable. – stijn

+0

Oui, je l'ajoute uniquement aux bibliothèques. Ce que j'ai posté est la configuration complète. Celui-là est importé dans le fichier csproj. Il semble fonctionner avec un seul projet. Avez-vous essayé avec 2 projets où l'un a une référence de projet à l'autre? – Hg347

+0

Après avoir ajouté le chemin lib, n'oubliez pas d'effectuer une modification dans la classe dépendante ou d'effectuer un nettoyage. Sinon, la reconstruction ne peut pas être observée. – Hg347

Répondre

1

Eh bien, mes tests comme décrit ci-dessus mènent à la réponse: Il est en cache dans Visual Studio (VS) qui déclenche les builds après avoir modifié le chemin de sortie. Après avoir apporté des modifications au chemin de sortie et probablement aussi à outdir, Visual Studio recherche toujours FastUpToDateCheck dans l'ancien répertoire.

La fermeture et la réouverture de la solution aident déjà à effacer le cache VS. Dans certains cas, il est nécessaire de supprimer le fichier caché .suo dans le dossier caché .vs Cela résout tous les problèmes indiqués dans l'exemple de fichier donné dans la question ci-dessus.

Mon fichier d'importation finale ressemble à ceci:

<?xml version="1.0" encoding="utf-8"?> 
    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 

     <!-- Note that VS caches settings, to be sure the FastUpToDateCheck works 
       * reopen the solution after 
        - changing properties 
        - after adding a platform config 
        - after adding references to projects 
       * close VS and remove the hidden file 
        <solution folder>\.vs\<solution name>\v14\.suo after changing IntermediateOutputPath, 
        (You have to enable "how hidden files" in windows file explorer) 
       * After updating App.config do a random change in any .cs source file too, 
        otherwise FastUpToDateCheck fails 
     --> 

     <PropertyGroup> 
     <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> 

     <IntermediateOutputPath>$(SolutionDir)obj\$(Configuration)\$(Platform)\$(MSBuildProjectName)\</IntermediateOutputPath> 

     <!-- if true, don't copy output files of referenced assemblies, since everything builds to the same folder. --> 
     <UseCommonOutputDirectory>true</UseCommonOutputDirectory> 
     <DisableFastUpToDateCheck>false</DisableFastUpToDateCheck> 
     </PropertyGroup> 

     <PropertyGroup Condition=" '$(OutputType)' == 'Library' "> 

     <OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)\lib\</OutputPath> 
     <OutDir>$(OutputPath)</OutDir> 
     </PropertyGroup> 

     <PropertyGroup Condition=" '$(OutputType)' == 'Exe' "> 
     <OutputPath>$(SolutionDir)bin\$(Configuration)\$(Platform)\</OutputPath> 
     <OutDir>$(OutputPath)</OutDir> 
     </PropertyGroup> 


     <!-- sets "Copy Local" property of references to false on reopen of solution 
      don't copy output files of referenced assemblies, since everything builds to the same folder --> 
     <ItemDefinitionGroup> 
     <Reference> 
      <Private>False</Private> 
     </Reference> 
     <ProjectReference> 
      <Private>False</Private> 
     </ProjectReference> 
     </ItemDefinitionGroup> 

    </Project> 
+0

Enfin, j'ai trouvé la solution pour le problème de $ (Plate-forme) aussi. Il y a un dossier .vs dans votre dossier de solution. Celui-ci semble mettre en cache les paramètres de propriété comme le IntermediateOutputPath. J'ai fermé VS, supprimé le fichier .suo dans le dossier '.vs \ \ v14 \ .suo' et cela a fonctionné! – Hg347