未发布 微软C# 8.0中的四个特性 可空的引用类型（Nullable Reference Types）
可空的引用类型可概括地表述为，引用类型将不再默认可空。因此，开发人员必须使用定义可空值类型的同样语法“Type?”，显式地标记一个引用类型为可空。
如果将一个空值赋值给一个非可空的引用类型，那么将会给出一个编译器警告。与之相类似，从可空类型中读取也会给出编译器警告，除非显式地提前检查了被质疑的变量是否为空值。因此从理论上讲，开发人员需要做的唯一更改就是在代码的适当位置标上问号。
该特性新加了一个语法。该语法针对开发人员明知一个可空变量x并非实际为空值却无法证明给编译器的情况。在上述情况下，开发人员现在可以定义x!.Method()，消除编译器对于潜在空值引用异常的警告。
异步流（Async Streams），即foreach async
异步流是IEumerable的异步等价类。C#团队自2015以来就一直在努力实现异步流。在经历了很多争议后，其语法被定为： foreach await (string s in asyncStream)
开发人员将使用如下的函数签名定义一个异步迭代器：
async IAsyncEnumerable MethodName()
就像使用一个正常的IEnumerable方法一样，开发人员可以使用“yield return”以懒方式（Lazy）构建对象流。
相比于源自响应式扩展（Reactive Extensions）的IObservable，使用这一方法的优点在于让消费者控制流速，这被称为“Pull模式”。与之相对，IObservable是一种“Push模式”，这意味着生产者可以使用高于消费者所能处理的流速让流涌向消费者。
缺省接口实现（Default Interface Implementations）
缺省接口实现在本质上是一种有限形式的多重继承。它允许抽象接口像抽象类一样，对方法进行完全的定义，只是抽象接口依然不能定义构造函数和字段。
需注意，开发人员可以通过使用ConditionalWeakTable在接口上模拟字段。
默认接口实现的主要好处是，开发人员可以在不破坏向后兼容的条件下，将一个新方法添加到一个已有的接口中。但是这并非是有保证的，因为默认接口只是在可以设计出适合的默认方法时才能工作。
扩展（Extension）
开发人员可以编写扩展方法，但是不能扩展属性，这是长期以来对C#一直存在的一个问题。事实上，如果使用当前的模式，甚至是不能定义一个扩展属性或事件的。此外，在很多开发人员看来，在静态类中放置扩展方法是“很诡异的”。
新的设计中新给出了一种称为“扩展”（Extension）的顶层语言构件。例如，如果开发人员想要为自定义的Customer类创建一个扩展方法和属性，可编写如下代码：
extension CustomerExt extends Customer {
//定义方法和属性的代码。
}就接口而言，是不能在扩展中定义实例字段的，但是可以使用ConditionalWeakTable实现模拟。定义静态字段也是允许的。
除了对属性、事件和操作符重载的扩展，C#团队甚至考虑允许扩展构造函数。扩展构造函数非常适用于工厂模式（Factory）和对象池场景。
扩展接口（Extension Interfaces）C#团队还考虑了扩展接口，即在已有类中添加新接口的能力。但是扩展接口将不会成为C# 8中的特性，因为它需要更改底层的运行时。
未发布 【教程】网络安全工具FileAudit安装指南 FileAudit可用于对Windows服务器上文件和文件夹的所有访问进行主动跟踪、审核、报告和警告。本文为大家介绍FileAudit的具体安装步骤。
英文和法文版本是相同的，并且与32位和64位平台兼容。
1、要启动FileAudit安装过程，请使用管理员帐户运行FileAudit_Setup.exe。
2、启动安装过程：
3、在随后的窗口中，单击 下一步>：
4、仔细阅读并接受最终用户许可协议，然后单击下一步> ：
5、在随后的窗口中，输入您的信息，然后单击下一步> ：
6、可根据需要更改安装文件夹：
7、在“安装类型”中，选中“Complete”复选框并点击下一步> ：
8、点击 “安装”开始FileAudit安装：
9、向导将在FileAudit成功安装时报告。点击“完成 ”：
未发布 百度正式开源其RPC框架brpc 9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。
Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？
戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q：为什么百度当时要研发brpc？
戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。
Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？
戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？
- 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。
Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？
戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。
Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？
戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
- 多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。
无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。
Q：谈谈brpc的整体架构？
戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。
Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。
Q：brpc的性能如何？这么高的性能是怎么做到的？
戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？
戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>
未发布 图像工具包VintaSoftImaging.NET SDK发布v8.5，新增独立web服务
Version 8.5更新内容
Web图像查看器：
创建了独立的Web服务，用于渲染图像和缩略图。该Web服务允许为任何.NET兼容的Web平台快速创建Web服务，例如ASP.NET WebForms、ASP.NET MVC、ServiceStack。Web服务位于Vintasoft.Imaging.Web.Services.dll程序集中。
在ASP.NET MVC 5中创建用于渲染图像和缩略图的Web服务。该Web服务位于Vintasoft.Imaging.Web.Api2Controllers.dll程序集中。
用于渲染图像和缩略图的HTML5和SVG控件现在与jQuery 2和3完全兼容。
改进了web图像查看器中的放大镜功能。
在Web应用程序中处理图像：
创建了独立的Web服务，用于图像处理。该Web服务允许为任何.NET兼容的Web平台快速创建Web服务，例如对于ASP.NET MVC、ASP.NET WebForms、ServiceStack。 Web服务位于Vintasoft.Imaging.Web.Services.dll程序集中。
在ASP.NET MVC 5中创建用于图像处理的Web服务. Web服务位于Vintasoft.Imaging.Web.Api2Controllers.dll程序集中。
负责图像处理的JavaScript类现在与jQuery 2和3完全兼容。
在Web应用程序中打印图像：
演示应用：
试用、下载、了解更多产品信息请点击"咨询在线客服"
未发布 Essential Studio for ASP.NET Web Forms发布2017 v2，新增自定义树形网格工具栏等 Essential Studio for ASP.NET Web Forms是一个帮您轻松创建商业Web应用程序的ASP.NET界面控件，其包含了商业Web应用程序开发中所需的所有控件，如grids、charts、gauges、menus、calendars、editors等等。同时，Essential Studio for ASP.NET中高性能的界面控件库还允许您的应用程序浏览和创建Excel、Word和PDF格式的文件。
Essential Studio for ASP.NET Web Forms更新2017 v2版本，增加大量新功能包括自定义树形网格工具栏、文本注释等。
通常
支持资源文件本地化
支持资源文件本地化，根据应用程序或组件生成文本。
图表
饼状图系列
增加创建饼状图的新功能。
打印
支持打印图表。
改进轴元件配置
图表控件现在可以防止轴图元素（如标签和标题）放在图表区域内时，图表值越过轴的问题。
圆形表盘
图例
添加图例来表示圆形表盘中的范围。
图表
标签的模板选项
图表控件现在支持在HTML和SVG渲染模式中定义标签的模板内容。
DocIO
增强Word转换PDF功能
DocIO现在支持Word到PDF转换期间的方程式字段。
甘特图
导出PDF
甘特图内容现在可以导出为PDF。
自定义工具栏项目
甘特图控件现在支持自定义工具栏项目。
映射展开状态
最初加载时，可以映射记录的展开状态。
列表框
排序
现在可以按升序或降序自动排序列表项。
列表显示
虚拟滚动
添加正常模式和连续模式下的虚拟滚动支持，无需缓冲即可加载大量数据。
PDF
增强PDF安全功能
现在支持PDF 2.0安全功能（AES Revision 6）。
PDF查看器
文本标记注释
文本标记注释（高亮、下划线和删除线）已添加到PDF查看器控件中。现在可以加载PDF文档，包括文本标记注释，并且可以编辑现有注释。
数据透视图表
分组标签
数据透视图表中的分组标签可以选择向上和向下拉取以提供详细的系列信息。
Pivot客户端
计算成员
Pivot客户端支持通过交互式对话框在运行时创建和显示维度和测度。
所有Pivot控件通用
Mondrian XML/A连接（客户端模式）
所有数据透视控件都可以通过不同版本的XML/A连接从Mondrian中检索多维数据，仅适用于客户端模式。
演示
注释功能
可以在PowerPoint演示文稿中创建和修改注释。
富文本编辑器
粘贴清理
从Word或网页（HTML）复制的内容将在粘贴到富文本编辑器时进行预处理，清理和格式化以获取正确的HTML。
时间表
隐藏周末
周末可以隐藏在调度程序中，并在所有视图中只显示工作日。
树型网格
自适应渲染
树型网格控件的UI已经在移动环境中得到了改进。
对话框编辑
树型网格控件现在支持对话框编辑。
自定义工具栏
树型网格控件现在支持自定义工具栏。
列验证
记录在更新到数据库之前可以进行验证。
映射展开状态
初始加载时可以映射树形网格中记录的展开/折叠状态。
复选框列
树型网格支持通过Boolean数据显示复选框列。
XlsIO
Excel到PDF转换中的图标设置
Essential XlsIO支持使用“仅显示图标”和“反向图标顺序”选项进行PDF转换的自定义图标设置。
增强图表转换图像功能
将图表转换为PDF文件或图像时，图表元素（如标题和显示单元）现在支持富文本和具有不同标记的图表系列。
数据透视表自定义排序
数据透视表列可以通过字符串数组或设置自定义位置进行排序。
表格过滤器
可以根据文本、数值和日期过滤Excel表格行。
未发布 安全预警：Xshell 5.0 Build 1322官方版本被植入后门，请尽快更新至最新版本 知名服务器终端管理软件Xshell在7月18日发布的5.0 Build 1322官方版本被植入后门，用户下载、更新到该版本均会中招。危害正在评估中，或可能窃取用户设备信息。
Xshell是一款功能强大的服务器终端管理软件，支持SSH1、SSH2、TELNET等协议，由国外公司NetSarang开发，在运维、站长、安全等圈子里有极多受众。
NetSarang公司在8月7日发布安全公告，称其最近更新（7月18日）的Xmanager Enterprise、Xmanager、Xshell、Xftp、Xlpd五款软件存在安全漏洞，官方已于8月5日紧急修复，并发布更新版本。目前暂未发现有人利用过漏洞。
五款软件的受影响版本：
Xmanager Enterprise 5.0 Build 1232
Xmanager 5.0 Build 1045
Xshell 5.0 Build 1322
Xftp 5.0 Build 1218
Xlpd 5.0 Build 1220
8月5日五款软件发布新版本，更新日志基本一致，都提到修复SSH通道的追踪消息和问题文件nssock2.dll：
FIX: Unnecessary SSH channel trace messages
FIX: Patched an exploit related to nssock2.dll
NetSarang公司没有解释漏洞的成因，据了解，很可能是该公司遭遇了入侵，发布版本被植入后门。有国内用户更新到Xshell问题版本，抓包发现该版本的nssock2.dll会向陌生域名（*.nylalobghyhirgh.com）发送畸形DNS请求。问题版本的nssock2.dll带有官方签名，可能是攻击者窃取了NetSarang的签名，或者直接在源码层面进行了植入。
修复方案
NetSarang公司已经发布修复版本，建议该公司产品用户请尽快更新至最新版本，企业网络可将*.nylalobghyhirgh.com域名进行屏蔽。
未发布 2D/3D文档查看器ABViewer发布v12，大大提高PDF转DWG的速度丨附下载 ABViewer是一款高质量的2D/3D文档查看器，可提供专业的浏览、编辑和转换功能，支持30多种光栅和矢量图形格式，其中包括AutoCAD DWG, DXF, DWF, Hewlett-Packard HPGL, PLT, HGL, CGM, SVG, IGES/IGS, STEP/STP, STL, 3DS, TIFF, BMP, JPG, GIF等。 ABViewer 12支持AutoCAD®DWG 2018、PDF转DWG速度更快、DWG/DXF转G-code。
ABViewer始终与时俱进，CAD应用程序的新版本ABViewer 12主要用于DWG/DXF和其他2D和3D CAD格式，以及三个主要亮点。
导入AutoCAD®DWG 2018
无论你是在CAD行业工作还是偶尔接收CAD图纸，ABViewer 12始终能够打开所有版本的DWG文件。支持导入最新版本的绘图文件格式 - AutoCAD®DWG 2018。
提高PDF转DWG的速度
ABViewer 12中PDF到DWG转换速度大大加快。以前，转换大文件需要很多时间，现在你无需浪费这些时间了。一些文件的转换就在眨眼之间！
DWG/DXF转换为G-code
许多使用数控机床的人需要从CAD文件中生成G-code。新版本的ABViewer可以实现这个目标。
你可以使用ABViewer创建铣削和切割数控机床的G代码。只需加载你的DWG或DXF文件，调整设置，ABViewer将从你的图纸中生成G-code并将其保存为NC文件格式。
未发布 【教程】网络安全工具FileAudit中配置你的第一个Audit路径 FileAudit可用于对Windows服务器上文件和文件夹的所有访问进行主动跟踪、审核、报告和警告。本文为大家介绍如何配置你的第一个Audit路径。
1、启动FileAudit。
你会发现3个主要分组：
- Audit：允许您配置审计和警报。
- Access：显示“文件访问查看器”和“统计”视图。
- Tools：自定义FileAudit设置，安排自动报告、清理数据库和访问帮助文件。
右上角的“连接”按钮允许您远程连接到“FileAudit服务”的另一个系统。
2、要设置您的第一个审计路径，请单击FileAudit集线器中的“添加文件夹”。点击“+”按钮，浏览您的目标文件夹：
3、验证了您的选择后，将弹出“FileAudit路径向导”，以指导您完成配置文件夹审计的过程。
该向导将显示所选文件夹的配置状态，并突出显示缺少的任何需求或设置。对于每个必要的操作，您可以选择自动完成（通过向导）或手动完成。我们强烈建议您将FileAudit自动配置用于所有设置。
4、需要操作的列表。
5、选择自动或手动处理。
6、FileAudit将优化NTFS审计设置。
7、当NTFS Audit设置被禁用时，FileAudit检查并可以启用它。
8、文件夹主机将被添加到“许可服务器”列表中。
9、启用实时事件监控。
10、您选择的文件夹现在由FileAudit进行监控。所有访问事件将被存储在FileAudit数据库中。
注意：
有几个不同的方法来选择要审核的文件/文件夹路径。除了以上方法外，您还可以：
- 通过右键单击Windows资源管理器中的文件或文件夹启动控制台，然后在“上下文菜单”中选择FileAudit。在这种情况下，前面的步骤将被跳过，因为文件/文件夹路径被直接导入FileAudit控制台。
- 显示“文件访问查看器”并直接在“路径”字段中输入目标路径。您也可以在“文件访问查看器”中找到两个按钮来添加文件夹或文件。
- 只需使用“Audit配置”部分中的两个贴图“添加文件夹”或“添加文件”即可。
另外，FileAudit总是检查在不同视图和设置中输入的每个路径的配置状态，例如：
沪公网安备31011202009668号 | 沪ICP备13020027号-2