Contributing: Either open an issue on the github page, or fork and send a pull request.
-
Calls to
GetType()on aNullable<T>instance always returnT, although the type isNullable<T>. -
Co/contravariance does not work on value types (i.e. in interface
ITest<out T>, if it is used with aTthat's a value type theoutkeyword has no effect). -
Type constraints are ignored when resolving method overloads. Calls to a method that has overrides where only one matches the current type constraints, are still considered ambiguous.
-
Array types
T[]implementICollection<T>and other incompatible interfaces. Arrays of T (T[]) "implement" some intefaces such asICollection<T>, but don't really implement them. Instead, the throwNotImplementedExceptionon methods they can't implement (such asAdd). -
Arrays are covariant despite being writable. In other words: you can assign
object[] x = new string[1]. If you then go ahead and dox[0] = new Something();you get an exception. Furthermore, as Jon Skeet explains, array covariance is not just ugly, but slow too. -
You can't combine getter and setter properties via interface inheritance. The compiler sees an ambiguity when trying to access a property "MyProp" when inheriting a setter from one interface, and the same property's getter from another interface. Properties are not like a pair of methods.
interface IGet { int Value { get; } } interface ISet { int Value { set; } } interface IBoth : IGet, ISet { } class Test { public void Bla(IBoth a) { var x = a.Value; // Error: Ambiguity between 'IGet.Value' and 'ISet.Value' } }According to Eric Lippert the reason is to simplify the compiler's implementation.
-
Comparing a class to an interface with
==always compiles, even if they are unrelated. Consider two unrelated classesAandBand variablesaandbof corresponding types. Using==, you can't comparea == b(fails compilation) - this is expected. Now consider an unrelated interfaceICand variablec- you can comparea == cdespite those types not matching. The reason is that there might be a classD : A, ICfor which the comparison will make sense. This should be at least a warning (apparently it is in VS >= 2012). -
Default parameters are compile-time substitutions, so if you change a parameter's default value without recompiling dependencies, they will still use the old value.
- Struct members cannot be protected (because structs cannot be inherited.)
- When comparing (using
==) a nullable to a non-nullable generic struct in an expression, you get a runtime error. The Connect issue explains that the bug is fixed in Roslyn, but will probably not be fixed in the current (old) compiler. - As explained in pitfalls above, co/contravariance does not work for value-type type parameters. However, the compiler will allow you to constrain a type parameter to be a value (
struct) resulting in a useless co/contravariance declaration.
- The
DateTime.Equalsmethod ignores.Kind, which makes the Equals method an unreliable of comparingDateTimes. As discussed in this SO question, the moral is not to use it at all.
- Bug (fixed in EF6): A LINQ query such as
where entity.str == myStringwhenmyStringis null, will always returnfalse- even if 'str' is a nullable column. (http://stackoverflow.com/questions/8090894/linq-to-entities-and-null-strings) This is because in SQL,[Column] = nullalways evaluates to false (to check for nulls you need[Column] is null). - DateTime loss of milliseconds resolution: The sql server type
datetimehas less resolution than the .NETDateTimetype. This means that if you save a DateTime value it won't be the same value when you read it back. EF is aware of this if you use '2005' for the SqlProvider manifest token which can be a bit tricky to do in Code First.
-
If a method parameter is not passed when calling a WCF service method, that parameter is initialized to some default value http://thorarin.net/blog/post/2010/08/08/Controlling-WSDL-minOccurs-with-WCF.aspx
-
Linq-to-SQL: Non-collection references between two entities (e.g. Division -> DivisionDeduction), is not serialized (no DataMember attribute is created on either side)
-
WCF service hosted in IIS: When defining custom error pages for some error codes, IIS will mask WCF exceptions and send the custom error page itself (despite this being a service).