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
When creating a ClrRuntime object, the user will often want to keep track of the version of the CLR that the runtime was created for. Because ClrRuntime doesn't expose the CLR version number, it often requires users to keep track of additional data.
It would be useful if ClrRuntime exposed a Version property (of type VersionInfo) that exposed this information directly. Exposing the complete ClrInfo object could be another option, but possibly too heavy-weight.
I looked at this and it does require a few changes in how ClrRuntime objects are created, as these do not contain the necessary information. Either we'd need to obtain it there, or another option would possibly change the ClrRuntime creation process so that you had to pass in the ClrInfo object as well, and not just the DAC location (though this would impact existing code).
This would also make it possible to easily hang interesting extension methods, such as checks for 4.5 or above, and so on (which are often very useful when analyzing code).
The text was updated successfully, but these errors were encountered:
When creating a
ClrRuntime
object, the user will often want to keep track of the version of the CLR that the runtime was created for. BecauseClrRuntime
doesn't expose the CLR version number, it often requires users to keep track of additional data.It would be useful if
ClrRuntime
exposed a Version property (of typeVersionInfo
) that exposed this information directly. Exposing the completeClrInfo
object could be another option, but possibly too heavy-weight.I looked at this and it does require a few changes in how
ClrRuntime
objects are created, as these do not contain the necessary information. Either we'd need to obtain it there, or another option would possibly change theClrRuntime
creation process so that you had to pass in theClrInfo
object as well, and not just the DAC location (though this would impact existing code).This would also make it possible to easily hang interesting extension methods, such as checks for 4.5 or above, and so on (which are often very useful when analyzing code).
The text was updated successfully, but these errors were encountered: