Je cherche à mettre de l'ordre dans la présentation de mon projet dans Visual Studio et je me demande s'il existe un hack, un plugin ou une astuce pour associer un fichier .xml à un fichier .cs. du même nom pour qu'ils apparaissent groupés dans mon navigateur/explorateur de solutions.
De la même manière que le fichier code-behind est associé à son aspx.
Toute suggestion est la bienvenue. Merci
Dans votre fichier de projet :
<Compile Include="FileA.cs"/>
<Compile Include="FileA.xml">
<DependentUpon>FileA.cs</DependentUpon>
</Compile>Ou vous pouvez utiliser Group Items commande de VSCommandes 2010 extension.
Edit : Juste au cas où votre fichier est dans un dossier, n'incluez pas le nom du dossier dans le champ DependentUpon étiquette. Par exemple, si votre fichier se trouve dans Helpers dossier :
<Compile Include="Helpers\FileA.cs"/>
<Compile Include="Helpers\FileA.xml">
<DependentUpon>FileA.cs</DependentUpon>
</Compile>
J'ai constaté que dans un projet VB VS2010, si vous essayez d'ajouter une classe enfant (par exemple, partiel) à un contrôle XAML, le fichier enfant sera caché à moins que vous choisissez "Show All Files". C'est déroutant, alors il suffit d'ajouter .xaml.vb à la fin du fichier et il s'affiche.
J'étais confus sur la façon d'utiliser la fonction de groupe de commandes VSC jusqu'à ce que je vois ce poste. Pour utiliser la fonction de groupe de VSCommands, mettez en surbrillance TOUS les fichiers que vous voulez grouper, puis faites un clic DROIT sur N'IMPORTE lequel d'entre eux, puis cliquez sur grouper.
Si vous ne souhaitez pas ralentir votre IDE avec une extension VSCommands lourde et propriétaire, vous pouvez utiliser une petite extension NestIn à la place. Il ne peut rien faire d'autre que de grouper/dégrouper des fichiers
@Tohid, votre lien vers le Extension de l'imbrication des fichiers est trop précieux pour être un simple commentaire. Il serait préférable de l'afficher comme une réponse, je suppose.
Pour le cas simple où le fichier est un fichier de "premier niveau", la description de Julien fonctionne parfaitement. Cependant, dans le cas où le fichier DependentUpon est dans un dossier sous le projet, cela semble différent. Personnellement, je n'aime pas cela, car il semble que cela pourrait conduire à une ambiguïté, mais c'est une opinion.
<Compile Include="DataStructs\CKDTree.cs" />
<Compile Include="DataStructs\CClosestObjects.cs" >
<DependentUpon>CKDTree.cs</DependentUpon>
</Compile>Notez que le poste "personne à charge" ne comprend PAS le dossier du parent. Ceci est vrai dans VS2013... probablement vrai dans les versions antérieures mais je ne l'ai pas vérifié.
Merci, le dossier "manquant" est bon à savoir. Je me demandais pourquoi il n'apparaissait pas correctement dans VS2013.
Je pense qu'il n'est pas nécessaire car il part du principe que le fichier "parent" (sans chemin) est un frère du fichier "enfant" et que l'enfant spécifie un chemin. Un test simple consiste à ajouter un deuxième fichier CKDTree.cs à un autre emplacement, puis à créer un enfant à cet autre emplacement, mais avec exactement le même chemin d'accès. DependentUpon confirmerait cette hypothèse. Cependant, comme je l'ai indiqué dans ma réponse ci-dessous, cela casse la capacité de VS à renommer les fichiers, alors méfiez-vous.
Emboîtement de fichiers pour Visual Studio est un bon outil. Elle compte environ 500K téléchargements au moment où j'écris cette réponse. Je l'ai personnellement ajoutée à mon VS 2015 et elle a bien fonctionné (je ne l'ai pas encore essayée avec VS 2017).
Je ne sais pas si les gens sont conscients, mais l'imbrication des fichiers comme cela semble casser la capacité de VS à renommer le fichier racine, au moins lorsque votre nouveau fichier imbriqué est également une classe partielle. Par exemple, voici l'arbre que nous avons créé...
MainWindow.xaml
MainWindow.xaml.cs
MainWindow.Commands.csMainWindow.Commands.cs est simplement une autre classe partielle de MainWindow, tout comme MainWindow.xaml.cs. Cependant, si vous essayez ensuite de renommer MainWindow.xaml, au lieu de renommer automatiquement les fichiers dépendants, une exception est levée.
Pour être complet, j'ai aussi essayé de nommer le fichier MainWindow.xaml.Commands.cs mais ça n'a pas marché non plus.
Sans le fichier supplémentaire 'commands', renommer fonctionne bien, bien sûr.
MainWindow.xaml
MainWindow.xaml.csQuoi qu'il en soit, c'était une raison suffisante pour nous d'abandonner l'imbrication des fichiers de cette manière. Sans la possibilité de renommer, cela n'en vaut pas la peine.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
En rapport : Voir cette réponse pour savoir comment nicher (groupe)
.csdans un projet .NET Core.