Remove support for the APP_NI_PATHS property

[AaronRobinsonMSFT]

This property is no longer relevant. Remove uses and all testing.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This property is no longer relevant. Remove uses and all testing.

Author:	AaronRobinsonMSFT
Assignees:	-
Labels:	area-Host
Milestone:	7.0.0

[lambdageek]

@AaronRobinsonMSFT Could oyu also delete
https://github.com/dotnet/runtime/blob/main/src/mono/mono/mini/monovm.c#L19
and all references to it. (also, LOL... it never would have worked on Mono since we apparently misspelled the property name as APP_NI_PATH**S**)

[vitek-karas]

@VSadov the refactoring PR #57023 and this will have quite a few conflicts. Just mechanical - FYI.

[AaronRobinsonMSFT]

@lambdageek The title of the issue was wrong, it should have been APP_NI_PATHS :-) That being said, I don't see uses of the stored values in mono's case. Was it never fully integrated?

[lambdageek]

I don't see uses of the stored values in mono's case. Was it never fully integrated?

That's right. There are no supported AOT-on-desktop scenarios for Mono right now, so the property value wasn't relevant.

[AaronRobinsonMSFT]

Please take a look. @lambdageek @elinor-fung @vitek-karas

[vitek-karas]

LGTM

[elinor-fung]

We should also update docs: https://docs.microsoft.com/dotnet/core/dependency-loading/default-probing

[ghost]

Hello @AaronRobinsonMSFT!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[AaronRobinsonMSFT]

Doc update: dotnet/docs#25711

[HJLeee]

@AaronRobinsonMSFT
Hello, could you explain why this is not relevant? APP_NI_PATHS is currently used in Tizen dotnet launcher so I wonder if there is alternative method to this.

cc @alpencolt

[AaronRobinsonMSFT]

could you explain why this is not relevant?

@HJLeee This was a property that was used long ago and had little value from APP_PATHS, other than to be looked in first. Was NI image being used on Tizen? As in, NGen images? Can you share examples of code using this?

I wonder if there is alternative method to this.

I would use APP_PATHS.

[HJLeee]

We are adopting .NET 6 and crossgen2 for the next Tizen release. As crossgen used to generate ni.dll files, we use the same way for .NET 6. Tizen is used for embedded systems, so storage for NI files are not always available. In that case, a system daemon creates or deletes NI files for each application based on use frequency. APP_NI_PATH brings handy management for this. I agree with you APP_NI_PATH brings little value and APP_PATHS is ok for us. I was rather wondering if this PR is a part of other big modifications or policy changes worth breaking backward compatibility.

[AaronRobinsonMSFT]

I was rather wondering if this PR is a part of other big modifications or policy changes worth breaking backward compatibility.

There is nothing specific at present. We are in the midst of removing all remaining CrossGen mentions for .NET 7. This PR is also for .NET 7 and will not impact .NET 6. It would be helpful if you could confirm that using APP_PATHS instead of APP_NI_PATHS doesn't break your scenario.