@MichaelSimons I've removed the netcoreapp3.1 versions as they don't seem to be supported, and manually fixed up the missing internal refs that was causing it to fail.

Is that an acceptable way to resolve?

@chsienki - Can you explain in more detail what you meant by "netcoreapp3.1 versions as they don't seem to be supported"? I looked at the first commit's build failures and noticed an issue with the tooling that I just submitted a PR for.

I will regenerate the source with this fix and update this PR. Aside from that, there do appear to be a number of issues in the generated source that will need to be analyzed and corrected.

@chsienki - I see you made a number of hand edits already. Do you know if these are something we can tool? GenAPI is the underlying tooling being used.

I regenerated the source but did not re-add microsoft.codeanalysis.common and microsoft.codeanalysis.csharp 3.1 nor did I undo the hand edits.

Ideally the hand edits would be minimal so I am looking for input on how to generate these ref packages correctly. Having to make these many manual edits doesn't scale. Also we would ideally not be removing 3.1.

@MichaelSimons Ok, I'll see if I can update the tool to generate the correct files.

/azp run

Hi @chsienki, @andriipatsula is starting to look at the broader problems of reference source generation and we had a couple questions about the changes. It looks like the major changes from the generated source were:

• nullable types: were these causing problems when compiling?
• internal types: as we understand it these are required because GenApi doesn't create them and this assembly has several InternalsVisibleTo attributes for other Roslyn assemblies. Is that correct?
• CLSCompliant - this seems like a known GenApi issue.
• netcoreapp3.1 which wasn't needed in this use-case: do you know what problem this was causing?

Thanks!

This PR has been superseded by #416.