你可以使用一些Interop代码来实现这个:
[DllImport("shlwapi.dll", CharSet = CharSet.Unicode)]
[return: MarshalAsAttribute(UnmanagedType.Bool)]
public static extern bool PathIsDirectory([MarshalAsAttribute(UnmanagedType.LPWStr), In] string pszPath)
为了进一步澄清一些评论...
在.NET中引入非托管代码并不比任何其他文件或I/O相关调用更加危险,因为它们最终都会调用非托管代码。
这是一次使用字符串的单个函数调用。通过调用此函数,您不会引入任何新的数据类型和/或内存使用。是的,你需要依赖非托管代码来正确清理,但你最终对大多数I/O相关的调用都有这种依赖。
供参考,这是从Reflector中获取的File.GetAttributes(string path)的代码:
public static FileAttributes GetAttributes(string path)
{
string fullPathInternal = Path.GetFullPathInternal(path);
new FileIOPermission(FileIOPermissionAccess.Read, new string[] { fullPathInternal }, false, false).Demand();
Win32Native.WIN32_FILE_ATTRIBUTE_DATA data = new Win32Native.WIN32_FILE_ATTRIBUTE_DATA();
int errorCode = FillAttributeInfo(fullPathInternal, ref data, false, true);
if (errorCode != 0)
{
__Error.WinIOError(errorCode, fullPathInternal);
}
return (FileAttributes) data.fileAttributes;
}
正如你所看到的,它还调用了非托管代码以检索文件属性,因此关于引入非托管代码是危险的争论是无效的。同样,完全保持在托管代码中的争论也是一样的。没有托管代码实现可以做到这一点。即使像其他答案所建议的那样调用File.GetAttributes(),也存在调用非托管代码的“问题”,我认为这是更可靠的方法来确定路径是否是目录。
编辑回答@Christian K关于CAS的评论。我认为GetAttributes进行安全性需求的唯一原因是因为它需要读取文件的属性,因此它希望确保调用代码有权限这样做。这与底层操作系统的检查(如果有)不同。如果需要,您始终可以在P / Invoke调用PathIsDirectory周围创建包装器函数,也会要求特定的CAS权限。