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 | ||||