20

I am using the Microsoft TFS API and one of the properties on one of the interfaces has been marked as Obsolete and it instructs me to use a different property. Unfortunately the property the API wants me to use is used by TFS2010 and not TFS2008.

I have tried doing this:

#pragma warning disable 0612, 0618
            request.CommandLineArguments = arguments;
#pragma warning restore 0612, 0618

But I still get the error that CommandLineArguments is obsolete. Is there anyway to suppress this?

EDIT

Unfortunately this is not showing up as a 'Warning as Error', in fact Treat Warning's As Error's is turned off in my project. Here is a screen cap of the offending code as well as the error list

enter image description here

EDIT 2:

After using ILSpy the CommandLineArguments property looks like this in the TFS2010 API:

    [Obsolete("This property has been deprecated. Please remove all references. To pass command line arguments to MSBuild.exe, set the ProcessParameters property.", true)]
    string CommandLineArguments
    {
        get;
        set;
    }

Unfortunately I don't think there is a way to tell the compiler to ignore the error that the Obsolete attribute is causing.

EDIT 3 As @Peter Ritchie points out this value could be set via reflection. As I thought through this problem though my guess is that if Microsoft set the property to throw an exception even if you did set it via reflection I doubt that the value would be referenced anywhere.

dparsons
  • 2,812
  • 5
  • 28
  • 44
  • I've just tested those two `#pragma` to suppress a custom class Obsolete and they work fine - just 0612 was needed. Is there anywhere else that this could be used. Also, you can suppress warnings in the Project Properties. – DaveShaw May 15 '12 at 20:35
  • It's just a warning, not an error. You can leave the code be and it will work fine. – svick May 15 '12 at 20:38
  • I've updated my post. This is actually showing up as an error and not allowing the compiler to build the project correctly. – dparsons May 16 '12 at 11:24
  • Turn off "Treat warnings as errors" in your build settings. – KingCronus May 16 '12 at 12:06
  • See update to my answer. – Peter Ritchie May 16 '12 at 12:27
  • What you posted w.r.t to CommandLineArguments decompiled shows it wouldn't throw an exception. That doesn't mean it won't in the future and the best solution is to stop using CommandLineArguments. – Peter Ritchie May 16 '12 at 13:59
  • Ignore my previous comment, the decompiled code you showed is an interface and thus doesn't contain any code. Some implementations of that interface do throw an exception... – Peter Ritchie May 16 '12 at 14:01
  • Possible duplicate of [C# - Selectively suppress custom Obsolete warnings](http://stackoverflow.com/questions/968293/c-sharp-selectively-suppress-custom-obsolete-warnings) – Kira Apr 14 '16 at 11:58

3 Answers3

22

Visual Studio 2015

Build failing due to [Obsolete]?

This would only occur if "Treat Warnings As Errors" is enabled, and there is a method with the [Obsolete] attribute.

Method 1: Downgrade error to warning

Add <WarningsNotAsErrors>612,618</WarningsNotAsErrors> in the .csproj file (repeat for all sections):

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <WarningLevel>4</WarningLevel>
    <WarningsNotAsErrors>612,618</WarningsNotAsErrors>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
</PropertyGroup>

If dealing with many .csproj files, see Appendix A: Notepad++ for search and replace.

Method 2: Ignore error in file

Note: This method is not recommended, because it hides the warnings for methods marked [Obsolete]. We still want to see a list of all calls to obsolete methods so we can upgrade them.

Use #pragma warning disable 612,618

Method 3: Ignore error in project

Note: This method is not recommended, because it hides the warnings for methods marked [Obsolete]. We still want to see a list of all calls to obsolete methods so we can upgrade them.

Edit the project (repeat for all sections):

enter image description here

Method 4: Ignore error in project

Note: This method is not recommended, because it hides the warnings for methods marked [Obsolete]. We still want to see a list of all calls to obsolete methods so we can upgrade them.

Manually edit your .csproj to disable warnings for specific errors. Add the tag <NoWarn>612,618</NoWarn> (repeat for all sections):

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
    <NoWarn>612,618</NoWarn>
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x64\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <DebugType>full</DebugType>
    <PlatformTarget>x64</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>        
</PropertyGroup>

Appendix A: Notepad++ for search and replace

Have a lot of files? No problem!

Open all .csproj files in NotePad++, then:

  • Find: <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  • Replace: <TreatWarningsAsErrors>true</TreatWarningsAsErrors>\n\t<WarningsNotAsErrors>612,618</WarningsNotAsErrors>

enter image description here

Contango
  • 76,540
  • 58
  • 260
  • 305
20

Following works for me:

#pragma warning disable 612,618
            request.CommandLineArguments = arguments;
#pragma warning restore 612,618

notice no leading 0 in the numbers

EDIT: Okay, your assembly has the "true" argument in the ObsoleteAttribute constructor. This means you can't use the property and not get an error.

If you can't re-write your code to avoid using this property, you'll have to invoke the property setter via reflection, for example:

request.GetType().GetProperty("Number").SetValue(request, arguments, null);

and getting is similar:

(string)request.GetType().GetProperty("CommandLineArguments").GetValue(request, null);

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • I have updated my post. The leading 0 has no affect on the problem at hand. – dparsons May 16 '12 at 11:25
  • 1
    I am going to mark your answer as being correct since this technically would work. The only downside is that since Microsoft has marked it to throw an exception setting the value probably will have 0 impact on anything. In my case the way around this was to simply pass the value I was trying to assign to CommandLineArguments directly to the ProcessParameters property. – dparsons May 16 '12 at 13:51
10

Just in case anyone else stumbles on this.

If you mark the method in which you set the property as Obsolete and DONT mark it as true the compiler will ignore the interior error throwing your higher level warning instead which you can ignore.

IE

[Obsolete("Cause it aint",false)]
public void Foo(object arguments)
{
     request.CommandLineArguments = arguments;
} 
David
  • 1,131
  • 9
  • 22
  • 1
    This is not the case (for TFS request.CommandLineArgument) described above – amuliar Jan 05 '18 at 16:49
  • 3
    I know it's kinda hacking but is there any way to ignore when `error: true` is set? – joe Apr 19 '21 at 06:46
  • as stated above just rewrap it in another method where its set to false then Ignore it. – David Apr 19 '21 at 18:03
  • @joe The only way is to call the method via reflection. – krimog Oct 06 '22 at 17:43
  • 1
    @krimog Actually that not true, reflection is not the only option, you can call any obsolete method or property from another method or property that is also marked as Obsolete. As this post states. – David Oct 11 '22 at 18:35
  • @David My bad. I was sure an Obsolete("", false) could not call an Obsolete("", true), but I rechecked and it's indeed possible. I must have made another mistake when I tested it last week. – krimog Oct 12 '22 at 17:13