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
is there any automated way to determine which parts of the runtime have changed between releases, when a new (patch for the) .NET runtime is released? For example for .NET 7, what has changed between v7.0.12 and v7.0.13 (I did a quick manual compare between these tags, there only seem to be fairly small changes in the source code. As far as I see it, for example, coreclr.dll on win-x64 should be the same(?))
As far as I understand, the runtime is always released as a whole (all packages for all platforms with all assemblies: the coreclr/gc/jit/... for all platforms, the static libs for all platforms, the base assemblies, most of the tooling). Even if parts did not change, they are still released with new versions (as changed binaries).
Since all the executables/libraries/assemblies always seem get rebuild with new metadata/versions (even the commit hashes in the metadata always seem to differ) ... is there any reliable way to determine which parts actually were changed (which parts had its source code changed)? Or is this published in a way which can be processed in an automated way?
I would like to know which of my applications/deployments would be affected by a new runtime version (especially also for AOT deployments, as these have to be rebuilt).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
is there any automated way to determine which parts of the runtime have changed between releases, when a new (patch for the) .NET runtime is released? For example for .NET 7, what has changed between v7.0.12 and v7.0.13 (I did a quick manual compare between these tags, there only seem to be fairly small changes in the source code. As far as I see it, for example, coreclr.dll on win-x64 should be the same(?))
As far as I understand, the runtime is always released as a whole (all packages for all platforms with all assemblies: the coreclr/gc/jit/... for all platforms, the static libs for all platforms, the base assemblies, most of the tooling). Even if parts did not change, they are still released with new versions (as changed binaries).
Since all the executables/libraries/assemblies always seem get rebuild with new metadata/versions (even the commit hashes in the metadata always seem to differ) ... is there any reliable way to determine which parts actually were changed (which parts had its source code changed)? Or is this published in a way which can be processed in an automated way?
I would like to know which of my applications/deployments would be affected by a new runtime version (especially also for AOT deployments, as these have to be rebuilt).
Thanks for insight.
Beta Was this translation helpful? Give feedback.
All reactions