标签: obsolete

我想知道只在运行时检查过时的属性？

认为你有两个组件.程序集A使用程序集B中的方法.之后,我们将程序集B中的方法标记为过时,这会在编译程序集A时导致编译时错误.

到目前为止没有问题,但问题是旧的A组件是否继续与新的B组件一起工作？谢谢

我可以在某种程度上将整个命名空间标记为在.NET Framework(3.5和4)中过时,或者可选地将整个项目标记为什么？

我想知道是否可以创建一个自定义的过时类.我需要它并且我讨厌在我输入之前Obsolete出现这个警告的事实:SOMETHING已经过时了:我只想在仅使用输入的字段/方法时发出警告/错误,例如:

[CustomObsolete("Hello")]
public int i = 0;

将给出警告/调试你好.

这可能吗？如果我使用#warning/#error,它将始终显示错误/警告.

我经常遇到一种情况,我想阻止其他开发人员继续使用方法或类.例如,假设我有两个库方法"A"和"B",其中"A"是执行某项任务的"旧"方式,"B"是执行该任务的"新"方式.在许多情况下,A和B完全不同,使用A来重构代码开始使用B非平凡(例如需要流过附加状态).由于A适用于使用它的情况,我不想优先考虑重构.但是,我确实希望给我的开发人员一个直观的指示,即A不会在新代码中使用.

因此,我理想地喜欢在引用具有ObsoleteAttributeWITHOUT相关编译器警告/错误的成员时获得的删除(因为启用它会从A的所有旧用途中发出数百个错误,我们不打算随时解决).这样,如果开发人员用A编写新的代码行,他或她将立即注意到删除并修复代码以使用B.

有没有办法在VisualStudio(2012)中获得此类功能？

编辑:

• 对"无法区分新旧代码"的效果有几点评论.我同意.但是,这不是我要求的,所以让我澄清一下:相反,我想要的是代码"过时"(例如删除线)的直观表示,没有相应的编译器警告或错误.这样,开发人员在阅读旧代码或编写新代码的过程中,会立即看到某些内容已过时.即使.NET本身不支持这种情况,也许为此目的有一个VS扩展吗？

• 对于"你不能既有警告也没有警告"的效果,有几条评论.我以为我解释了上面的用例,但我会再试一次.我们有一组核心库,在构成我们代码库的各种解决方案中大量使用.有时,我会对其中一个库进行更新,这些库提供了一个新的,更好的API来执行某些任务.为了保持向后兼容性,我不能只删除执行该任务的旧方法(在许多情况下),因为大量现有代码依赖于使用旧的API集,并且不能轻易地重构以使用新的API.此外,没有迫切的理由这样做; 它只会冒险将bug引入现有代码.但是,我想通过某种方式在视觉上提醒开发人员注意某些API应该避免使用其他API.这很困难,因为开发人员倾向于通过阅读完成相同任务的现有代码来学习如何完成某项任务.这使得新的API难以传播,因为旧的根深蒂固的API被如此多的现有代码引用.在ObsoleteAttribute通过编译器警告实现这一点,但这些警告将刚刚从数百旧的API的现有用途的创建吨的噪音.这就是我喜欢删除线的原因:它是非常直观的,但只有在开发人员阅读或编写使用过时API的代码时才会干扰开发人员.以下是我想标记旧API的一些更改示例:

  • 我们引入了一个用于运行SQL查询的新API,它比以前更简洁,更古怪,更灵活.很难彻底删除旧的API,因为它有许多可能依赖的古怪行为.但是,我想将人们推向新API以便将来开发.
  • 我们有两套内部单元测试助手API.较旧的功能完全正常,但它依赖于继承并且不是很灵活.较新的一个使用属性构建,更灵活.数百个旧测试仍然使用旧API运行,但我想推动新测试的编写者使用新API.
  • 我们的核心库有一些旧的随机遗留代码,它们并不适合,但此时很难删除.我想减少添加对这些类型和方法的新引用.这样,在某些时候删除它们可能会降低成本效率,因为依赖于它们的现有代码会因正常的流失而消失.

• 作为进一步的说明,我认为这个问题的答案很好地描述了为什么你可能不会标记过时的东西,即使你不建议在新代码中使用它.

• 有几条评论/答案只是简单地说出了存在ObsoleteAttribute.请注意,此问题的文本始终引用该属性.

我们喜欢将警告设置为错误设置,因为我们的策略是不检查带警告的代码,这是我们发现强制执行它的唯一有效方法.

我们还希望使用Obsolete属性来标记不应再使用的方法.

问题是将Obsolete属性添加到方法或类会立即导致大量项目无法构建(更不用说如果不推荐使用.NET API调用的问题).

有没有人有这个好的解决方案？

我们想要一个可见的,难以忽略的指示器,表明您正在使用已弃用的API,但这不会导致构建失败.我们希望在IDE和CI版本中看到警告.

我注意到在使用C#构建一个较旧的MVC项目时,有很多对OWIN库的引用.但是在VS2015 SP3中创建.NET Core Web应用程序时,似乎没有对它的引用.

这个图书馆已经过时了吗？

Android版本2.3 - 2.3.2(API 9)被宣布为过时,根据Android Market统计,非常罕见(0.5%的市场用户).

问题是:为什么API 9被宣布为过时,更重要的是,有什么理由我不应该使用它吗？我一直在使用API​​ 9并且没有看到任何问题...我错过了什么？

最好不要修理它,如果它没有被打破,对吧？

编辑:

澄清:如果我将应用程序的API从9更新到10,那么有什么好处？

我只能看到负面影响:1%的用户会突然发现该应用程序不再适用于他们的手机.付费应用更糟糕.或者我被迫维护每个应用程序的两个版本.

注意:我已经检查了msdn,它没有解决我的实际问题,见下文.

我正在尝试在我的一个类中使用过时的(明显过时的)构造函数的过时属性.这是场景:

我希望能够强制开发人员更新到新构造函数,而不会影响已存在和已部署的代码.通过这种方式,我可以将我的代码部署到生产中,但是从开发人员的角度来看,无论何时他们进入他们的代码,而不仅仅是得到一个"警告"我肯定他们会忽略,我希望他们得到一个编译错误,因为现状不再正常.

所以我的问题是,这会影响开发人员,还是所有调用应用程序,还是我的整个错误？

示例代码:

public class MyClass
{
   private string _userID; //new code

   [Obsolete("This constructor is obsolete, please use other constructor.", true)]
   public MyClass()
   {
      _userID = ""; //defaulting to empty string for all those using this constructor
   }

   public MyClass(string userID)
   {
      _userID = userID; //this is why they need to use this constructor
   }
}

任何和所有帮助将不胜感激,提前感谢!

我已经从Windows 8.0将我的项目升级到Windows 8.1,并获得了一些过时代码的警告.其中一些我已修复,其中一些没有.

这是我无法修复的最后警告的图像,无法找到任何信息.

所有警告都指的是相同的方法,它说它已经过时了,我该怎么办才能获得不过时的代码？

以下是代码:

1. 警告号码2.

   /// <summary>
   /// Translates <see cref="ApplicationViewState" /> values into strings for visual state
   /// management within the page.  The default implementation uses the names of enum values.
   /// Subclasses may override this method to control the mapping scheme used.
   /// </summary>
   /// <param name="viewState">View state for which a visual state is desired.</param>
   /// <returns>Visual state name used to drive the
   /// <see cref="VisualStateManager" /></returns>
   /// <seealso cref="InvalidateVisualState" />
   protected virtual string DetermineVisualState(ApplicationViewState viewState) …

   Run Code Online (Sandbox Code Playgroud)

毕竟,它们似乎优于标准的libc rand().我错过了什么吗？

(我花了一些时间在网上搜索这个问题,而我能找到的这个问题的唯一另一个例子是在分布偏差的背景下并且没有得到答复.)

rand()和drand48()的手册页也似乎不一致.第一个推荐第二个,第二个推荐它已经过时,应该使用第一个.(虽然,公平地说,很多了解PRNG背后数学的人都会对这些函数的手册页有问题,因为它们的措辞很差,在某些情况下也是错误的.)

尽管如此,我仍然没有找到"过时"地位的理由.