You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Java.Interop] $(Version) depends on TargetFramework
Context: 2d5431f
Context: 88d6093
Context: #936
Context: https://github.com/jonpryor/java.interop/commits/jonp-registration-scope
Versioning is hard.
Way back in 3e6a623 we tried to use the `GitInfo` NuGet package so
that *all* assemblies would have a version number which contained the
number of commits since `GitInfo.txt` changed.
This turned out to have unanticipated breakage, and was largely
reverted in 2d5431f for "core" libs like `Java.Interop.dll`.
This still presents a problem, though: the *point* to assembly
versioning is to prevent accidental breaking of referencing
assemblies. If we add a new member to `Java.Interop.dll` but
*fail to update the version*, then that *permits* a scenario in which
an app/lib depends on the new member, but is built against a version
missing that member. This result in runtime exceptions.
The whole reason this hasn't been a problem so far is because
`Java.Interop.dll` has barely changed in *years*. (Plus, most usage
is hidden behind other layers and libs…)
However, *I want this to change*: #936 and
jonpryor/java.interop/jonp-registration-scope both *add* new public
API to `Java.Interop.dll`, and there are other features and
optimizations we're considering that would also require API changes.
A policy of "no changes" isn't tenable.
Thus, the first priority: allow `Java.Interop.dll` built for .NET 6 to
have a different `$(Version)` than the one built for .NET Standard 2.0.
Fixing this was unexpectedly problematic, as commit 88d6093:
> Update[d] `Java.Interop.BootstrapTasks.csproj` to *no longer* `<Import/>`
> `VersionInfo.targets`, as this causes a circular dependency
> (`VersionInfo.targets` uses tasks from
> `Java.Interop.BootstrapTasks.dll`). This is fine, as
> `Java.Interop.BootstrapTasks.dll` doesn't need to be versioned.
`Java.Interop.BootstrapTasks.dll` doesn't need to be versioned, but
*other libraries **do***, and this change change meant that
`VersionInfo.targets` was *never* used, which in turn meant that e.g.
`bin/BuildDebug/Version.props` was never created.
Re-introduce `VersionInfo.targets` by "moving" it into
`build-tools/VersionInfo/VersionInfo.csproj`, and adding
`VersionInfo.csproj` to `Java.Interop.BootstrapTasks.sln`.
This allows the `Prepare` target to create
`bin/Build$(Configuration)/Version.props`.
Next, update `Java.Interop.csproj` so that `$(Version)` is
*conditional* on `$(TargetFramework)`. This allows it to continue
using version 0.1.0.0 for .NET Standard 2.0, and begin using
6.0.0.* for .NET 6+ builds.
Finally -- and most of the "noise" in this commit -- "cleanup and
unify" the disparate build systems. `make prepare all` is one world,
while `dotnet` is a different and overlapping world.
Clean this up: the `dotnet`-based MSBuild environment is now our
Source Of Truth, and the `make` targets are updated to rely on the
`Prepare` target instead of duplicating most of the logic.
While cleaning up `Makefile`, remove other cruft such as the explicit
`gcc` calls to build the `NativeTiming` lib (we have a `.csproj` as
of 5c756b1; use it!), and rationalize
`Java.Runtime.Environment.dll.config` generation.
(test -f test-jni-output/$(notdir $<)&&test -f test-jni-output/Java.Interop.Export-Tests-JniMarshalMethods.dll) || { echo"jnimarshalmethod-gen did not create the expected assemblies in the test-jni-output directory";exit 1; }
0 commit comments