2009-09-29 9 views
10

Dans VS 2008, existe-t-il un moyen de définir le répertoire intermédiaire (où vont les fichiers .obj, pas les cibles finales) dans un projet C#?Définir le répertoire intermédiaire dans C# Projet

+0

+1 pour une bonne question. J'ai essayé de faire la même chose pour les mêmes raisons (ne pas polluer le répertoire source avec la sortie du compilateur) et j'ai échoué (sans une boîte de dialogue d'avertissement de sécurité - mais ce n'est pas acceptable pour moi). –

+0

Quelqu'un sait si cette situation a changé dans Visual Studio 2010/.NET4 ...? –

Répondre

0

Je ne crois pas. Toutefois, vous pouvez copier vos fichiers exécutables, dll, etc. dans un autre dossier dans un événement post-build. (Onglet Construire des événements dans les propriétés du projet)

6

Vous devez remplacer BaseIntermediateOutputPath msbuild var, plus à ce sujet here.

+1

Cela fonctionne pour la plupart, mais je cherchais un moyen de le définir dans chaque projet afin de construire à partir de l'IDE ne polluerait pas le dossier source. Cependant, définir BaseIntermediateOutputPath dans le projet déclenche un avertissement de sécurité. Hélas, cela ne semble pas possible. soupir... –

+0

L'avertissement de sécurité est là pour vous informer que quelque chose d'inhabituel est arrivé, vous pouvez mettre l'avertissement en sourdine, et vous ne le verrez plus jusqu'à ce que vous changiez quelque chose d'autre. –

+2

Il n'y a rien d'extraordinaire dans la personnalisation de l'emplacement de sortie intermédiaire. Visual Studio accepte volontiers les projets C++ qui personnalisent l'emplacement des fichiers intermédiaires (via la propriété IntDir) sans une boîte de dialogue d'avertissement de sécurité, mais il lance une crise quand la même chose est faite dans le projet C#. –

1

J'ai trouvé une solution à cela en utilisant Visual Studio Express 2013; J'oublie quelle version de VS a introduit MSBuild, et je ne peux pas dire avec certitude que cela fonctionnera pour n'importe quelle autre version. Mais voici:

Dans C:\Windows\Microsoft.NET\Framework sont des sous-répertoires correspondant aux versions .NET; Avec VSX2013 sur mon système le dossier d'intérêt est v4.0.30319. (C'est la version .NET utilisée par MSBuild, pas celle que je vise.) Dans ce dossier sont .targets fichiers, qui sont des collections de règles MSBuild.

Près du début de Microsoft.CSharp.targets sont quelques règles qui importeront plus de fichiers de règles. Le troisième de ces instructions d'importation importe à partir du fichier nommé par la variable de génération CustomBeforeMicrosoftCSharpTargets. Vous pourriez être en mesure de comprendre le nom de ce en lisant les règles, mais il est plus facile d'ajouter une étape de construction personnalisée de

echo $(CustomBeforeMicrosoftCSharpTargets) 

Construire et regarder la sortie. Dans mon cas, le chemin complet était

C:\Program Files (x86)\MSBuild\v12.0\Custom.Before.Microsoft.CSharp.targets 

NOTE: dans mon cas, il y avait déjà un dossier C:\Program Files (x86)\MSBuild\12.0 mais pas v12.0.

donc (en tant qu'administrateur) j'ai créé le dossier et placé un fichier Custom.Before.Microsoft.CSharp.targets qui ressemble à ça:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
     <BaseIntermediateOutputPath>$(SolutionDir)\Build\$(MSBuildProjectName)</BaseIntermediateOutputPath> 
    </PropertyGroup> 
</Project> 

REMARQUE: $(ProjectName) ne fonctionne pas, utilisez $(MSBuildProjectName).

Quand je construit, les OBJs ont été placés dans un répertoire de construction sous la solution, et non pas dans le cadre du projet, dans un sous-répertoire avec la convention de nommage typique: Debug ou Release ou x86\Debug ou x64\Release. Cela ne fonctionnait pas exactement comme souhaité: je voulais vraiment les placer dans %TEMP% mais la variable n'était pas développée, donc j'ai fini avec un dossier de construction sous le projet appelé %TEMP%. Placer le chemin d'accès développé dans la règle a fonctionné correctement, mais d'autres sous-dossiers de %APPDATA% ont échoué en raison de problèmes d'autorisations. Je suppose que cela peut être utilisé pour configurer l'une de ces variables; lire les fichiers .TARGETS par défaut est une corvée, mais il contient quelques commentaires utiles.

+0

Juste une autre note: l'approche ci-dessus fonctionne pour VS CE 2017. 'CustomBeforeMicrosoftCSharpTargets' a une valeur de' C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Communauté \ MSBuild \ v15.0', et encore je a dû créer le dossier 'v15.0'; aucun changement requis pour le XML. –

Questions connexes