Develop Reference

Equals is not implemented

I have the following class in C# 10:
public sealed record Country : IEquatable<Country>
{
public string Language { get; set; } = "xx";
public bool Equals(Country? other)
{
if (other is null)
{
return false;
}
return Language == other.Language;
}
public override int GetHashCode() => Language.GetHashCode();
}
Which when compiling will bring the following compile time error:
Interface member 'bool System.IEquatable<Country?>.Equals(Country?)' is not implemented
Which is... a very weird error message for the type in question. I tried varying the nullability of the Country parameter, and I tried generating the "missing" method, which will generate the following method for my IDE:
public bool Equals(Country? other) => throw new NotImplementedException();
And then, of course, the error switches to
Member with the same signature is already declared
Generating the Equals() method directly will just override the existing method.
What is going on here? Not all of my colleagues have the same error message for this class, so it might just be something that has nothing to do with the class. (I think I'm the only one on Windows, for example.) dotnet build works, so it might just be a problem with Rider 2021.3.2, but that's the IDE my colleagues use as well.

Its related to your record usage, records already implement this interface and IEquatable is not needed
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/records#equality-members
Quick test in Visual studio and its likely IDE issue.

Records implement equality automatically: that's one of the main advantages of using one.
We can see this in SharpLab. If we paste in:
public sealed record Country
{
public string Language { get; set; } = "xx";
}
and select "Results: C#", we can see that the generated code includes:
public override int GetHashCode()
{
return EqualityComparer<Type>.Default.GetHashCode(EqualityContract) * -1521134295 + EqualityComparer<string>.Default.GetHashCode(<Language>k__BackingField);
}
[System.Runtime.CompilerServices.NullableContext(2)]
public override bool Equals(object obj)
{
return Equals(obj as Country);
}
[System.Runtime.CompilerServices.NullableContext(2)]
public bool Equals(Country other)
{
return (object)this == other || ((object)other != null && EqualityContract == other.EqualityContract && EqualityComparer<string>.Default.Equals(<Language>k__BackingField, other.<Language>k__BackingField));
}
as well as definitions of the == and != operators.
See here.
If you do want to override equality in a record, then you do that as you have done, by specifying your own bool Equals(Counter? other) and int GetHashCode() methods. There's no need to specify that the record implements IEquatable<Country> however, because the compiler will automatically add this interface for records.
Note that it's good practice to put in a test for EqualityContract == other.EqualityContract. This is used to make sure that you're not comparing a record of type Country with one which is a subclass of Country:
public bool Equals(Country? other)
{
if (ReferenceEquals(this, other))
return true;
if (other is null || EqualityContract != other.EqualityContract)
return false;
return Language == other.Language;
}
public override int GetHashCode() => Language.GetHashCode();
See on SharpLab.

How do the `EqualOperator()` and `NotEqualOperator()` methods work in this `ValueObject` implementation (Microsoft Docs)?

In Domain Driven Design, we're introduced to the concept of a ValueObject, where objects don't carry an identity.
Microsoft have provided an implementation of their ValueObject in their Microservices series, where they override Equals() so that two ValueObject's with the same values are considered identical.
I've included their implementation below, but my question is relating to the EqualOperator() and NotEqualOperator() methods - how does this work? when are they called?
I'm familiar with operator overloads, but this seems to be an implementation I've not seen before, and I can't find any documentation around it.
Here is the implementation:
public abstract class ValueObject
{
protected static bool EqualOperator(ValueObject left, ValueObject right)
{
if (ReferenceEquals(left, null) ^ ReferenceEquals(right, null))
{
return false;
}
return ReferenceEquals(left, null) || left.Equals(right);
}
protected static bool NotEqualOperator(ValueObject left,
ValueObject right)
{
return !(EqualOperator(left, right));
}
protected abstract IEnumerable<object> GetAtomicValues();
public override bool Equals(object obj)
{
if (obj == null || obj.GetType() != GetType())
{
return false;
}
ValueObject other = (ValueObject)obj;
IEnumerator<object> thisValues = GetAtomicValues().GetEnumerator();
IEnumerator<object> otherValues =
other.GetAtomicValues().GetEnumerator();
while (thisValues.MoveNext() && otherValues.MoveNext())
{
if (ReferenceEquals(thisValues.Current, null) ^
ReferenceEquals(otherValues.Current, null))
{
return false;
}
if (thisValues.Current != null &&
!thisValues.Current.Equals(otherValues.Current))
{
return false;
}
}
return !thisValues.MoveNext() && !otherValues.MoveNext();
}
// Other utilility methods
}
Here's an example of their object in use:
public class Address : ValueObject
{
public String Street { get; private set; }
public String City { get; private set; }
public String State { get; private set; }
public String Country { get; private set; }
public String ZipCode { get; private set; }
private Address() { }
public Address(string street, string city, string state, string country,
string zipcode)
{
Street = street;
City = city;
State = state;
Country = country;
ZipCode = zipcode;
}
protected override IEnumerable<object> GetAtomicValues()
{
// Using a yield return statement to return
// each element one at a time
yield return Street;
yield return City;
yield return State;
yield return Country;
yield return ZipCode;
}
}

Actually, I find it astonishing that Microsoft implemented a value type using a class. Usually, structs are much better for this purpose, unless your value objects get very large. For most usages of value types such as coordinates or colors, this is not the case.
Leaving this discussion aside, what happens here is the following: If you implement a value object, you need to implement Equals and GetHashCode correctly, which includes consistently to each other. However, these two methods are actually not very difficult but verbose to implement: You need to cast the object and then check each of its properties. In case you are using classes, you have an additional boilerplate factor which is the fact that you typically want to speed up equality check using the reference equality check. That is, two objects need not be the same to be equal, but if they are the same, then they are also equal.
The class you depicted here is an attempt to support this consistency problem and boilerplate problem for value objects that are using classes by abstracting away quite a few commonalities. All you need to provide are the fields that make up the identity. In most cases, these are simply all fields. You iterate them using a co-method.
Now, for the actual question of when EqualOperator and NotEqualOperator are actually called, I would guess they are simply helper functions to make the implementation of operators more easy: You would provide an overloaded == operator that simply returns EqualOperator and != that simply returns NotEqualOperator. You might ask why the value type base class does not have these operators? Well, I guess this is because this would mean that the compiler would allow you to apply == and != to different types of value objects using the overloaded operator.

JsonConvert.SerializeObject passes custom type properties to parent types Equals(object) method

I'm seeing some weird behavior serializing with Json.NET v6.0.5 for objects that override the Equals method and have reference type properties, aside from string.
public class TestObject
{
public ChildObject CustomTypeProperty
{
get;
set;
}
public List<string> ListProperty
{
get;
set;
}
public List<ChildObject> ListCustomProperty
{
get;
set;
}
public string StringProperty
{
get;
set;
}
public int IntProperty
{
get;
set;
}
public override bool Equals(object obj)
{
Console.WriteLine(obj.GetType().FullName);
return base.Equals(obj);
}
public override int GetHashCode()
{
return base.GetHashCode();
}
}
public class ChildObject
{
}
Then I serialize it.
var testObj = new TestObject() { CustomTypeProperty = new ChildObject(), IntProperty = 1, ListCustomProperty = new List<ChildObject>(), ListProperty = new List<string>(), StringProperty = "abc" };
var json = JsonConvert.SerializeObject(testObj);
I can see that it calls TestObject.Equals(object obj) three times and passes in not the TestObject, but the CustomTypePropety object, then the ListProperty and then the ListCustomProperty. In my case this causes an InvalidCastException because TestObject tries to cast the obj parameter to a TestObject. I cannot change this in the real-world scenario because the the type is in a third party library.
Is this a bug in Json.NET or am I doing something wrong? I've been digging for a while and cannot find any resolution. Thanks for the help.
EDIT
I just upgraded to Json.NET 6.0.6 and saw the same behavior.

If you are implementing an override for bool Equals(object obj) then you need to handle any type that might be passed to you. You cannot make the assumption that callers will always pass the type you are expecting. The usual solution is to do a simple type check before you cast, like this:
public override bool Equals(object obj)
{
if (obj is TypeYouAreExpecting)
{
TypeYouAreExpecting other = (TypeYouAreExpecting) obj;
bool areEqual = false;
// implement your equals logic here
return areEqual;
}
return base.Equals(obj);
}
If it is a third party library that throws an InvalidCastException in the Equals method, that is definitely a bug. I would contact the author and request that they fix it.
As for why Json.Net calls Equals during serialization on objects of different types, this is done to check for reference loops. See Why does Json.Net call the Equals method on my objects when serializing? for more details.

ICollection<>.Contains in EF as HashSet fails

I have an object defined as such:
public class QuestionSetAssignee
{
[Required]
public int Id { get; set; }
[Required]
public string Name { get; set; }
public virtual ICollection<QuestionSet> QuestionSets { get; set; }
public override int GetHashCode()
{
return Id.GetHashCode();
}
public override bool Equals(Object obj)
{
if (obj == null)
{
return false;
}
QuestionSetAssignee qsa = obj as QuestionSetAssignee;
return Id == qsa.Id;
}
}
The following statement:
QuestionSetAssignees.Contains(director)
in
public bool isEditable()
{
ApplicationDbContext db = new ApplicationDbContext();
QuestionSetAssignee director = db.QuestionSetAssignees.Find((int)QuestionSetAssigneeEnum.Director);
if (Conference.AcceptingDirectorApplications && QuestionSetAssignees.Contains(director))
{
return false;
}
return true;
}
returns false, when as far as i can tell is should return true. (Note: Conference.AcceptingDirectorApplications returns true)
In case it's not immediately clear, the director object and the HashSet objects come through as DynamicProxies (due to EF and object hierarchy).
Here is the director object:
(Click for larger view)
and here is the QuestionSetAssignees object:
(Click for larger view)
I do not have control over the type of QuestionSetAsignees as it is supplied by EF 6 (it is declared as an ICollection in the model. This also means I am unable to provide a compare object (well, as far as I know). All I want to do is be able to compare two QuestionSetAsignee objects. I have also tried implementing IEquatable, but that did not work.

The problem is it is turning your Contains() in to a SQL call so no matter what you put in Equals and GetHashCode() it won't matter because the database you are connecting to does not use them for testing equality (This is why "This" == "this" will return true when working with entity framework on a database who's collation is not case sensitive).
The "quick and dirty" way to fix it is to realize the collection in memory and then do the .Contains
QuestionSetAssignees.AsEnumerable().Contains(director))
But that will not give you very good performance. You will likely need to approach this query a different way so the SQL behaves like you want it to.
I think the following may work, but please test it and let me know if it does not, I will remove it.
QuestionSetAssignees.Select(assignee => assignee.Id).Contains(director.Id)

Associate a value with a subclass in c#

I have the following class and my question lies with it's GetComponent function
class GameObject
{
private List<GameComponent> _components = new List<GameComponent>();
public void AddComponent(GameComponent component)
void RemoveComponent(string name)
public T GetComponent<T>(string name) where T : GameComponent
}
class GameComponent
{
public string Name { get; set; }
}
So in GetComponent i want to get the component identified by name and return it as T.
So i would call
NavigationComponent navigation = gameObject.GetComponent<NavigationComponent>("navigation");
where NavigationComponent would be a subclass of GameComponent
Since each NavigationComponent instance is only ever going to have the same name, "navigation", i am pondering if i can do something to simplify the GetComponent to the following
NavigationComponent navigation = gameObject.GetComponent<NavigationComponent>();
Thanks in advance.
Update 1
Well i should mention that the GameObject works like a set of GameObjects, identified by their name, so there can be only one of each in it.
So to elaborate lets say we have
class SimpleNavigation : GameComponent {...}
class AdvancedNavigation : GameComponent {...}
class SensorSystem : GameComponent {...}
Then i would give SimpleNavigation and AdvancedNavigation the Name "navigation" and to the SensorSystem the name "sensor"
So i cannot have both SimpleNavigation and AdvancedNavigation in the above example.
Hope that makes sense.
Thanks in advance.
p.s. I fear that i might be placing too many constrains when there isn't much to gain and longterm the specifications might change, but that is outside of the scope of the question i guess

Firstly, if all NavigationComponents will have the same name, how will you distinguish between them? If you only want to return a single NavigationComponent, you will need a unique identifier.
You can use the OfType() method to return all instances of a type:
var navigationComponents = _components.OfType<NavigationComponent>();
From there, you can select a single NavigationComponent by some unique identifier:
NavigationComponent nc = navigationComponents.Where(n => n.Id == 1);

Rewritten:
You've mentioned that .Name should remain as a property on your GameComponent class--so one option to consider is overriding the equality operator to say "if two instances of GameComponent have the same name then they should be considered equal". Combined with Dave's suggestion of using OfType() you would have something like this:
class GameObject
{
private List<GameComponent> _components = new List<GameComponent>();
public T GetComponent<T>(string name) where T : GameComponent, new
{
return
(from c in _components.OfType<T>()
where c == new T { Name = name }
select c).FirstOrDefault();
}
}
class GameComponent
{
public string Name { get; set; }
public bool Equals(GameComponent other)
{
if (ReferenceEquals(null, other))
{
return false;
}
if (ReferenceEquals(this, other))
{
return true;
}
return Equals(other.Name, Name);
}
public override bool Equals(object obj)
{
if (ReferenceEquals(null, obj))
{
return false;
}
if (ReferenceEquals(this, obj))
{
return true;
}
if (obj.GetType() != typeof(GameComponent))
{
return false;
}
return Equals((GameComponent)obj);
}
public override int GetHashCode()
{
return (Name != null ? Name.GetHashCode() : 0);
}
}
It's worth thinking through whether or not you want to implement this approach--it will affect any equality-checks (not reference-checks). However it's a very powerful ability to say "X and Y should be considered equal when X"--and equality overloading lets you implement that logic in a single centralized home (right on the entity).

Update: In response to your edit:
Then i would give SimpleNavigation and
AdvancedNavigation the Name
"navigation" and to the SensorSystem
the name "sensor"
If this is the case, then you really can't hope to have an interface like this...
public T GetComponent<T>() where T : GameComponent { }
...because multiple GameComponent object types may potentially share the same name. So you cannot infer name from type.
Why not go with an enum instead? Then you might have something like this:
public enum ComponentType
{
Navigation,
Sensor // etc.
}
And your GameObject class could in turn hold a Dictionary<ComponentType, GameComponent>.
Then your GetComponent method could look like this:
GameComponent GetComponent(ComponentType type) { }
Anyway, it's a thought...
I think what makes more sense is this:
Firstly, if you're looking up by name, use a Dictionary<string, GameComponent> instead of a List<GameComponent>. This will give you O(1) lookup time instead of O(N).
Now, if you want name to be dependent on type, define your GameComponent class like this:
class GameComponent
{
public virtual string Name
{
// You could also hard-code this or cache it
// for better performance.
get { return this.GetType().Name; }
}
}
You might then choose to override the Name property in your derived methods, like so:
class NavigationComponent : GameComponent
{
public override string Name
{
// This returns the same thing as GetType().Name,
// but it's faster.
get { return "NavigationComponent"; }
}
}
Then your AddComponent method would be:
public void AddComponent(GameComponent component)
{
_components.Add(component.Name, component);
}
and your GetComponent method would be simple:
public T GetComponent<T>() where T : GameComponent
{
return _components[typeof(T).Name] as T;
}