Sync Csc invocations from CoreCompile to XamlPreCompile

[rainersigwald]

The Csc task invocation in XamlPreCompile has drifted from the one in CoreCompile in the Roslyn repo. I'm attempting to bring them back into sync.

This will fix #9785.

I did this in two parts to make future updates easier:

• 18671e8 is a clean copy/paste of the Csc & Vbc calls from Roslyn.

• The subsequent commit modifies them to (hopefully) have the differences we expect here.

In the future, we can update from Roslyn by syncing to caa45ea, making a new commit of a clean update copy/paste of the task, and then merging with the subsequent edits.

[rainersigwald]

@jaredpar Here are some comments on the changes I'm proposing from CoreCompile. Would love to get compiler team review on them please.

[rainersigwald]

My reasoning here is that embedding stuff is for final outputs and isn't needed here. Should we explicitly pass false/empty though?

[jaredpar]

I think it's important that we keep all of the properties in <Csc here. That way when we look at the targets file we can quickly assert whether or not properties are missing.

[rainersigwald]

I assume this isn't relevant to the precompilation step but would like confirmation.

[jaredpar]

Unfortunately everything but FileAlignment is necessary. The rest all impact compilation success / failure.

[rainersigwald]

Should we keep PublicSign?

[rainersigwald]

I think ref assembly outputs aren't useful here.

[rainersigwald]

I don't know why this was using the old @(ReferencePath) before. Scared to change it but filed #9787.

[rainersigwald]

Definitely need to not be RefOnly--should we explicitly pass false?

[rainersigwald]

Not sure what this does, should it run in this context?

[rainersigwald]

Likewise SkipCompilerExecution seems like it wouldn't be necessary.

[rainersigwald]

These feel like they belong only in final outputs so no need to pass them here, right?

[rainersigwald]

This shouldn't have been there right? We don't generally want to produce symbols for the Xaml precompilation.

[jaredpar]

Logically yes I agree there is no reason for PDB to be produced here. At the same time what is the best way to do this? I think controlling DebugType="None" is the more holistic approach then also pass an empty string here.

[jaredpar]

@RikkiGibson, @chsienki, @jjonescz FYI

[RikkiGibson]

I do not think I understand what the XamlPreCompile step is doing well enough to say which arguments can be left out or not. I would lean toward including all the same arguments from the original task invocation from Roslyn as much as possible, except for those where there is a specific detrimental effect to keeping them.

[jaredpar]

@RikkiGibson part of my motivation for pinging is making you all aware that this exists. It was something I was unaware of.

I would lean toward including all the same arguments from the original task invocation from Roslyn as much as possible, except for those where there is a specific detrimental effect to keeping them.

Largely agree. I'm okay with a few items like disable PDB generation but overall would keep same where possible. In cases we do change arguments would use explicit values vs. implicit defaults to make it clear the item was considered.

[rainersigwald]

Largely agree. I'm okay with a few items like disable PDB generation but overall would keep same where possible. In cases we do change arguments would use explicit values vs. implicit defaults to make it clear the item was considered.

This makes total sense and I've just tried to do so. I think it's probably best at this point to try an experimental VS with this contents and validate that we can build some WPF projects--I'll do that. Marking this as "draft" until that's done.