CLR Design-Time Breaking Changes

Short Description	Aligning TlbeExp behavior with run-time behavior
Affected APIs	TlbExp	Severity	Very Low	Compat Switch Available	No
Description	The exporter allowed UnmanagedType.LPArray on fields, however the marshaler does. I changed the exporter to disallow this as well. I don't consider this to be a breaking change since this didn't really make any sense and furthermore this is only a compile-time breaking change. The exporter allowed fixed array fields without a SizeConst, however the marshaler does. I again changed the exporter to disallow this. The exporter allowed value classes with an invalid UnmanagedType specified via MarshalAs, however the marshalers do. I again changed the exporter to disallow this. The exporter allowed classes with layout with an invalid UnmanagedType specified via MarshalAs, however the marshalers do. I again changed the exporter to disallow this. The exporter exported classes with layout fields as pointers to structs while the field marshaler considers these to be embedded structs. I changed the exporter behavior to match the marshaler behavior. The exporter didn't do any validation for System.Array's marked with [MarshalAs(UnmanagedType.SafeArray)]; however it does now. System.Array fields without a SafeArraySubType are exported as SAFEARRAY(VARIANT); however, at run time, they are marshaled as SAFEARRAYs of the type specified in the array. I added a warning in the exporter since this means these fields are not usable from COM as defined in the TLB.
User Scenario	A developer had incorrectly specified the marshalling behavior for method calls in a type and exports it. Previously the exporter would allow the type to be exported, but if the methods were ever used a run-time exception would be generated. Now the developer knows at export time there is a problem and can fix it then, instead of finding out about it when the method is used
Work Around	Since none of the declarations that are now dissallowed could have been used those method calls can be labeled ComVisible=false and they would not be exported. The exporter will tell developers why the export failed, so if they choose they can fix the incorrect definitions and their types will export properly AND be usable.

 

Short Description	New String.Split overloads make certain existing calls ambiguous
Affected APIs	String.Split(char[],int)	Severity	Very Low	Compat Switch Available	No
Description	We've added new overloads to String.Split which take an enum, StringSplitOptions. In VB, an overload that differs only by enum or int (that is, there are two overloads, one which accepts an int, and the other that accepts an int enum in the same parameter location) cannot be resolved successfully if another argument accepted an array, and the call to the array argument is simply passed as a single instance of a type of the array, and you get an ambiguous match error.
User Scenario	Someone uses String.Split(char(), int) and recompiles the code on V2.0. The code now receives an ambiguous call error.
Work Around	Change the first argument passed to this call from a single instance of a char, to a new char(). For example, instead of passing String.Split("-", 2), call String.Split(new char() {"-"}, 2).

 

Short Description	System.DirectoryServices.SearchWaitHandler class is removed
Affected APIs	System.DirectoryServices.SearchWaitHandler	Severity	Medium	Compat Switch Available	No
Description	The type SearchWaitHandler was public in V1.1. Since this type only backs a config file setting, it's a type that doesn't appear anywhere else, there are no references to it anywhere in the code and it isn't useful to consumers.
User Scenario	No valid scenarios
Work Around	None