Using migStatus="delete"

migStatus="delete" causes the tool to not author any statements that reference the affected member – this means the ENTIRE STATEMENT that referred to the deleted member is REMOVED without a trace!   As expected, removing entire statements from the code and not replacing them with something that is semantically equivalent dramatically alters the behavior of the system.  This is a quick and dirty (very very dirty) way to remove dependencies on legacy APIs, but it is typically a very temporary simplifying technique. 

For example the commands below remove critical members of the farpoint spread control; removing the statements that use these members will certainly break the application and at the least they must be marked with an UPGRADE_TODO so that we can make sure they are revisited for a functional solution.

In its final form, the migration configuration will use migStatus="delete" only in situations where the deleted statements that referred to the member have been verified as no longer needed or have been replaced by some other equivalent operation.  For example, in a few simple cases, the replacement component provides for the legacy operations as part of its default behavior so no explicit invocation of the replacement control is needed.   Even in these simple cases, you must be very careful when using migStatus="delete" because doing so "can throw the baby out with the bath water" if the member was used in a complex statement involving other operations that should be retained.  In most cases, references to legacy component members cannot simply be deleted so migStatus="delete" is not valid.  In these cases the migration specialist needs to design some other way to implement the legacy component operations; if it is not one to one, then either one must derive and extend a replacement component to support the old member behavior, or one must restructure the application code to make provide for the legacy behavior in some other way.  If the application code must be significantly altered, you have several choices:

1)      Use author/fix./replace command(s) to modify the generated code using a simple search and replace paradigm, a regex replace technique is also possible with replace@status="regex", or even a the replaceFile command.

2)      Use refactor/reauthor command to replace entire methods

3)      Implement a migration DLL to do things like inspect and modify the pcode level or to dynamically select different .NET code patterns

Another key point to understand about migStatus="delete" is that it should only be used to remove member references from the logic sections of the code; it should not be used to remove property initializations in designer code as those initializations can be more precisely controlled by a designer migClass in the refactor library such that only the properties explicitly named in the migClass are authored. 

NOTE: migStatus=delete on an IDF member is different from migStatus=delete on a <refactor/remove>.  In refactor/remove migStatus=delete tells the tool to delete both the implementation and the calls from the application code.  As opposed to <refactor/remove> with migStatus=stubOut, which stubsout the implementation of the indicated method, but leaves the calls intact.