search

commonsensesoftware / More.Build

Provides more extensions for MSBuild
MIT License
3 stars 2 forks source link

Dependency version numbers do not resolve correctly #5

Closed jeffgaroutte closed 7 years ago

jeffgaroutte commented 7 years ago

Using the basic example project I changed LibraryA the version to[assembly: AssemblyVersion("1.0.*")] and removed [assembly: AssemblyFileVersion("1.0.0.0")] [assembly: AssemblyInformationalVersion( "1.0.0" )] the package generates correctly with the a version based on the build number as expected.

(so the $version$ parameter is correct)

LibraryB's dependency on on LibraryA refers to version 1.0.0. the properties on the command line being passed is '-Properties "configuration=Debug;platform=AnyCPU;librarya=1.0.*"'

commonsensesoftware commented 7 years ago

This happens because Roslyn is used to read the version value. The value is read as a string without any parsing. I happen to know how the * is computed, but I'm not sure that would help. The version number used at compilation time and the value used at package generation time will be, ever so slightly, different. It might be possible extract the value from the assembly in this case, but it would require compilation and extracting the version number from the output assembly.

Is there any reason why you want to use the 1.0.* format for the package version? In general, I don't recommend creating packages with a variable version. The one exception is nightly builds. In addition, the Semantic Version specification states that you should only have the components <Major>.<Minor>.<Patch>. While NuGet will happily create a package that deviates from the specification, it's not recommended.

... so I'm not saying 'no', I'd just like to understand the use case better.

commonsensesoftware commented 7 years ago

It turns out that it wasn't all that difficult to implement. I've added support in the latest package which will honor and translate the use of x.x.*. Thanks for reporting this.

jeffgaroutte commented 7 years ago

Thank you. In my use case, it is part of a nightly build process that runs through a SAST engine, is compiled into 2 different "test" applications and forwarded to 2 separate groups for DAST and QA testing. The process included a series of manual steps to build the packages correctly. This will help complete the automation in the process.

Once the SAST, DAST, & QA processes finish; a separate build process - which generates a proper Semantic version - runs and pushes the packages to a private feed.