Curently version information is stored on many places:
- in each packages.config within project folder
- in project files (reference itself and hintpath)
- in folder names in the packages folder
However, most solutions use the same versions of dependent packages in whole solution and such versioning lowers maintability without giving a real benefit. Many times the same version is even required.
Let me propose a resolution that works even for having multiple versions of a dependent package within solution:
Project files - don't write version in them
packages.config file, example today:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="log4net" version="2.0.0" targetFramework="net40" />
<package id="SharpZipLib" version="0.86.0" targetFramework="net40" />
<package id="SharpZipLibStub" version="0.86.0" targetFramework="net40" />
<package id="Test" version="1.2.3" targetFramework="net40" />
</packages>
Proposal:
packages.config file in project folder:
<?xml version="1.0" encoding="utf-8"?>
<Import Config="pathToSulution\packages\versions.config" \>
<packages>
<package id="log4net" versionRef="log4net" targetFramework="net40" />
<package id="SharpZipLib" versionRef="SharpZipLib" targetFramework="net40" />
<package id="SharpZipLibStub" versionRef="SharpZipLib" targetFramework="net40" />
<package id="Test" versionRef="Test02" targetFramework="net40" />
</packages>
versions.config file in <pathToSulution>\packages\versions.config:
<?xml version="1.0" encoding="utf-8"?>
<versions>
<version id="log4net" version="2.0.0"/>
<version id="SharpZipLib" version="0.86.0"/>
<version id="Test01" version="1.1.1"/>
<version id="Test02" version="1.2.3"/>
</versions>
Proposed structure in packages folder:
packages
--log4net
----vlog4net
------lib
--SharpZipLib
----vSharpZipLib
------lib
--SharpZipLibStub
----vSharpZipLib
------lib
--Test
----vTest01
------lib
----vTest02
------lib
Having that in place means that most updates would be just a change to one versions.config file that contains all versions for whole solution. I could even do most of the updates manually be editing the .xml file (if I know it is safe).
This effectivelly also adds version rules to the solution, it is a good feature for enterprise usage, the example says:
- all projects that use log4net of version vlog4net shares the same version
- all projects that use Test of version vTest02 shares the same version
- SharpZipLib and SharpZipLibStub should be always of the same version
I would expect that when I install a new package in a project using UI it would let me choose if I want to use a version that is in the solution already or create a new version. It could also do heuristic defaults based on if the default installed version would be the same version as an existing one - then default would be to use the existing one (it could still ask me if I really want that).
- in each packages.config within project folder
- in project files (reference itself and hintpath)
- in folder names in the packages folder
However, most solutions use the same versions of dependent packages in whole solution and such versioning lowers maintability without giving a real benefit. Many times the same version is even required.
Let me propose a resolution that works even for having multiple versions of a dependent package within solution:
Project files - don't write version in them
packages.config file, example today:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="log4net" version="2.0.0" targetFramework="net40" />
<package id="SharpZipLib" version="0.86.0" targetFramework="net40" />
<package id="SharpZipLibStub" version="0.86.0" targetFramework="net40" />
<package id="Test" version="1.2.3" targetFramework="net40" />
</packages>
Proposal:
packages.config file in project folder:
<?xml version="1.0" encoding="utf-8"?>
<Import Config="pathToSulution\packages\versions.config" \>
<packages>
<package id="log4net" versionRef="log4net" targetFramework="net40" />
<package id="SharpZipLib" versionRef="SharpZipLib" targetFramework="net40" />
<package id="SharpZipLibStub" versionRef="SharpZipLib" targetFramework="net40" />
<package id="Test" versionRef="Test02" targetFramework="net40" />
</packages>
versions.config file in <pathToSulution>\packages\versions.config:
<?xml version="1.0" encoding="utf-8"?>
<versions>
<version id="log4net" version="2.0.0"/>
<version id="SharpZipLib" version="0.86.0"/>
<version id="Test01" version="1.1.1"/>
<version id="Test02" version="1.2.3"/>
</versions>
Proposed structure in packages folder:
packages
--log4net
----vlog4net
------lib
--SharpZipLib
----vSharpZipLib
------lib
--SharpZipLibStub
----vSharpZipLib
------lib
--Test
----vTest01
------lib
----vTest02
------lib
Having that in place means that most updates would be just a change to one versions.config file that contains all versions for whole solution. I could even do most of the updates manually be editing the .xml file (if I know it is safe).
This effectivelly also adds version rules to the solution, it is a good feature for enterprise usage, the example says:
- all projects that use log4net of version vlog4net shares the same version
- all projects that use Test of version vTest02 shares the same version
- SharpZipLib and SharpZipLibStub should be always of the same version
I would expect that when I install a new package in a project using UI it would let me choose if I want to use a version that is in the solution already or create a new version. It could also do heuristic defaults based on if the default installed version would be the same version as an existing one - then default would be to use the existing one (it could still ask me if I really want that).