Task: Add probing paths for satellite assemblies in ICUResourceBundle

[NightOwl888]

We currently only probe the application directory and the GAC for satellite assemblies. But there are additional probing paths that can be configured, so we need to fix our configuration to check these additional locations.

NOTE: Once #79 is addressed, we will be reading the assembly metadata for the assemblies so they won't need to be loaded. This however, means we won't be taking advantage of the built in probing in .NET by calling Assembly.GetSatelliteAssembly(), so we need to duplicate this logic ourselves and it should be setup to use the same order as .NET Framework and .NET Core. We should also check whether there are any other cases we need to cover for other frameworks, such as ASP.NET Core, MAUI and Mono.

From ChatGPT:

Probing Order for Satellite Assemblies

The documented order for probing satellite assemblies in .NET is governed by specific rules that differ slightly between .NET Framework and .NET Core. Here's the general order of probing used by the runtime when looking for satellite assemblies:

.NET Framework

1. Application Base Directory:
   The runtime first looks in the application's base directory, under a subdirectory named after the culture (e.g., en, fr).
   The expected location for the satellite assembly is:
   <AppBaseDirectory>\<CultureName>\<AssemblyName>.resources.dll

2. Global Assembly Cache (GAC):
   If the satellite assembly is strong-named, the runtime next checks the GAC on Windows to see if the satellite assembly has been installed there.
   In the GAC, satellite assemblies are also stored in culture-specific subdirectories.

3. Probing Paths from Configuration:
   Custom probing paths can be specified in the app.config or web.config file under the <runtime> section. These probing paths can point to additional directories where the runtime should search for assemblies (including satellite assemblies).
   The runtime searches these probing paths in the order they are defined.

4. Codebase Configuration (If Specified):
   If a codeBase element is specified in the app.config for the specific culture, the runtime will attempt to load the satellite assembly from that location.

.NET Core (and .NET 5+)

1. Application Base Directory:
   The first place the runtime looks for satellite assemblies is the application's base directory in a culture-specific subdirectory.
   The expected location for satellite assemblies is:
   <AppBaseDirectory>\<CultureName>\<AssemblyName>.resources.dll

2. Additional Probing Paths:
   Probing paths can be specified in the runtimeconfig.json file or set through runtime options. These paths are typically relative to the base directory or absolute paths.

3. NuGet Package Cache (for Framework-Dependent Apps):
   For framework-dependent .NET Core applications, if the satellite assemblies were deployed through NuGet, the runtime might resolve satellite assemblies from the NuGet package cache.

4. Bundled Assemblies (Self-Contained Apps):
   In self-contained .NET Core applications, satellite assemblies may be bundled within the app and resolved internally. In this case, the runtime doesn't perform disk-based probing, as all assemblies are bundled within the app.

5. Custom Assembly Resolvers:
   The runtime also allows applications to define custom assembly resolvers using AppDomain.AssemblyResolve in .NET Framework or AssemblyLoadContext in .NET Core.

Key Notes:

• Additional Probing Paths:
  In both .NET Framework and .NET Core, additional probing paths can be configured to extend the default search locations, especially in web applications or apps deployed with complex directory structures.

• No Registry Check:
  Unlike some legacy COM-based systems, .NET doesn't probe the registry for assemblies. It only looks in file system paths (e.g., app directory, GAC, custom paths).

Conclusion

To summarize the probing order:

• Application Base Directory
• GAC (Windows/.NET Framework)
• Additional Probing Paths (from config)
• Custom CodeBase or Assembly Resolvers

If you’re developing a class library that needs to check for the existence of satellite assemblies, focusing on the base directory and any additional probing paths (from config files) should be sufficient for most cases.

For web applications, it's common to define custom probing paths, so make sure you account for those. Using AppDomain.BaseDirectory and programmatically parsing configuration files for probing paths will cover these scenarios.