System.Addin or "Games with reliable plugins." Part 1
Introduction
Good day. I think the absolute majority of you have been faced with the problem of application extensibility. Likewise, I think that many of you had to dig Reflection to find out if the build is a plug-in for your program. Many did not like the fact that in .NET assemblies are loaded by default into the same domain as the application, and then they could not be unloaded. Many, of course, created objects in separate domains through CreateInstanceAndUnwrap, but all this had to be done by hand. In general, "the mice cried and injected ...". With the advent of System.Addin, developers got their hands on a tool for creating an extensible application that is devoid of these problems, as they say, out of the box. I will also tell about this technology in several articles.
Before we begin - let's deal with the terminology:
Host, Host application is, in fact, an extensible application, which, as a rule, searches for and activates extensions.
Addin. An extension is a module that contains some additional functionality for a host application.
System.Addin features
')
What is System.Addin? This is a new namespace (namespace), which appeared in the .NET Framework 3.5. In essence, System.Addin provides developers with a software model for expanding the functionality of the application. Moreover, the use of this software model provides several key features:
1. The host application and the Addin may have independent versions. Thus, it is possible to build a host application that would work with extension assemblies that were built for previous versions of the application, or for later versions of the application, or that were generally built for another application.
2. The ability to activate Addin with the desired level of isolation and security rights. That is, the System.Addin software model allows you to take care of the security of the application even if the Addin was created by third-party developers. Now no major expansion module will overwhelm your program.
3. Support for multiple levels of isolation extensions from the host application and other extensions. That is, there are several possible scenarios for building isolation at the domain or process level, thereby enhancing the security of the host application.
4. More convenient life management expansion. Since isolation is used at the level of domains or processes, upon completion of work with the plugin, it is sufficient to simply unload the required domain.
Okay. With some opportunities sorted out. Go ahead.
Architecture
The entire architecture of System.Addin is built around such a key concept as the Add-in pipeline (I would translate as an "extension pipeline"). Under this phrase, in fact, everything is hidden. We look at the following picture, all with architecture clarifying:
This is the very Add-in pipeline . Due to all these segments in the pipeline, the required level of abstraction is achieved and isolation is provided. We will analyze in more detail. At the ends of the pipeline we see the host application and the extension itself. These are not the most interesting things, so we will immediately move on to considering what is between them:
1. Contract . As can be seen from the figure, the contract is an interface, the "protocol of interaction" of the host and the extension, and is the point of contact.
2. Next, adapters are created on both sides of the contract (inherit Views), which implement the corresponding view classes (views) and wrap the contract with an interface that provides the view. Also, if you do not combine the Addin view and Host view with one assembly, you can combine the Host and Host view into one assembly. In any case, my advice to you: use a separate assembly for each segment of the pipeline. It will be easier.
3. Well, the third item is the presentation classes (they must be strictly interfaces or inherited classes). They are the appropriate representations of the types and methods that are used in the interaction between the host and the extension.
At this stage, this information is enough for us. It’s enough just to imagine what the Add-in pipeline looks like. In more detail the role of each of the segments of this pipeline, we consider in one of the following articles.
It is also worth noting that the architecture imposes some limitations that we encounter during the creation process:
1. First, each segment of the pipeline ideally is a separate assembly. Views can be combined into a single assembly, but only with the same combination of adapters.
2. Secondly, Addins, adapters and contracts must be public and labeled with special attributes. See picture below:
Required attributes are marked with square brackets. As you can see the presentation from the host side does not require a special attribute.
3. Thirdly, compliance with a rigid folder structure is required, which must be strictly observed for the normal functioning of the pipeline:
* Addins do not necessarily lie next to adapters, views, and contracts. Extensions can be located anywhere.
You may notice that each pipeline segment must be located in its own folder, and the AddInSideAdapters, AddInViews, Contracts and HostSideAdapters folders do not allow the presence of subdirectories in them.
4. Fourthly, since the most typical scenario is with the activation of expansion in a separate domain, when designing you should not forget that the objects crossing the domain boundaries (as parameters or return values) should be serializable.
Like this. No more, no less. At first glance, the architecture and restrictions imposed may seem unnecessarily complex, but in reality this is not the case. I think many of you now imagine what System.Addin is.
That's all.
In the next article, I will show an example demonstrating the use of System.Addin.
Good day. I think the absolute majority of you have been faced with the problem of application extensibility. Likewise, I think that many of you had to dig Reflection to find out if the build is a plug-in for your program. Many did not like the fact that in .NET assemblies are loaded by default into the same domain as the application, and then they could not be unloaded. Many, of course, created objects in separate domains through CreateInstanceAndUnwrap, but all this had to be done by hand. In general, "the mice cried and injected ...". With the advent of System.Addin, developers got their hands on a tool for creating an extensible application that is devoid of these problems, as they say, out of the box. I will also tell about this technology in several articles.
Before we begin - let's deal with the terminology:
Host, Host application is, in fact, an extensible application, which, as a rule, searches for and activates extensions.
Addin. An extension is a module that contains some additional functionality for a host application.
System.Addin features
')
What is System.Addin? This is a new namespace (namespace), which appeared in the .NET Framework 3.5. In essence, System.Addin provides developers with a software model for expanding the functionality of the application. Moreover, the use of this software model provides several key features:
1. The host application and the Addin may have independent versions. Thus, it is possible to build a host application that would work with extension assemblies that were built for previous versions of the application, or for later versions of the application, or that were generally built for another application.
2. The ability to activate Addin with the desired level of isolation and security rights. That is, the System.Addin software model allows you to take care of the security of the application even if the Addin was created by third-party developers. Now no major expansion module will overwhelm your program.
3. Support for multiple levels of isolation extensions from the host application and other extensions. That is, there are several possible scenarios for building isolation at the domain or process level, thereby enhancing the security of the host application.
4. More convenient life management expansion. Since isolation is used at the level of domains or processes, upon completion of work with the plugin, it is sufficient to simply unload the required domain.
Okay. With some opportunities sorted out. Go ahead.
Architecture
The entire architecture of System.Addin is built around such a key concept as the Add-in pipeline (I would translate as an "extension pipeline"). Under this phrase, in fact, everything is hidden. We look at the following picture, all with architecture clarifying:
This is the very Add-in pipeline . Due to all these segments in the pipeline, the required level of abstraction is achieved and isolation is provided. We will analyze in more detail. At the ends of the pipeline we see the host application and the extension itself. These are not the most interesting things, so we will immediately move on to considering what is between them:
1. Contract . As can be seen from the figure, the contract is an interface, the "protocol of interaction" of the host and the extension, and is the point of contact.
2. Next, adapters are created on both sides of the contract (inherit Views), which implement the corresponding view classes (views) and wrap the contract with an interface that provides the view. Also, if you do not combine the Addin view and Host view with one assembly, you can combine the Host and Host view into one assembly. In any case, my advice to you: use a separate assembly for each segment of the pipeline. It will be easier.
3. Well, the third item is the presentation classes (they must be strictly interfaces or inherited classes). They are the appropriate representations of the types and methods that are used in the interaction between the host and the extension.
At this stage, this information is enough for us. It’s enough just to imagine what the Add-in pipeline looks like. In more detail the role of each of the segments of this pipeline, we consider in one of the following articles.
It is also worth noting that the architecture imposes some limitations that we encounter during the creation process:
1. First, each segment of the pipeline ideally is a separate assembly. Views can be combined into a single assembly, but only with the same combination of adapters.
2. Secondly, Addins, adapters and contracts must be public and labeled with special attributes. See picture below:
Required attributes are marked with square brackets. As you can see the presentation from the host side does not require a special attribute.
3. Thirdly, compliance with a rigid folder structure is required, which must be strictly observed for the normal functioning of the pipeline:
* Addins do not necessarily lie next to adapters, views, and contracts. Extensions can be located anywhere.
You may notice that each pipeline segment must be located in its own folder, and the AddInSideAdapters, AddInViews, Contracts and HostSideAdapters folders do not allow the presence of subdirectories in them.
4. Fourthly, since the most typical scenario is with the activation of expansion in a separate domain, when designing you should not forget that the objects crossing the domain boundaries (as parameters or return values) should be serializable.
Like this. No more, no less. At first glance, the architecture and restrictions imposed may seem unnecessarily complex, but in reality this is not the case. I think many of you now imagine what System.Addin is.
That's all.
In the next article, I will show an example demonstrating the use of System.Addin.
Source: https://habr.com/ru/post/54189/
All Articles