Error when performing LINQ query with equals in Where enclosure

Question

When executing the query below:

public ActionResult GridViewPartial()
    {
        if (Session["cod_cli"] != null)
        {
            int cod_cli = Convert.ToInt32(Session["cod_cli"]);

            //var model = db.DadosTecnicos;

            var model = (from s in db.DadosTecnicos
                        where s.id_cliente.Equals(cod_cli)
                        select s).ToList();

            return PartialView("~/Views/DadosTecnicos/_GridViewPartial.cshtml", model);
        }
        else
        {
            return RedirectToAction("Login", "Account");
        }
    }

The error is returned:

However, if I replace the Equals for == works.

But why?

Answer 1

If you want to test the equality of some object you should use the equality operator which is the == that operates on that type. The method Equals() tests the equality of the object according to the hierarchy. It will not always execute what it expects, unless it dominates the functioning of the language.

I’ve actually already answered the difference between them in What is the difference in the use of the Equals method for the operator ==?. Has a complement in another answer. Just use the Equals() with arguments that should operate only on the type, even so sparingly, understanding if this will not have some side effect.

When you use a LINQ expression that will be converted to something else, like SQL, the access provider can interpret each of them differently. In this case the vendor is transforming the C# equality operator into the SQL equality operator. When it finds a Equals() What should it turn into? This method is not necessarily equal to the operator. It may not even operate as the expected type since it is virtual, it even knows if it can turn into equal operator. Maybe you know you can, but the compiler can’t.

The method is never better than the operator unless it has a clear and substantiated justification for this. It should not follow actions. I’ve seen the AP accept an answer that teaches use Equals(). There’s a case that works, but it’s almost a coincidence.

That’s what I’ve been repeating over and over again:

Right always works, what works can only work in that case, with that data, in that situation. Perhaps the biggest mistake that programmers make and many never learn is that working is the worst thing that can happen to you, because it passes the feeling of duty accomplished even if the opposite is occurring.

Often the answer you used Equals() worked out there, but taught wrong. There’s a lot of accepted answer on the site that is wrong. That is why I trust little in acceptance and more in voting, although this is increasingly flawed as well, and its inherent flaw since it may be biased towards the response that was given earlier.