Add logic to generate type forwarding information to ECMAXML

[anmeng10101]

No description provided.

[dnfclas]

All CLA requirements met.

[anmeng10101]

@joelmartinez

I reused the methods in FXUtils to add/remove fx to/from list.

Since the changes will be cached, I am not sure it will impact the results return by PreviouslyProcessedFXString.

[joelmartinez]

ok, so in general, I would say that this code looks good ... however as discussed, there's a few improvements to the data and the algorithm:

• Add FromVersion and ToVersion parameters ... this will help in tracking down assembly resolution issues.
• Currently, this is using the "Update" methodology, which tries to maintain the existing XML if it already exists. This logic is difficult to maintain and prone to issues with edge cases.
• Moving to a process more like how the MDocUpdater.MakeParameters function works would probably be ideal. The important stages in that process are as follows:
  1. return early if typeEntry.TimesProcessed > 1
     • this can be relevant when a type is forwarded in an assembly but that assembly is in the framework folder, rather than in the dependencies folder. What happens is that the same type is inevitably processed more than one time in the same framework, which can cause issues in some cases.
  2. delete the whole list if typeEntry.Framework.IsFirstFrameworkForType(typeEntry) is true
     • this lets the algorithm begin fresh without having to make a bunch of stateful decisions. Please note that this is only relevant for XML nodes that do not have user content. So because this is information that comes from the metadata, we can process it this way.
  3. prepare state data
     • This is less of a technical reason, but more for making the algorithm easier to write.
     • It begins by making a datastructure of all relevant data in the current type (in the case of make parameters, it's the list of parameters in this type instance in this framework).
     • Then it gets a list of the current XML parameters (xdata) ... again, not really a technical reason other than organization
  4. syncing state
     • with the data from the previous step, this one becomes as simplified as:
     1. If the data doesn't exist ... add it (with FrameworkAlternate)
     2. If it does exist ... add the current framework to the FrameworkAlternate parameter
  5. There's a step here in the MakeParameters method that probably isn't relevant ... this is necessary here because Parameters are kind of unique in that they have to sync with related Docs/param nodes
  6. Lastly is the processing you do on the last instance of the type when typeEntry.Framework.IsLastFrameworkForType(typeEntry) is true
     • Here you just loop through all the XML elements, and compare the FrameworkAlternate value with typeEntry.Framework.AllFrameworksWithType(typeEntry) ... if they match, then you can confidently remove the FrameworkAlternate parameter from the XML node.

[joelmartinez]

Closing and re-opening to request new build after small update in develop branch for failing unit test

[joelmartinez]

This is very close :) After you address the comment, please squash your commits and this will be ready to go. Thanks!