Archived

This forum has been archived. Please start a new discussion on GitHub.

slice2cs 3.4 tie classes use ObsoleteAttribute without namespace

Hi All,

afaict slice2cs 3.4 has a bug in the generation of tie classes. They look like the following and don't compile because the using statement in red prevents the compiler from resolving the Obsolete attribute in blue.
[COLOR="Red"]using _System = global::System;[/COLOR]
using _Microsoft = global::Microsoft;

namespace MyModule
{
    ...
    public class IMyInterfaceTie_ : IMyInterfaceDisp_, Ice.TieBase
    {
        ...
        [COLOR="Blue"][Obsolete("This method is deprecated, use GetHashCode instead.")][/COLOR]
        public override int ice_hash()
        {
            return GetHashCode();
        }
        ...
    }
    ...
}

If I understand the problem, the line in blue should be:
[[COLOR="Green"]_System[/COLOR].Obsolete("This method is deprecated, use GetHashCode instead.")]

ZeroC, when do you think a fix will be made available? (if you agree the problem is there, of course :-) )

Thank you

Comments

  • Just wanted to add one thing...

    The ice_hash method in the above post is actually overriden from a base abstract class in Ice.dll where it is marked as obsolete.

    The compiler issues a warning if the override is not marked as obsolete.

    This means defining a bogus ObsoleteAttribute in the same namespace as the tie class does not make the compiler happy, as System.ObsoleteAttribute is sealed.

    The only way around this problem is suppressing CS0672 and CS1591 for the whole project.

    This makes System.ObsoleteAttribute useless, which I think is a rather *major* sacrifice for big projects.

    This will make Ice a rather hard sell for my project. Please help, ZeroC!
  • mes
    mes California
    Hi Alessio,

    Thanks for reporting this. The generated ice_hash method is actually redundant because it's inherited from Ice.ObjectImpl.

    I've posted a patch for this issue. We'll also add a test for the next release to make sure we don't run into this again.

    Thanks,
    Mark