Comment puis-je déplacer un code commun dans un assemblage externe pour l'utiliser dans des projets Unity 3d?

Question

Le problème: Je dois partager du code entre plusieurs projets dans Unity. Ce code est en constante évolution lors du travail sur les projets. J'ai donc besoin que mon code soit partagé en tant qu'assemblage séparé et inclus dans chaque version d'Unity dans Visual Studio 2015.

La question: comment faire des changements dans l'assemblage commun pour qu'il soit automatiquement mis à jour pour d'autres projets et pour Éditeur de l'unité?

Answer 1

Disons que j'ai ici mon projet commun: c: \ UnityProjects \ DesignPatterns \ et doivent inclure dans mon projet Unity ici: c: \ UnityProjects \ Jeu \

Solution:

1. Déplacer tout le code partagé dans un projet séparé (c: \ UnityProjects \ DesignPatterns)
2. Incluez ce projet dans la solution pour tous vos projets Unity. Cela vous permet d'apporter des modifications une fois que vous en avez besoin sans rouvrir le projet partagé séparément.
3. Tout fonctionne correctement à ce moment, sauf que l'éditeur Unity ne peut pas voir votre assembly externe. Vous devez le copier dans n'importe quel dossier d'actifs dans Unity. Unity le détectera automatiquement et créera un fichier .meta. Créons un dossier pour ceci: c: \ UnityProjects \ Game \ Assets \ ExternalDLLs \

4. Nous ne voulons pas copier l'assemblage récemment construit dans ce répertoire, nous voulons le faire automatiquement. Et la ligne de commande Visual Studio post-build d'événement est là pour vous aider. Faites un clic droit sur le projet CSharp et sélectionnez les propriétés, puis allez à l'onglet Construire des événements et ajoutez la ligne suivante dans la ligne de commande de l'événement post-construction:

   xcopy $ (ProjectDir) .. \ DesignPatterns \ bin \ $ (ConfigurationName) \ DesignPatterns .dll » « $ (ProjectDir) \ actifs \ ExternalDLLs \ DesignPatterns.dll »/ Y

maintenant, chaque fois que nous faisons construire solution cette commande copie notre dll du dossier de sortie du projet partagé dans le dossier de l'actif de notre projet.

Veuillez noter: le projet partagé doit être construit avant votre code d'unité asse Mbly est construit. C'est le cas lorsque vous faites toujours construire une solution. Dans d'autres cas, envisagez de copier l'assemblage à partir du répertoire temporaire de Unity (vous avez des macros pour ce dossier à sélectionner).

Answer 2

Votre solution se trouve dans des sous-modules avec contrôle de version. Vous avez un dépôt pour le projet principal. Ensuite, vous avez un dossier dans lequel est un autre repo. Celui-ci est un sous-module. Il apparaît en gris sur votre repo principal et ne va pas en commit.

https://git-scm.com/book/en/v2/Git-Tools-Submodules

Il fonctionne avec d'autres systèmes de contrôle de version.

Le point de ce modèle est que vous travaillez sur le projet A avec utilitaire-sous-module. utilitaire est un dossier dans le dossier Assets. Ensuite, vous modifiez Utility.cs et appuyez sur Utility repo.

Le projet B utilise utilitaire-sous-module et faire un pull, vos modifications sont là sans altérer le reste du projet B. Évidemment, cela inclut tous les tracas offerts par le contrôle de version, c'est-à-conflits si le projet B a travaillé utilitaire, pauses probables sur d'autres projets si vous changez la mise en œuvre de l'utilité et ainsi de suite (rien d'inhabituel cependant).D'autre part, il est un moyen facile de passer le code commun sur des projets indépendants.