fody / obsolete Goto Github PK

There are scenarios when ObsoleteEx is not needed and plain Obsolete is required to have a "warning" forever (type that is public that cannot be removed, but also should not be used as an example).

Currently Fody generates a warning:

1>  Fody: Fody (version 2.1.2.0) Executing
1>MSBUILD : warning : Fody/Obsolete: The member `System.TimeSpan Library.Class::Property()` has an ObsoleteAttribute. You should consider replacing it with an ObsoleteExAttribute.

Would be nice to get rid of the warning for types/properties by opting out from Fody inspection.

Hi,
Thanks for the great work!, extremely useful.

I have been thinking whether we could extend the ObsEx attribute to handle a date. May be a new attribute called "ObsBy", which has a date. (e.g)
[ObsoleteBy(EffectiveFromIsoDatePart = "2014-09-01", TreatAsErrorFromEffectiveFromIsoDatePart = true)]
public string PropertyWithExpiry { get; set; }

I work with an extremely large code base and we seems to leave code that should ideally be removed at certain point (certain release or after 3/4 months in trial).

I am just wondering this is something you would consider for your library.

Thanks, M.

I've just updated to the latest version of Obsolete.Fody and I'm also using the Costura weaver.

Before the update my FodyWeavers.xml looked like this:

<?xml version="1.0" encoding="utf-8"?>
<Weavers>
  <Costura>
    <IncludeAssemblies>
      Raven.Abstractions
      Raven.Client.Lightweight
    </IncludeAssemblies>
  </Costura>
  <Obsolete HideObsoleteMembers='true'/>
</Weavers>

After the update:

<?xml version="1.0" encoding="utf-8"?>
<Weavers>
  <Obsolete />
</Weavers>

I was expecting the update to recognise that there is already a FodyWeavers.xml and only update it if the weaver is not already there.

I see that you've updated to csproj packaging.

However, currently, the default value for PrivateAssets results in build targets/props and analyzers being excluded from transitive references:

That means if someone just installs the Obsolete.Fody package, the transitive reference to Fody won't work at all because the targets aren't added to the project.

I'd recommend adding PrivateAssets="none" to the package reference to fix this.

There are now 2 editions of Windows Phone 8.1. Please add support for Windows Phone 8.1 RT (SL already works).

I've started seeing a weird failure on https://github.com/Particular/NServiceBus.AmazonSQS, on both the develop branch and Particular/NServiceBus.AmazonSQS#197

[Fody.WeavingTask] Fody: Could not enable HideObsoleteMembers due to problem finding EditorBrowsableAttribute. Disable HideObsoleteMembers and raise an issue detailing what runtime you are compiling against. Inner Exception:System.InvalidOperationException: Sequence contains no matching element
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at ModuleWeaver.FindFromTypes(Collection`1 typeDefinitions) in C:\projects\obsolete\Fody\EditorBrowsableAttributeFinder.cs:line 39
   at ModuleWeaver.FindSystemTypes() in C:\projects\obsolete\Fody\EditorBrowsableAttributeFinder.cs:line 27

It's happening for a netstandard2.0 build being run via msbuild.exe, but only on the build server. Building locally works fine. The net452 target in the same build also works fine.

We're running Fody 2.4.4 and Obsolete.Fody 4.3.7, but this just started happening even though we've been running with those versions.

I suspect there is something environmental going on. Given that Fody scans a lot of directories outside of the project, could it be picking up something from another build? Any ideas as to what I could go looking for that might be causing the failure?

log.txt

Because ObsoleteExAttribute does not derive from ObsoleteAttribute, Resharper does not provide syntax highlighting support for objects that are marked as ObsolteEx.

By default the prefix of AssemblyInformationalVersionAttribute will be used, if it can be parsed to a version. Otherwise the assembly version is used.

b3aa25e

So given

[ObsoleteEx(TreatAsErrorFromVersion = "2.1")]

The following should be created

[Obsolete("Will be treated as an error from version 2.0.0. Will be removed in version 3.0.0.")]

Compared to the previous incorrect behaviour of generating

[Obsolete("Will be treated as an error from version 2.0.0. Will be removed in version 3.1.0.")]