Tag: 已过时
防止其他开发人员在类中使用基本方法
我有一个使用文件系统实体来操作数据的类。 我们有几种专门设计用于（尝试）处理我们使用此方法遇到的一些问题的方法（文件锁定，不存在的文件等）。 理想情况下，如果其他开发人员尝试通过System.IO直接访问文件系统而不是使用帮助程序方法，我希望能够发出警告。 这可能吗？ 我正在寻找的行为是有效地标记File.ReadAllText（）等方法，就像它们已经过时一样，但仅限于此项目（非解决方案范围内）。 我做了一些挖掘，看起来我唯一的选择是“告诉他们确保他们使用你的方法”。 我希望有人可以给我一个不同的，更有帮助的答案。 🙂 –EDIT–自定义StyleCop或FxCop规则的建议是好的，但遗憾的是在这种情况下不是不切实际的（并非部门中的每个开发人员都使用这些优秀的工具），并且执行文件访问的合法方法确实使用System.IO 。 将“忽略”属性添加到合法方法中也是一个危险的想法。 如果有人看到我如何“破坏”我自己的规则，他们可能会将属性复制到他们自己的方法中。
如何用Marshal.SizeOf （）替换Marshal.SizeOf（Object）？
我正在从现有代码构建一个Universal类库，并且我得到一些编译器警告，我终其无法弄清楚该怎么做。 我有这样的代码： void SomeMethod(Object data) { var size = Marshal.SizeOf(data); … } 代码构建，但在Universal项目（我猜，.NET 4.5.1及更高版本的项目）中，我得到以下编译器警告： 警告CS0618：’System.Runtime.InteropServices.Marshal.SizeOf（object）’已废弃：’SizeOf（Object）在将来的版本中可能不可用。 而是使用SizeOf （）。 但是如何使用通用无参数方法Marshal.SizeOf()在上述情况下为Marshal.SizeOf(Object)创建替换？ 从理论上讲，我可能不知道什么类型的data是什么？ 是因为使用Marshal.SizeOf(Object)被认为是不好的做法，它被Obsolete ？ 带回家的消息应该是“完全重构代码”？
如何将代码标记为“不用于将来使用”
我经常最终处于这样一种情况：我希望阻止其他开发人员继续使用方法或类。 例如，假设我有两个库方法“A”和“B”，其中“A”是执行某项任务的“旧”方式，“B”是执行该任务的“新”方式。 在许多情况下，A和B完全不同，使用A来重构代码开始使用B非平凡（例如，需要流过附加状态）。 由于A适用于使用它的情况，我不想优先考虑重构。 但是，我希望给我的开发人员一个可视的指示，即A不会在新代码中使用。 因此，理想情况下，当您使用ObsoleteAttribute引用一个成员而没有相关的编译器警告/错误时，我会得到一个删除（因为启用它会从A的所有旧用途中发出数百个错误，而我们没有计划随时解决）。 这样，如果开发人员用A编写新的代码行，他或她将立即注意到删除并修复代码以使用B. 有没有办法在VisualStudio（2012）中获得这样的function？ 编辑： 关于“无法区分新旧代码”的效果有几点评论。 我同意。 但是，这不是我要求的，所以让我澄清一下：相反，我想要的是代码“过时”（例如删除线）的直观表示，没有相应的编译器警告或错误。 这样，开发人员在阅读旧代码或编写新代码的过程中，会立即看到某些内容已过时。 即使.NET本身不支持这种情况，也许为此目的有一个VS扩展吗？ 有几条评论说“你不能既有警告也没有警告”。 我以为我解释了上面的用例，但我会再试一次。 我们有一组核心库，在构成我们代码库的各种解决方案中大量使用。 有时，我会对其中一个库进行更新，这些库提供了一个新的，更好的API来执行某些任务。 为了保持向后兼容性，我不能只删除执行该任务的旧方法（在许多情况下），因为大量现有代码依赖于使用旧的API集，并且不能轻易地重构以使用新的API。 此外，没有迫切的理由这样做; 它只会冒险将错误引入现有代码。 但是，我想通过某种方式在视觉上警告开发人员应该避免使用某些API以支持其他API。 这很困难，因为开发人员倾向于通过阅读完成相同任务的现有代码来学习如何完成某项任务。 这使得新的API难以传播，因为旧的根深蒂固的API被如此多的现有代码引用。 ObsoleteAttribute通过编译器警告实现了这一点，但这些警告只会从旧API的数百个现有用途中产生大量噪音。 这就是我喜欢删除线的原因：它是一种非常直观的东西，但只有当他或她正在阅读或编写使用过时API的代码时，它才会侵入开发人员。 以下是我想要标记旧API的一些更改示例： 我们引入了一个用于运行SQL查询的新API，它比以前更简洁，更古怪，更灵活。 很难彻底删除旧的API，因为它有许多可能依赖的古怪行为。 但是，我希望将人们推向新的API以便将来开发。 我们有两套内部unit testing助手API。 较旧的function完全正常，但它依赖于inheritance并且不是很灵活。 较新的一个使用属性构建，更灵活。 数百个旧测试仍然使用旧API运行，但我想推动新测试的编写者使用新API。 我们的核心库有一些旧的随机遗留代码，它们并不适合，但此时很难删除。 我想减少添加对这些类型和方法的新引用。 这样，在某些时候删除它们可能会降低成本效率，因为依赖于它们的现有代码会因正常的流失而消失。 作为进一步的说明，我认为这个问题的答案很好地描述了为什么你可能不会标记过时的东西，即使你不建议在新代码中使用它。 有几条评论/答案只是简单地提出了ObsoleteAttribute的存在。 请注意，此问题的文本始终引用该属性。
为什么C＃collection-properties在调用它们的属性时没有被标记为过时？
我试图将类上的集合属性标记为Obsolete以查找所有出现并在我的警告列表中保留缩小的事项列表，因为我们需要用其他东西替换此集合属性。 编辑 ：我已通过Microsoft Connect提交此问题 ， 问题＃417159 。 编辑16.11.2010 ：在编译.NET 3.5和4.0时，validation现在可以在C＃4.0编译器中使用。 我在发布的代码中收到4个警告，包括评论“Not OK？”的警告。 然而，令我惊讶的是，该列表只包含了一些内容，远远少于我所知道的内容，并且spotchecks告诉我，由于某种原因，警告列表中的编译器并不总是将该属性的使用标记为过时。 这是一个示例程序，可以在Visual Studio 2008中编译。 请注意标记为＃1-＃4的末尾附近的四行，其中，我希望所有人都报告所使用的属性已过时，但＃3不是，而且似乎如果我继续前进直接对集合属性或方法，属性本身的使用不会被标记为过时。 请注意，＃3和＃4引用相同的属性，＃4标记为使用过时的属性，而＃3则不是。 测试表明，如果在表达式中，我访问属性返回的集合的属性或方法，编译器不会抱怨。 这是一个错误，还是我不知道的C＃编译器的“隐藏的gem”？ using System; using System.Collections.Generic; namespace TestApp { public abstract class BaseClass { [Obsolete] public abstract String Value { get; } [Obsolete] public abstract String[] ValueArray { get; } [Obsolete] public abstract List ValueList { get; […]
