In the scope of CSHARP-3427, we noticed that our `RelativeLibraryLocatorBase` behavior will fail if consumer application uses some special symbols in his path.
This issue is related to `Uri` behavior, for example in the scope of CSHARP-3427 we fixed handling of spaces, but we didn't fix handling of # in the file path.
Possible solutions:
1. Use Fragment field, the solution is implemented here.
2. Use code like this:

 public virtual string GetLibraryBasePath()
        {
#if NETSTANDARD1_5
            var assembly = GetLibraryBaseAssembly();
            var absolutePath = assembly.Location;
#else
            var absolutePath = AppDomain.CurrentDomain.BaseDirectory;
#endif
            return Path.GetDirectoryName(absolutePath);
        }

pay attention that as it was mentioned here it's not recommended to use such approach for web applications.
So any of the above ways should be carefully checked on all supported platforms (web, desktop, mobile), TFs(.net framework, set of .net cores), OSs and we should be able to correctly work with this logic in our driver tests with/without shadow copying