Appveyor.psm1 needs to be updated:
https://github.com/PowerShell/PowerShell/blob/master/tools/appveyor.psm1#L166
https://github.com/PowerShell/PowerShell/blob/master/tools/appveyor.psm1#L322

Yeah - had the changes, but didn't hit save.

I noticed ScheduledJobs in the list. Those cmdlets are targeted for porting, so they should remain.

Thanks - I put those files back - sorry that I rewrote history to do that, it seemed much easier that way though.

At one time, we were running our existing internal lab tests against our github build. While this hasn't happened for some time, I was hoping that we would be able to do that again. With this change we are no longer going to be able to do this. Is that right?

Correct. The trade-off here is time is being spent maintaining this code today (it has cause problems that required investigation) and will require work in the future (moving to msbuild). In return, what do we lose?

I don't recall internal lab runs finding any bugs that were common to PowerShell Core and Windows PowerShell (there may have been a small number, but they didn't stick with me, so maybe not noteworthy.)

I do recall bugs specific to how we were building Windows PowerShell out of github - bugs that would not exist when building Windows PowerShell using the internal build process.

So the thinking here is that we can provide more value to our customers by focusing on PowerShell Core here by not spending any time on Windows PowerShell. For example, if we truly believe internal tests are valuable and not easy to port, getting them to run against PowerShell Core might be a better investment, especially as it may help getting those tests running out of github.

WRT bugs found, @vors might recall, as he did all of that work. There is value in those historical tests, but it's hard to quantify how much value as they need to be inspected. I am just looking for the appropriate people to sign off on the fact that we won't be running these tests until they're available in github. To date, they've acted as a security blanket, but in actuality not providing much surety because we actually haven't been running them. Removing the windows build just makes that explicit, which is fine as long as everyone is aware of this effect.

In reply to: 278485996 [](ancestors = 278485996)

We should also remove all exclude sections. Note that some of them represent resources (files in gen). You may want to remove .resx files for them too.

Not needed now - the msbuild PR supersedes this work, well the building part, we could still delete some of the code that isn't built.