So we're sure this will end in \r\n because when you use git on Windows, and it checks out https://github.com/flutter/flutter/blob/master/packages/flutter_tools/templates/app_shared/windows.tmpl/CMakeLists.txt.tmpl, it will auto convert \n -> \r\n, or is there some other OS-level magic? Or are there some configurations of git that might lead to this file having only \n between lines?

Or, do we know this must have \r\n because otherwise windows cmake will explode?

Good question. Somehow this has \r\n line endings on my computer, let me investigate how that happens.

It turns out it's because I've enabled autocrlf globally on git. This converts my Flutter SDK's template files from LF to CRLF on checkout. It's likely most users have LF line endings, so we should support that as well.

I'm gonna be out for a week, however this change LGTM provided we're confident it will work no matter which settings they have in their windows git config :)

to clarify, we only want to do any migrations if BOTH of these files exist?

Yup. I'd like to make this migration conservative and only run on projects that are clearly safe. If one of these files is missing, it indicates the app has done non-trivial changes to its runner.

That said, this migration should be safe even if one file is missing: each file's changes are backwards compatible and would work even if the other file's migration wasn't applied.

Is there a docs page we can point people to when this fails, so they can do it by hand if desired? If so, in addition, log something like "For more information see: URL".

I added some more information to the trace to make it more actionable. This failure scenario seems unlikely (it wouldn't be unreasonable for flutter build windows to break if the runner's CMakeLists.txt file was missing), so I don't think it warrants a dedicated docs page.

Would it be preferable to put these long hardcoded strings into their own file(s)?

Prior art also hardcodes strings inside the migration itself:

I can move this to another file if folks feel strongly about this.

I weakly would prefer it inlined to make it easier to grep for a string and then see the usage within the tool.

Even though it's private, consider adding a doc comment stating what this does. The name sounds like it might have to do with replacing window resources of some sort (if such a thing exists).

Do we already have a _replaceFirst? I'd be tempted to just name it that, since that's what it does. That it handles windows line-endings is more of an implementation detail.

Updated! Let me know if you have additional feedback here!