Copy satellites in deployment script#5260
Conversation
| FileToCopy "$bootstrapBinDirectory\en\Microsoft.Build.resources.dll" "en" | ||
| FileToCopy "$bootstrapBinDirectory\en\Microsoft.Build.Tasks.Core.resources.dll" "en" | ||
| FileToCopy "$bootstrapBinDirectory\en\Microsoft.Build.Utilities.Core.resources.dll" "en" | ||
| FileToCopy "$bootstrapBinDirectory\en\MSBuild.resources.dll" "en" |
There was a problem hiding this comment.
Do we need en resources? I thought they were always embedded as default?
There was a problem hiding this comment.
That was my understanding as well until I got missing resource failures. I also deployed release bits, maybe those behave differently. I vaguely remember at some point, some email thread, where somebody suggested we don't treat en resources any differently to capture more possible bugs, so maybe I actually implemented that but forgot :)
And whatever scheme we had in the past, probably got replaced by whatever the xliff package is doing.
| ) | ||
|
|
||
| Set-StrictMode -Version "Latest" | ||
| $ErrorActionPreference = "Stop" |
There was a problem hiding this comment.
Wishlist item that may be too hard to implement: Building out the error functionality to delete the folder that was generated for this particular build, or essentially "reset" to the original binaries.
There was a problem hiding this comment.
I restore original binaries by adding the VS msbuild bin dir under git, committing before I deploy, and doing a checkout and clean to restore. And then I have to restore and commit for each VS update, which gets a bit annoying, but alas, that's the VS design for ya. If I were to implement restoration of original binaries, that's how I would do it. But I'd rather not do it in this PR :)
3 participants
Extracted this from #5222
When I tried the deployment script msbuild failed not finding the satellite assemblies. Apparently this happens when you're testing msbuild bits with new resources.