最近需要支持国产的 UOS 系统,这个系统我采用了 Xamarin 加上 GTK 开发,而我的日志系统有一个功能是记录日志的时候传入当前的文件路径,此时 NuGet 包是在 Windows 下构建的,因此传入的路径是 Window 构建服务器路径。此时在 Linux 上尝试获取文件名就炸了
在 dotnet 中,可以通过 CallerFilePath 特性获取调用当前方法的文件路径是哪个,请看下面代码
public void DoProcessing ()
TraceMessage ( " Something happened. " );
public void TraceMessage ( string message ,
[ System . Runtime . CompilerServices . CallerMemberName ] string memberName = "" ,
[ System . Runtime . CompilerServices . CallerFilePath ] string sourceFilePath = "" ,
[ System . Runtime . CompilerServices . CallerLineNumber ] int sourceLineNumber = 0 )
System.Diagnostics.Trace. WriteLine ( " message: " + message);
System.Diagnostics.Trace. WriteLine ( " member name: " + memberName);
System.Diagnostics.Trace. WriteLine ( " source file path: " + sourceFilePath);
System.Diagnostics.Trace. WriteLine ( " source line number: " + sourceLineNumber);
// message: Something happened.
// member name: DoProcessing
// source file path: c:\Users\username\Documents\Visual Studio 2020\Projects\CallerInfoCS\CallerInfoCS\Form1.cs
// source line number: 31
上面代码是官方的例子,这是在构建的时候,自动注入的值。因此在 Windows 服务器构建的 NuGet 包给日志注入字符串是构建服务器上的代码文件的路径
而我记日志只是使用了文件名而已,如下面代码
public static void LogInfo ( this ILogger logger , string message ,
[ System . Runtime . CompilerServices . CallerMemberName ]
[ System . Runtime . CompilerServices . CallerFilePath ]
string sourceFilePath = "" ,
[ System . Runtime . CompilerServices . CallerLineNumber ]
int sourceLineNumber = 0 ,
// 刚好在 Linux 下构建的在 Linux 下运行,而在 Windows 构建的库在 Windows 下执行。此时使用 GetFileNameWithoutExtension 能保持输入路径和解析相同
// 假定在 Windows 下构建而在 Linux 下构建,只是让路径变长而已,我相信咱的日志系统炸不了…… 或者说,炸了再说
// 炸了的解决方法是在 dotnet runtime\src\libraries\System.Private.CoreLib\src\System\IO\Path.cs 的 GetFileName 方法里面将 `PathInternal.IsDirectorySeparator(path[i])` 替换为实际需要的 \ 或 / 符号
var classFile = Path. GetFileNameWithoutExtension (sourceFilePath);
如注释,使用 Path.GetFileNameWithoutExtension 如果在 Linux 运行,传入的是 Windows 下的路径,那么此时将拿不到文件名
原因是 Path.GetFileNameWithoutExtension 的实现如下
public static ReadOnlySpan < char > GetFileNameWithoutExtension ( ReadOnlySpan < char > path )
ReadOnlySpan < char > fileName = GetFileName (path);
int lastPeriod = fileName. LastIndexOf ( '.' );
return lastPeriod == - 1 ?
fileName : // No extension was found
fileName. Slice ( 0 , lastPeriod);
public static ReadOnlySpan < char > GetFileName ( ReadOnlySpan < char > path )
int root = GetPathRoot (path).Length;
// We don't want to cut off "C:\file.txt:stream" (i.e. should be "file.txt:stream")
// but we *do* want "C:Foo" => "Foo". This necessitates checking for the root.
for ( int i = path.Length; -- i >= 0 ;)
if (i < root || PathInternal. IsDirectorySeparator (path[i]))
return path. Slice (i + 1 , path.Length - i - 1 );
上面代码的 GetFileName 的 PathInternal.IsDirectorySeparator
判断就不对了,因此就拿不到文件路径了。因为在 Windows 下添加的字符串默认使用的是的是 \
分割,因此 Linux 下无法解析。反过来,如果是在 Linux 服务器构建的,此时在 Windows 下解析没有问题,因为在 Windows 下的 IsDirectorySeparator 方法的判断是两个方向的都可以
解决方法就是自己抄 dotnet runtime\src\libraries\System.Private.CoreLib\src\System\IO\Path.cs
的 GetFileNameWithoutExtension 方法,修改判断文件夹符号
这是我修改的代码
public static ReadOnlySpan < char > GetFileNameWithoutExtension ( ReadOnlySpan < char > path )
ReadOnlySpan < char > fileName = GetFileName (path);
int lastPeriod = fileName. LastIndexOf ( '.' );
return lastPeriod == - 1 ?
fileName : // No extension was found
fileName. Slice ( 0 , lastPeriod);
public static ReadOnlySpan < char > GetFileName ( ReadOnlySpan < char > path )
int root = GetPathRoot (path).Length;
// We don't want to cut off "C:\file.txt:stream" (i.e. should be "file.txt:stream")
// but we *do* want "C:Foo" => "Foo". This necessitates checking for the root.
for ( int i = path.Length; -- i >= 0 ;)
if (i < root || path[i] == '/' || path[i] == ' \\ ' )
return path. Slice (i + 1 , path.Length - i - 1 );
特别吐槽 Linux 系统的文件路径的坑,在这里被坑了几次了
更好的解决方法是在 Linux 运行的内容就在 Linux 构建,本来我的主项目也是在 Linux 构建的。不过这里炸的是 CBB 公共组件,这些 NuGet 是在 Window 构建的,因为每个 NuGet 都支持 .NET Framework 和 .NET Core 版本
尽管我不能吐槽 UOS 系统,客观说,这个系统现在还是不开源的。我没有看到这个系统的优势。也许唯一的优势就是咱国家的有政策在推动,加上底子是深度的
我依然还会努力去支持国产的系统,尽管支持会让我加好多班,业余时间也用在支持上。整个 dotnet 都是开源的,而且还是完全开源的,加上现在龙芯等在硬件层面对 .NET 添加了运行时优化,此时在 UOS 上基于 .NET 构建从最低到最顶的完全自主研发的软件是十分简单的事情
这里需要说明一下的是完全开源的 .NET 完全允许贴牌,也就是改个名字,说这是自己完全拥有的技术,这是没有问题的,官方也是支持的。如果在贴牌之后还能将自己发现的 Bug 等提到官方,那么官方就更是推荐这样的行为。使用 .NET 的优势在于不会被卡,因为从编译到运行时到库都是完全开源,同时可自行构建,无版权问题。假设现在 M$ 断绝所有技术支持,包括抹掉了中国微软,此时对 .NET 也多少影响,除了可能存在的新代码无法拿到外,现有的代码同时基于现有代码继续开发没有任何问题。咱能改代码,也改的动
原文链接: http://blog.lindexi.com/post/C-dotnet-%E8%A7%A3%E5%86%B3-Path-%E8%8E%B7%E5%8F%96%E6%96%87%E4%BB%B6%E5%90%8D%E8%B7%AF%E5%BE%84%E5%9C%A8-Windows-%E6%9E%84%E5%BB%BA%E5%9C%A8-Linux-%E6%89%A7%E8%A1%8C%E9%97%AE%E9%A2%98
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。
欢迎转载、使用、重新发布,但务必保留文章署名 林德熙 (包含链接: https://blog.lindexi.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请与我 联系 。