My investigations, which circled the same drain as @alelom in his reply above, have ruled that this information is not easily available using the .NetStandard2.0 libraries within the Rhino context. These may come back as Rhino itself upgrades from .NetFramework in the future (maybe?) and may be available in non-.NetFramework-contexts (such as zero code tools, etc.), but are not currently available for use in BHoM's supported versions of Rhino.
Speaking with @alelom offline, we're of the opinion that these may not be the end of the world, as the property being used is only valid for directories, and is, as the method name suggests, 'extra data' as opposed to core data and is unlikely to be being used in workflows as a primary issue.
As such, I'm raising this PR for review with the aim to merge, and allow others to test/play and raise issues if the loss of this one piece of information is a huge issue or not.
Please be advised that the check with reference 12799733662 has more than 50 annotations of notes. API limitations restrict annotations to 50. You may need to rerun this check to obtain the next set when you make changes. At the time of reporting this check, there are 19 additional annotations waiting, made up of 16 errors and 3 warnings.
@FraserGreenroyd fix requested for project compliance.
The errors with the CSProject (`.csproj`) files have been recorded as annotations on the checks tab.
I will apply the fixes to every case detailed on the checks tab with the exception of any references to the target framework. I am unable to provide fixes to the Target Framework automatically, these will need to be performed manually. If you want to perform the fixes in a different manner please resolve this manually and rerun the check.
If you are happy for me to go ahead and perform this action, please reply with:
> @BHoMBot fix project file ref. `12799733662`
The check `documentation-compliance` has already been run previously and recorded as a successful check. This check has not been run again at this time.
Issues addressed by this PR
Fixes #151
Following the discussion in https://github.com/BHoM/File_Toolkit/pull/152, primarily this reply and this reply, I have spent most of the morning trying to find a way around this issue for file ownership.
My investigations, which circled the same drain as @alelom in his reply above, have ruled that this information is not easily available using the .NetStandard2.0 libraries within the Rhino context. These may come back as Rhino itself upgrades from .NetFramework in the future (maybe?) and may be available in non-.NetFramework-contexts (such as zero code tools, etc.), but are not currently available for use in BHoM's supported versions of Rhino.
Speaking with @alelom offline, we're of the opinion that these may not be the end of the world, as the property being used is only valid for directories, and is, as the method name suggests, 'extra data' as opposed to core data and is unlikely to be being used in workflows as a primary issue.
As such, I'm raising this PR for review with the aim to merge, and allow others to test/play and raise issues if the loss of this one piece of information is a huge issue or not.