============================
Assemblies and Probing Paths
============================
.. contents::
:local:
:depth: 3
Elements **appDataDir**, **plugins**, **additionalAssemblyProbingPaths**, and **assemblies** define the assemblies and paths that the **IoC.Configuration** will search to locate the assembles.
.. note::
For more information about plugins refer to section :doc:`./plugins`.
Element: **appDataDir**
=======================
This element specifies the folder, where **IoC.Configuration** saves dynamically generated DLLs. The application should have write permissions to path specified in **appDataDir**.
Example of **appDataDir** in configuration file:
.. code-block:: xml
Element: **plugins**
====================
This element specifies the root folder, where plugin assemblies are, using the attribute **pluginsDirPath**, as well as might have **plugin** child elements to declare plugins (for more information about plugins refer to section :doc:`./plugins`).
The assemblies related to a plugin should be copied to a folder [plugins root folder]/[plugin name], where [plugins root folder] is the value of attribute **pluginsDirPath** of **/iocConfiguration/plugins** element, and [plugin name] is the value of **name** attribute in **/iocConfiguration/plugins/plugin** element.
For example the assemblies for plugin **Plugin1** below should be in folder "**K:\\...\\TestDlls\\PluginDlls\\Plugin1**".
.. code-block:: xml
Here is an example of file structure with plugin folders.
.. image:: plugin-folders.jpg
Element: **additionalAssemblyProbingPaths**
===========================================
This element specifies additional folders that **IoC.Configuration** will use for assembly resolution (this includes resolving assemblies defined in element **assemblies** as well as re-solving assemblies, on which assemblies in **assemblies** elements depend).
Here is an example of **additionalAssemblyProbingPaths** element:
.. code-block:: xml
Element: **assemblies** and **assembly**
========================================
The elements **assemblies** and **assembly** specify all the assemblies that can be used when referencing types in XML configuration file. The assemblies in **assemblies** and their dependencies are resolved by looking up for assemblies in folders specified in elements **plugins**, **additionalAssemblyProbingPaths**, in addition to default folders (e.g., application startup folder, standard folder for **.Net Core** assemblies, etc).
Here is an example of **assemblies** element:
.. code-block:: xml
:linenos:
Attributes in **assembly** element
----------------------------------
- **name**: Specifies the assembly name without the file extension. Example of this attribute value is **IoC.Configuration.Autofac** (see the XML above).
- **alias**: A short unique alias to use, when referencing the assembly in other elements.
Here is an example of element that references the assembly with alias **dynamic1**:
.. code-block:: xml
- **plugin**: An assembly that is in a plugin folder should include this attribute with value specifying the plugin name.
Here is an example of assembly **TestProjects.ModulesForPlugin1** with the value of attribute plugin being **Plugin1**.
.. code-block:: xml
.. note::
There should exist some **plugin** element under element **plugins**, with the value of attribute **name** equal to **Plugin1**.
- **overrideDirectory**: Specifies the directory, where the assembly should be loaded from. Normally this attribute should not be included in element, and the folders specified in elements **plugins**, **additionalAssemblyProbingPaths**, in addition to default folders will be searched to locate tbe assembly.
.. note::
Use this attribute in rare circumstances, to override the default behaviour.
Here is an example of **overrideDirectory** attribute usage.
.. code-block:: xml