Le fournisseur 'Microsoft.ACE.OLEDB.12.0' n'est pas enregistré sur la machine locale

J'essaie d'obtenir des données à partir d'un fichier Excel sur un événement de clic de bouton. Ma chaîne de connexion est:

 string connString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\source\\SiteCore65\\Individual-Data.xls;Extended Properties=Excel 8.0;";

Lorsque je clique sur le bouton, je reçois l'erreur suivante:

Le fournisseur «Microsoft.ACE.OLEDB.12.0» n'est pas enregistré sur la machine locale.

Je ne sais pas comment résoudre ce problème. Mon système d'exploitation est Windows 7.

Eh bien, vous devez l'installer. Vous cherchez:

• Le pilote Office System 2007: Composants de connectivité de données .

Une version 64 bits du «Microsoft Access Database Engine 2010 Redistributable» qui vous permettra d'utiliser le fournisseur «Microsoft.ACE.OLEDB.12.0» est disponible ici:
http://www.microsoft.com/en-us/ download / details.aspx? id = 13255

Si vous utilisez le téléchargement à partir de la réponse acceptée, vous devrez créer pour x86, comme indiqué par @ backtestbroker.com.

en fonction de l'application (32 / 64bit) en utilisant la connexion que vous pouvez simplement installer

• Moteurs Access 2007 (32 bits uniquement)
• Access 2010 (32 et 64 bits)
• Accès à l'exécution complète 2013 (32 et 64 bits!> 200 Mo)
• Access 2016 runtime
• Accéder à l'exécution 2019

Sommaire:

• tous les bureaux de 2007 à 2016 contiennent le fournisseur "Microsoft.ACE.Oledb.12.0"
• selon l'architecture de votre application, choisissez le moteur d'exécution approprié (32/64) 6

• vérifiez vos fournisseurs avec la commande powershell du shell 32 et 64 bits :

  (New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION 

• et vous verrez quel fournisseur votre système peut utiliser

la longue histoire: les chaînes peuvent être trouvées avec http://live.sysinternals.com/strings.exe

par exemple. sur un système 64 bits avec des pilotes 32 bits installés

strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE14\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\MSO.DLL" | findstr "ACE.O"

même dans le prochain bureau 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\MSO.DLL
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\MSO.DLL

vous trouverez les cordes

• Microsoft.ACE.OLEDB

• Microsoft.ACE.Oledb.12.0

Office 2013 est également livré avec csi.dll

c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\Csi.dll
c:\Program Files\Common Files\Microsoft Shared\OFFICE15\Csi.dll

qui contient le " Microsoft.ACE.OLEDB.15.0 "

et Office 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\Csi.dll
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\Csi.dll

qui a la version " Microsoft.ACE.OLEDB.16.0 "

La première chose que vous devez vérifier est la configuration de votre application.

• Si vous avez construit votre projet sous la plate - forme x86 , afin de résoudre votre problème, vous devez installer les packages suivants sur votre machine:

  1. Pour utiliser le fournisseur «Microsoft.ACE.OLEDB.12.0», vous devez d'abord installer le moteur de base de données Microsoft Access 2010 redistribuable , cette installation est disponible à l' adresse : http://www.microsoft.com/download/en/details.aspx ? id = 13255 .

     Une fois l'installation terminée, essayez d'exécuter votre application.Si cela résout le problème, sinon, passez à l'étape 2.

  2. Cette prochaine étape est une solution de contournement inexpliquée, qui fonctionne pour Office 2010, même s'il s'agit des composants de connectivité de données d'Office 2007. Je ne sais pas très bien pourquoi cela fonctionne, mais c'est le cas et il a été prouvé que cela fonctionne dans presque tous les cas. Vous devez installer le pilote Office System 2007: composants de connectivité des données , cette installation est disponible à l' adresse : http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .

     Une fois cette installation terminée, essayez d'exécuter votre application, cela devrait résoudre le problème.

• Si vous essayez d'exécuter une application construite sous la plate - forme x64 ou AnyCPU , je recommanderais d'abord de valider qu'elle s'exécute comme prévu sous la plate-forme x86. Dans le cas où il ne s'exécute pas sous cette plate-forme x86, effectuez les étapes de la première partie et validez qu'il s'exécute comme prévu.

  J'ai lu que les pilotes MS Access, y compris le pilote de base de données OLEDB, ne fonctionnent que sous la plate-forme x86 et sont incompatibles sous la plate-forme x64 ou AnyCPU. Mais cela semble être faux. J'ai validé que mon application était en cours d'exécution lors de la construction de x86, puis j'ai installé le moteur de base de données Access à l'aide de l'indicateur passif.

  1. Téléchargez d'abord le fichier localement Vous pouvez télécharger l'installation ici: http://www.microsoft.com/en-us/download/details.aspx?id=13255
  2. Installation à l'aide de l'invite de commande avec l'indicateur «/ passif». Dans l'invite de commandes, exécutez la commande suivante: 'AccessDatabaseEngine_x64.exe / passive'

  Après ces 2 étapes, j'ai réussi à exécuter mon application après la construction en configuration x64 ou AnyCPU. Cela a semblé résoudre mon problème.

Remarque: L'ordre des étapes semble faire une différence, veuillez donc suivre en conséquence.

J'ai obtenu cette erreur / exception dans Visual Studio 2010 lorsque j'ai modifié ma version dans la boîte de dialogue Configuration Manager de «x86» en «Any CPU». Je comprends que ce pilote de base de données OLEDB ne fonctionne qu'en x86 et n'est pas compatible 64 bits. Changer la configuration de build en x86 a résolu le problème pour moi.

J'ai installé les pilotes MS et cela ne fonctionnait toujours pas pour moi. Ensuite, j'ai trouvé ce billet de blog qui a résolu le problème. Lisez-le ici, sinon utilisez ces deux images (liées à ce post) comme résumé TLDR:

Si vous utilisez 64 bits mais que vous rencontrez toujours des problèmes même après avoir installé AccessDatabaseEngine, consultez cet article , cela a résolu le problème pour moi.

c'est-à-dire que vous devez installer ce AccessDatabaseEngine

Pour tous ceux qui en sont encore affectés.

J'ai eu l'erreur ...

OLEDB error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."

... comme décrit par le PO, Shailesh Sahu.

J'ai Windows 7 64 bits.

Mon problème se trouve dans les scripts PowerShell , mais j'utilise une chaîne de connexion, similaire à la publication de l'OP, donc j'espère que mes résultats pourront être appliqués à C #, PowerShell et à tout autre langage reposant sur le pilote "Microsoft.ACE.OLEDB".

J'ai suivi les instructions sur ce fil de discussion MS: http://goo.gl/h73RmI

J'ai d'abord essayé d'installer la version 64 bits , puis d'installer la version 32 bits d'AccessDatabaseEngine.exe à partir de cette page http://www.microsoft.com/en-us/download/details.aspx?id=13255

Mais toujours pas de joie.

J'ai ensuite exécuté le code ci-dessous dans PowerShell (sur le site de SQL Panda http://goo.gl/A3Hu96 )

(New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION 

... qui m'a donné ce résultat (j'ai supprimé d'autres sources de données par souci de concision) ...

SOURCES_NAME              SOURCES_DESCRIPTION                                                                       
------------              -------------------                                                                       
Microsoft.ACE.OLEDB.15.0  Microsoft Office 15.0 Access Database Engine OLE DB Provider

Comme vous pouvez le voir, j'ai Microsoft.ACE.OLEDB. 15 .0 (quinze) pas Microsoft.ACE.OLEDB. 12 .0 (douze)

J'ai donc modifié ma chaîne de connexion à 15 et cela a fonctionné.

Donc, un extrait PowerShell rapide pour montrer comment coder en douceur la version ...

$AceVersion = ((New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | Where-Object { $_.SOURCES_NAME -like "Microsoft.ACE.OLEDB*" } | Sort-Object SOURCES_NAME -Descending | Select-Object -First 1 SOURCES_NAME).SOURCES_NAME

$connString = "Provider=$AceVersion;Data Source=`"$filepath`";Extended Properties=`"Excel 12.0 Xml;HDR=NO`";"

modifié pour choisir la dernière version ACE, si plusieurs

J'espère que quiconque le trouve peut maintenant vérifier quelle version OLEDB est installée et utiliser le numéro de version approprié.

Bien que de nombreuses réponses aient été données, le problème que j'ai rencontré n'a pas encore été mentionné.

• Mon scénario: application 64 bits, Win10-64, Office 2007 32 bits installé.

• L'installation du programme d'installation 32 bits AccessDatabaseEngine.exe téléchargé à partir de MS signale le succès, mais n'est PAS installé, comme vérifié avec le script Powershell de l'une des publications ci-dessus ici.

• L'installation du programme d'installation 64 bits AccessDatabaseEngine_X64.exe a signalé un message d'erreur choquant:

La solution très simple a été trouvée ici sur un site Autodesk. Ajoutez simplement le paramètre / passif à la chaîne de ligne de commande, comme ceci:

AccessDatabaseEngine_X64.exe / passive

Installation réussie, le pilote OleDb a fonctionné.

Les fichiers Excel que je traite avec OleDb sont de type xlsx, produits avec EPPlus 4.5 et modifiés avec Excel 2007.

Vous devez changer la plate-forme de solution de "N'importe quel CPU" en "x86" ou "x64" en fonction du nombre d'installation de bureau.

Les étapes sont données ci-dessous:

1. Cliquez avec le bouton droit sur le fichier de solution dans l'Explorateur de solutions:

   2. Cliquez sur Configuration Manager.

   3. Cliquez sur le menu déroulant de la plate-forme active, si x86 est déjà là, sélectionnez-le, sinon cliquez sur Nouveau.

   4. Sélectionnez x86 ou x64 dans la liste déroulante de la nouvelle plate-forme:

Compilez et exécutez votre application.

Si le "AccessDatabaseEngine" installé n'aide toujours pas, voici la solution:

Vous devez changer la plate-forme de solution active de "N'importe quel CPU" en "x86".

Le fournisseur OLEDB n'est pas enregistré sur la machine locale

De CodeProject.com

J'ai pu résoudre ce problème en suivant les étapes de cet article: http://www.mikesdotnetting.com/article/280/solved-the-microsoft-ace-oledb-12-0-provider-is-not-registered- sur-la-machine-locale

Le point clé pour moi était le suivant:

Lors du débogage avec IIS,

par défaut, Visual Studio utilise la version 32 bits. Vous pouvez modifier cela à partir de Visual Studio en allant dans Outils »Options» Projets et solutions »Projets Web» Général et en choisissant

"Utilisez la version 64 bits d'IIS Express pour les sites Web et les projets"

Après avoir vérifié cette option, puis redéfini la cible de plate-forme de mon projet sur "N'importe quel processeur" (je l'avais définie sur x86 quelque part dans le processus de dépannage), j'ai pu surmonter l'erreur.

Si vous déboguez un projet Web, assurez-vous simplement qu'IIS Express s'exécute en 32 ou 64 bits en fonction des paramètres de votre projet.

Aller à

Outils> Options> Projets et solutions> Projets Web

et à partir de là, vérifiez (ou décochez) la case "Utiliser la version 64 bits d'IIS Express ..."

Vérifiez d'abord quelle version de microsoft.ace.oledb.12.0 est installée sur votre système.

Archiver sous le chemin C: \ Program Files \ Fichiers communs \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL --64 bits est installé

Archivez sous le chemin C: \ Program Files (x86) \ Common Files \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL - le bit x86 est installé

Si (x86) est installé, alors en utilisant le gestionnaire de configuration, changez la plateforme de solution en x86, pour x64 changez en x64.

Si non disponible, installez en utilisant le lien ci-dessous

https://www.microsoft.com/en-us/download/details.aspx?id=23734

syp_dino,

La solution pour moi comme vous l'avez suggéré pour l' erreur "Le fournisseur" Microsoft.ACE.OLEDB.12.0 'n'est pas enregistré sur la machine locale " consiste à remplacer la plate-forme de solution active par" Any CPU "par" x86 ".

Lorsque j'ai effectué ces étapes, reconstruit la solution, saisi l'EXE et placé sur le réseau, tout s'est bien passé sur la machine Windows 7 64 bits.

J'ai eu ce problème lors de la tentative d'importation de données à partir d'un fichier Excel (xlsx) dans une base de données SQL Server à l'aide de SSMS 2014.

L' installation du pilote Office System 2007: composants de connectivité des données a fait l'affaire pour moi.

J'ai fait face à ce même problème. Allez dans les propriétés de la solution et changez n'importe quel CPU en x86, je pense qu'il fera le travail.

faites ces 2 étapes: 1. dans ce menu: projet -> propriétés de votre projet ... -> Build: décochez "préfère 32 bits" 2. dans connectionString: écrivez des cuotes avant et après les propriétés étendues, comme ceci: Propriétés étendues = ' Excel 12.0 Xml; HDR = OUI '

                var fileName = string.Format("{0}", openFileDialog1.FileName);
            //var connectionString = string.Format("Provider=Microsoft.Jet.OLEDB.4.0; data source={0}; Extended Properties=Excel 8.0;", fileName);
            var connectionString = string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0}; Extended Properties='Excel 12.0 Xml;HDR=YES'", fileName);
            var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connectionString);
            var ds = new DataSet();

            adapter.Fill(ds, TableNmae);

            DataTable data = ds.Tables[TableNmae];
            dg1.DataSource = data;

Ces configurations ont fonctionné en janvier 2020 sur ma nouvelle version de machine:

(1 - x64 uniquement) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 installé avec l'argument / passif, les paramètres de génération VStudio définis explicitement sur x64, avec la chaîne de connexion suivante: Provider = Microsoft.ACE.OLEDB.16.0; Source de données = D: ... \ MyDatabase.accdb

(2 - x64 ou x32) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 installé avec l'argument / passif, PLUS AccessDatabaseEngine 2010 (32 bits) installé avec l'argument / passif, les paramètres de génération VStudio définis sur AnyCPU, avec la chaîne de connexion suivante: Provider = Microsoft.ACE.OLEDB.16.0; Source de données = D: ... \ MyDatabase.accdb

(3 - x32 uniquement) Windows 10 x64, Office 365 x32, AccessDatabaseEngine 2010 (32 bits) installé avec l'argument / passif, les paramètres de génération VStudio définis sur x86, avec la chaîne de connexion suivante: Provider = Microsoft.ACE.OLEDB.12.0; Source de données = D: ... \ MyDatabase.accdb

NOTES D'ÉCHEC

L'utilisation du fournisseur ACE.OLEDB.12.0 x64 dans la chaîne de connexion a échoué avec uniquement AccessDatabaseEngine_x64 2016 installé comme ci-dessus dans (1).

L'utilisation d'AnyCPU dans les paramètres de construction de Visual Studio a échoué en (1). Le réglage x64 est requis. C'est peut-être parce que AnyCPU signifie que Vstudio doit voir un fournisseur x32 ACE.OLEDB.nn.0 au moment de la compilation.

Le moteur x32 / passif ACE.OLEDB.12.0 2016 ne s'installera PAS lorsqu'il verra des applications x64 autour. (Le programme d'installation ACE.OLEDB.12.0 2010 x32 / passif a fonctionné.)

CONCLUSIONS

Pour utiliser les paramètres de build x64, vous devez disposer du moteur de base de données x64 2016 ET du fournisseur de chaîne de connexion ACE.OLEDB.16.0 ET des paramètres de build x64 explicites pour fonctionner avec Office 365 en janvier 2020. L'utilisation de l'option / passive facilite les installations. Nous remercions celui qui a publié ce conseil!

Pour utiliser AnyCPU, j'avais besoin d'avoir à la fois le moteur ACE.OLEDB.12.0 2010 x32 et les moteurs ACE.OLEDB.16.0 x64 installés. De cette façon, Vstudio pouvait voir les moteurs x32 et x64 au moment de la compilation "AnyCPU". Je pourrais changer la chaîne de connexion du fournisseur en ACE.OLEDB.12.0 pour un fonctionnement x32 ou en ACE.OLEDB.16.0 pour un fonctionnement x64. Les deux ont bien fonctionné.

Pour utiliser les paramètres de génération x86, vous devez disposer du moteur de base de données 2010 x32 ET du fournisseur de chaînes de connexion ACE.OLEDB.12.0 ET des paramètres de génération x86 explicites pour fonctionner avec Office 365 x32 en janvier 2020.

J'ai un problème similaire lorsque nous lisons un fichier Excel.

Histoire du problème:

Nous avons récemment migré notre application de 32 bits à 64 bits en raison de la mémoire requise. Pour cela, nous avons migré nos fenêtres 7 de 32 bits vers 64 bits. Mais nous avons quand même installé le bureau 32 bits sur nos machines.

à cause de cela, nous avons eu ce problème lors de l'importation de données Excel dans l'application.

Solution,

J'ai téléchargé la version 64 bits de http://www.microsoft.com/en-us/download/details.aspx?id=13255 et installé avec l'argument as,

AccessDatabaseEngine_x64.exe / passive

Sans aucun changement de code, mon problème est résolu.

Remarque:

Sur un système d'exploitation 64 bits et un bureau 64 bits, ma fonctionnalité fonctionnait correctement sans ce correctif. Ce correctif n'est requis que lorsque notre application fonctionne en 64 bits sur un système d'exploitation 64 bits sur lequel Office 32 bits est installé.

Téléchargez et installez simplement le moteur Access DB suivant (X86 ou X64: selon la configuration de votre machine) et voyez la magie :)

https://www.microsoft.com/en-us/download/confirmation.aspx?id=13255

J'ai suivi les instructions des autres; l'installation de ce correctif, l'installation de ce correctif ainsi que le moteur de base de données Microsoft Access 2010.

Mon problème est que j'utilise la même bibliothèque (linq2sql) sur 2 sites sur ma machine; 1 fonctionne et 1 ne fonctionne pas.

Finalement, j'ai trouvé que je devais "activer les applications 32 bits" dans les paramètres avancés de l'apppool pour mon site non fonctionnel.

Tout fonctionne bien maintenant.

peut également essayer ces étapes

Dans SQL Server, 1.Ouvrez une base de données 2.Cliquez dans l'option 'Server Obtect' 3.Cliquez dans 'Linked Servers' 4.Cliquez dans 'Providers' 5.Clic Rigth dans 'Microsoft.ACE.OLEDB.12.0' 6. Décochez toutes les options et fermez

N'oubliez pas d'installer AccessDatabaseEngine sur le serveur pour l'application Web.

J'ai eu le même problème mais dans ce cas, le fournisseur microsoft-ace-oledb-12-0 était déjà installé sur ma machine et fonctionnait bien pour une autre application développée.

La différence entre ces applications et celle avec laquelle j'ai eu le problème était que les anciennes applications s'exécutaient sur " Local IIS " tandis que celle avec erreur était sur " IIS Express (exécutée à partir de Visual Studio"). Donc ce que j'ai fait était-

1. Faites un clic droit sur le nom du projet.
2. Accéder aux propriétés
3. Accédez à l'onglet Web à droite.
4. Sous Serveurs, sélectionnez IIS local et cliquez sur le bouton Créer un répertoire virtuel.
5. Exécutez à nouveau l'application et cela a fonctionné.

J'ai eu le moteur de base de données Microsoft Access 2010 Redistributable déjà installé sur ma machine, mais je recevais toujours l' erreur du fournisseur Microsoft ACE OLEDB .

Ensuite, je me suis rappelé que j'avais récemment effectué une mise à niveau vers Office 2016. Je devrais donc essayer de réinstaller le moteur de base de données Microsoft Access 2010 redistribuable . Et cela a résolu le problème sur ma machine.

Donc, si vous avez mis à niveau vers une version différente de MS Office ou même réparé / réinstallé votre MS Office, essayez de réinstaller Microsoft Access Database Engine 2010 Redistributable avant de perdre du temps à trouver d'autres correctifs. Bonne chance!

1.) Vérifiez votre chaîne de connexion avec ConnectionStrings.com .

2.) Assurez-vous que le bon moteur de base de données est installé. Ce sont les deux moteurs de base de données qui m'ont aidé.

Moteur de base de données Microsoft Access 2010 redistribuable

Pilote Office System 2007: composants de connectivité des données

3.) Il pourrait y avoir un problème avec votre plate-forme cible de génération étant "N'importe quel CPU", il peut être nécessaire d'être "X86" (Propriétés, Build, Plate-forme cible).

Si vous obtenez cette erreur lorsque vous essayez d'utiliser ACE à partir d'une application ASP.NET, la cause la plus probable est que vous avez installé l'une des versions 32 bits. Par défaut, IIS sur un système d'exploitation 64 bits exécutera les applications dans un processus de travail 64 bits. Les processus 64 bits ne peuvent pas charger les DLL 32 bits. Lorsqu'un appel est effectué vers le fournisseur ACE, le processus 64 bits tentera de localiser une DLL 64 bits. S'il n'existe pas, vous obtenez le message d'erreur qui vous a amené ici.

Dans ce cas, vous avez deux options. Tout d'abord, vous pouvez installer la version 64 bits 2010. Si la version 32 bits 2007 est installée, vous pouvez simplement installer la version 64 bits 2010 à côté. Si la version 32 bits de 2010 est installée, vous devez la désinstaller et télécharger et installer la version 64 bits 2010 à la place. Vous ne pouvez pas avoir les versions 32 et 64 bits du fournisseur 2010 installées en même temps. Si vous effectuez l'installation sur votre machine de développement, vous pouvez également être contraint par le bit-ness des installations Office existantes.

La deuxième option consiste à modifier le pool d'applications dans IIS pour activer les applications 32 bits. Si vous utilisez la version complète d'IIS, vous pouvez utiliser l'outil de gestion pour cela (Panneau de configuration »Outils d'administration» Gestionnaire des services Internet (IIS)).

Pour plus de compréhension, veuillez consulter le lien ci - dessous

J'ai reçu cette erreur lors de l'importation de données d'un fichier Excel dans MS-SQL. Le fournisseur était déjà installé (64 bits) et cela m'a surpris pourquoi cela ne fonctionnait pas. Donc, tout ce que j'ai fait, c'est localiser l'application d'importation / exportation utilisée ici, c'est-à-dire le .EXE. Et je l'ai trouvé à

C: \ Program Files \ Microsoft SQL Server \ 130 \ DTS \ Binn \ DTSWizard.exe

J'ai ensuite exécuté le .exe directement pour effectuer l'importation des données. Et ça a marché!

Cela a fonctionné pour moi en ce moment.

1. Visitez cette page puis téléchargez le package approprié pour votre ordinateur (AccessDatabaseEngine.exe ou AccessDatabaseEngine_X64.exe)
2. Installez ça.
3. Enjoye ... Vos codes fonctionnent maintenant ...

Mais pour votre package d'application, vous pouvez utiliser l'une des solutions suivantes:

4. Allez dans "C: \ Program Files (x86) \ Common Files \ microsoft shared" ou "C: \ Program Files \ Common Files \ Microsoft Shared" et placez le répertoire "OFFICE14" au même emplacement que votre fichier de package.

Ou

4. Attachez deux projets (dans l'élément1) dans votre package d'installation.