Мне нужно загрузить файл схемы XML, чтобы проверить некоторую информацию о API .Net Core 2.1, который находится на сервере Linux.К сожалению, у меня нет доступа к этому серверу (мы используем jenkins для развертывания, поэтому у меня 0 контактов с ним), поэтому я могу тестировать только на своем компьютере, который является Windows 10.
Я пробовал следующее:
System.AppContext.BaseDirectory
System.AppContext.BaseDirectory.Substring(0, AppContext.BaseDirectory.IndexOf("bin"));
AppDomain.CurrentDomain.BaseDirectory
Directory.GetCurrentDirectory()
GetType().Assembly.Location
System.Reflection.Assembly.GetExecutingAssembly().Location
System.Reflection.Assembly.GetExecutingAssembly().CodeBase
Все они возвращают текущее местоположение выполнения в Windows (т. Е. C:/SomePath/SomeProject/Name/api.dll), которое я могу использовать с Path.Combine для получения пути к файлу схемы.
Однако в linuxвсе они возвращают /home/app/, что не в том месте, где должна быть dll, согласно журналам Дженкинса.Это приводит к сбоям при загрузке файла схемы.Проект фактически находится в /services/projectname/.
Код теста:
var schema = new XmlSchemaSet { XmlResolver = new XmlUrlResolver() };
schema.Add(null, Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Schema/schema.xsd"));
Ожидается: в Windows и Linux это загружает файл схемы, используя путь выполнения DLL в качестве основы.
Факт: В Linux вместо правильного пути я получаю home/app.
Редактировать: я не могу жестко указать путь.Путь изменяется при каждом развертывании, так как имя проекта версионно.Это означает, что после того, как я разверну его, любое жестко закодированное значение будет неверным.Мне абсолютно необходим относительный путь.Помимо этого технического требования, жесткое кодирование является основным табу.Я никогда не пройду мимо проверки кода.