DNN Tracking DLL Dependencies fails when multiple Versions are in Use

Description of bug

Two modules using the same DLL in different versions can easily do so by placing them in a subfolder in the bin and setting the Web.Config rules for version redirects. This works at runtime, but fails on module installs and updates. Here’s a real example where 2sxc and DnnSharp run into a problem (see also the issue on 2sxc:

1. 2sxc uses EF 1.1 and the MS Dependency Injection 1.1 and places all this in bin/2sxc
2. PlantAnApp (DnnSharp) uses EF 2.1 and places all this in bin/PlantAnApp

Because the web.config redirects manage all this, it’s not a problem. But on Module-Install and Upgrade it fails. The reason is that DNN tries to help by tracking installed DLLs, but doesn’t keep track of the folder. So even though the files don’t conflict, DNN checks the DB and assumes a newer version has already been installed (Table: Assemblies):

Note: for historic reasons the EF in 2sxc has the wrong version (it believes it’s EF v11 or 12 because that’s the 2sxc version). This may lead to more confusion, because actually installing 2sxc after PlantAnApp works, but updating PlantAnApp will fail then. But the core problem is that the version ignores the folder it’s in.

Current behavior

This leads to the following problems:

1. If PlantAnApp is installed first, 2sxc with EF v1.1 wouldn’t install, because DNN believes it already has a newer version.
2. If 2sxc with EF 1.1 is installed first, the entry would say v1.1 and Would allow PlantAnApp to install it as well. That would bump the version to 2.1. After that updating 2sxc with a newer EF (say 1.2) would fail, because DNN believes it already has a newer version.

Expected behavior

DLL Versions in Assemblies should include the folder they are in, as the same DLL can be installed in different versions.

Affected version

• All DNN versions as of now up and till v09.09.01

[bdukes]

I just looked at the .dnn file in your latest install package and wanted to respond to the comments 🙂

The File component will report file extensions that are not on the allowed list. However, the ResourceFile component will not. https://github.com/2sic/2sxc/blob/9ba57100fa532aef41ec96a9bb0f347ac89aeb73/Src/Dnn/ToSic.Sxc.Dnn.Main/DnnPackageBuilder/2sic_2SexyContent.dnn#L266-L275

It looks like this is what you’re doing now for pdb files, you could do the same for your bin/2sxc/*.dll files. https://github.com/2sic/2sxc/blob/9ba57100fa532aef41ec96a9bb0f347ac89aeb73/Src/Dnn/ToSic.Sxc.Dnn.Main/DnnPackageBuilder/2sic_2SexyContent.dnn#L286-L293

Regarding PDB files, it looks like you implemented support for pdb files in the Assembly component in DNN 9.1.1. https://github.com/2sic/2sxc/blob/9ba57100fa532aef41ec96a9bb0f347ac89aeb73/Src/Dnn/ToSic.Sxc.Dnn.Main/DnnPackageBuilder/2sic_2SexyContent.dnn#L145-L148

[bdukes]

Using an Assembly component (as opposed to a File component) provides the following features:

• Registers the assembly in the Assemblies table (records what version of an assembly each package installed)
• Creates a binding redirect for strong-named assemblies
• Checks the version of installed assemblies to avoid overwriting newer assemblies with older assemblies

It doesn’t seem to me that any of those features are of use to these assemblies that are installed to an alternate folder. Certainly a well-behaved module should declare their shared assemblies that are going into the bin folder using the Assembly component, but assemblies that you’re managing and that are not shared probably don’t benefit by using the Assembly component.