2010-11-24 2 views
4

Je dispose d'un fichier de solution .sln qui fait référence à un fichier de projet .csproj qui a une composition après la tâche de quelque chose comme:

<PropertyGroup> 
    <PostBuildEvent> 
     xcopy $(SolutionDir)\dir1\Somefle.xml $(ProjectDir) /Y /I 
    </PostBuildEvent> 
</PropertyGroup> 

la solution est construite en utilisant msbuild une tâche comme ce qui suit:

<Target Name="CompileSolution"> 
    <MSBuild Projects="@(SolutionToBuild)" Targets="Rebuild" Properties="Platform=Any CPU" /> 
</Target> 

maintenant, voici la partie étrange:

Si I:

  1. exécuter le script de construction (par exemple c: \ MyWorkingCopy)
  2. Renommez le dossier de copie de travail (dire à c: \ YourWorkingCopy)
  3. exécuter le script rebâtis

À l'étape 3, la xcopy échouera, car il essaiera de copier le fichier à partir de "c: \ MyWorkingCopy" - ce qui bien sûr n'est pas le cas où le fichier de solution réside maintenant.

Pourquoi msbuild utilise-t-il l'ancien répertoire Solution? Et y a-t-il un moyen de le réinitialiser?

(j'utilise .NET Framework 3.5)

+0

Renommez-vous votre nom de dossier de copie de travail quelque part pendant l'exécution de msbuild? Ou j'ai raté quelque chose? –

+0

peut-être msbuild crée un fichier cache que vous devez supprimer? – stijn

+0

Non, msbuild ne crée aucun fichier cache avec des propriétés. Mais tu n'as pas répondu. Courez-vous msbuild une ou deux fois dans votre scénario? –

Répondre

2

Il peut être lié au fichier sln.cache qui est créé par msbuild lorsque vous créez un fichier sln (c'est un fichier proj temporaire construit à partir d'une SLN) , s'il est présent ou si le sln n'est pas modifié, le fichier sln.cache peut être utilisé ... Je ne sais pas vraiment mais je pense que ça pourrait aider.

+0

les fichiers sln.cache étaient effectivement en train de traîner après la construction initiale. – Nathan

Questions connexes