我需要加载XML模式文件以验证Linux服务器上.Net Core 2.1
api上的某些信息。不幸的是,我无权访问此服务器(我们使用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/
,根据詹金斯(Jenkins)日志,这不是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
而不是正确的路径。
编辑:我无法对路径进行硬编码。项目名称版本化后,路径在每个部署上都会更改。这意味着我第二次部署它,任何硬编码的值都是不正确的。我绝对需要相对路径。除了技术要求之外,硬编码是主要的禁忌。经过代码审查,我将永远无法得到它。
答案 0 :(得分:0)
对我来说,在dotnet core 3.1中,以下语句适用于Windows和Ubuntu中的控制台应用程序:
Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);