Package Create: Less greedy package dependency detection
Currently a package dependency is created if the packaged assembly depends on any dll that another installed package includes, even if it is just some framework dependency inside the Dependencies/ folder. This means the dependency resolution depends on which packages are installed and it is very hard to predict what dependencies will be there.
Instead I suggest that we only include the dependency if the packaged assembly and another package shares a DLL that is not inside the dependencies folder.
The following project illustrates the issue:
The SQLite and PosgreSQL package is installed, but the plugin itself only depends on System.Data.SQLite. However, system.Data.SQLite is a calculated dependency to "SQLite And PosgreSQL" and so, Test1 is calculated to depend on that package. We dont want items from the /dependencies/
folder to affect the package dependency calculation, only dlls that were explicitly included in the package should be used for that. In this concrete case, Test1 should not depend on "SQLite and PostgresQL", since those references are not technically used and instead Test1 should include System.Data.SQLite as a dependency.
<ItemGroup>
<PackageReference Include="OpenTAP" Version="9.7.0" />
<PackageReference Include="System.Data.SQLite" Version="1.0.112" />
<OpenTapPackageReference Include="Demonstration" Version="9.0.2" Repository="packages.opentap.io"/>
<OpenTapPackageReference Include="SQLite and PostgreSQL" Version="9.4.2" Repository="packages.opentap.io"/>
</ItemGroup>
To test the build do something like the following:
C:\Users\romadsen\source\Test1\bin\Release>..\..\..\..\projects\opentap\bin\Debug\tap.exe package create ..\..\package.xml --v
Where the opentap folder includes a debug build of open tap.
The solution is probably fixed the findDependencies method inside OpenTAP.
Note: The easiest way to debug tap package create
is probably by inserting a Debugger.Launch inside the code and then compile+run from the command line.