不能，因为Windows文件系统本身不区分大小写。
如果您可以进入一个同时拥有RICHIE. h和richie. h的情况，那么控制大小写敏感性可能是有意义的，但您不能。

我想指出的是，这是不是一个无法解决的问题，因为许多人试图向OP指出。大小写不敏感是无关紧要的。关键是，正如Lorenz03Tx在评论中解释的那样，即使文件系统是大小写不敏感的，大小写也会保留，因此可以控制。
在进行跨平台开发时，这样的反措施真的很棒，并且当代码为其他平台编译时，可以防止很多工作。不要忘记，使构建过程更加挑剔，您将为开发人员带来更好的习惯，因为他们逐渐会更加一致地包含和命名文件。
TL;DR
一个解决方案是使用一个脚本，它简单地扫描源文件中的include语句，并尝试沿着include路径匹配它们。这样的脚本可以添加到visual studio的后期构建事件中，从而在每次构建时运行，或者（受krlmlr的启发）使用编译器的预处理器，强制区分大小写。

在NTFS上创建同名但大小写不同的文件是可能的（过去是？）。也许有cygwin的人可以验证这一点。
MSDN
然而，即使这样，也不可能从普通的Windows应用程序一次访问多个。

虽然在Visual Studio中可能无法强制执行这一点，但可以通过仅在C/C++源代码上运行预处理器来实现快速检查。这将运行得足够快，即使在版本控制系统中作为post-commit钩子也是可行的，并且如果文件名中的大小写不匹配，则会出错。因此：

• 在Linux中配置构建系统以支持仅预处理器运行（-E和gcc/g++）
• 实现一个只在预处理器上运行的post-commit hook，触发对负责人和/或愿意定期修复这些错误的人的早期通知

当然，这假设VCS作为代码的中央存储。

FAT和NTFS都是不区分大小写的文件系统。Foo和fOO就它们而言是同一个文件。尽管Windows操作系统会保留你对文件使用的大小写。如果你将文件命名为ThisIsAheaderFile. h，它将以这种方式显示在文件系统中。尽管所有打开该文件的系统函数调用都可以使用他们想要的任何大小写。

在linux下也有类似的问题;不是完整的解决方案…
如果您通过VSFind in Files*#include* 并将结果复制到textarea，您将获得排序的CSV，其中包括文件名，原始路径和第三列中的文件列表（列以制表符分隔）
易于检查解决方案/宽，如果没有太多的情况下的问题，它应该很容易更换他们？

function readIncludes(t)
{
    var s = t.value.split('\n');
    var res = {};
    for(var r in s)
    {
        if (r == 0) continue;
        var dq = s[r].indexOf('(');
        var p = s[r].substr(0, dq);
        var p2 = s[r].indexOf(':', dq);
        p2 = s[r].substring(0, p2);
        dq = s[r].indexOf('#', dq);
        var i = s[r].substr(dq);
        var ip = i.replace(/#include\s+/, "");
        if (!ip) continue; // *#includes.*
        var st = '<>""';
        if (st.indexOf(ip[0]) < 0) continue; // *#include*\S+
        st = st[st.indexOf(ip[0]) + 1];
        ip = ip.substr(1, ip.indexOf(st, 2) - 1);
        if (!ip || ip[0] == '/') debugger
        if (!res[ip]) res[ip] = [];
        res[ip].push(p2);
    }
    var resSorted = [];
    for(var r in res)
    {
        var shortR = r.replace(/.+[\\/]/, ""); // include file
        resSorted.push(shortR + "\t" + r + "\t" + res[r]); // \tpath\tplaces
    }
    t.value = resSorted.sort().join('\n'); // sort again long lines of results
}

html,body,textarea {
    width: 100%;
    height: 100%;
    white-space: nowrap;
}

<textarea onchange="readIncludes(this)">
</textarea>

我的意见：所有的C++编译器应该至少警告，如果在源代码中的#include的情况不同于在不区分大小写的系统上的磁盘上的情况。在区分大小写的系统上，它应该警告，如果有一个文件比当比较时，因为不区分大小写将匹配包含，并且是一个不同的情况比包含。只是我的意见，被这种方式咬了太多次...
根据我做跨平台开发的经验，处理这个问题的最好方法是在区分大小写的系统上编译，查找大小写冲突，然后修复它们。