Extensions with shared common libraries

When two extensions share the same common dll, and if one of the packages is updated with an update of the common dll, the old dll is still contained in the memory so we cannot determine which one to execute. This can lead to strange behavior.

 

For example if you have shared settings between different extensions with a common library this won´t work.

 

 

• Change the version of the common library.
• Update the package for that specific extension (with the updated common lib - new  assembly version is needed).

Another way of working with extensions are to use one single package.

 

Also note,

When the connect service is restarted (manually or by a recovery action of the platform, for any reason) the service is triggered to go through all the extensions and then fetch all the packages related to the extensions. Since we cannot know which assembly that each extension might be depended on,  we are loading everything from the packages that is related to all existing extension into the app domain (memory). 
The app domain can handle multiple versions of each assembly, but if one assembly exists in several packages it only keeps one of those.

So, if you might have the setup: 

- Extension eX is using package pX where dll (assembly) aX has version vX 
- Extension eY is using package pY where dll (assembly) aX has version vY

The above scenario is working fine as the version differs.

But if you might have the setup:

- Extension eX is using package pX where dll (assembly) aX has version vX 
- Extension eY is using package pY where dll (assembly) aX has version vX (BUT you have slightly changed the functionality, but forgot to change the version number)

In this scenario, the outcome is unsure because of the order of the loading of the packages.

If you change something in your dll's, you need to ALWAYS update the version number before you compile and utilize the new version in your extensions. For instance, NuGet has the same requirements.