So that the resource manager doesn't try to load a non-existent
satellite assembly (and thus throw).
The culture `en-US` is the default `CurrentCulture` on all platforms I
tested, specifically not `en`.
Note that there is a problem with the FullCLR build where some other
assembly is still attempting to reference `Logging.resources` instead of
`System.Management.Automation.Logging.resources`.
Specifically this enables us to leverage `dotnet-resgen` to
auto-generate the `resx` files into `resources` files for the default
culture, which are then compiled into the SMA assembly.
This requires a change to the C# bindings. The Windows build system
takes `file.resx` and compiles `file.resources`, but CLI prepends the
assembly name, thus compiling `SMA.file.resources`. So the resource
manager in the generated bindings must be adjusted to look for
`SMA.file` instead of `file`.
Note that C# bindings cannot yet be auto-generated.
Given localized resources of the form `file.en-US.resx`, `dotnet-resgen`
will create a satellite assembly and publish it to
`en-US/SMA.resources.dll`, so #666 will not be a technical problem.
If a runtime is given, we need to restore for that particular runtime as
well.
This also enables `Warning` `dotnet restore` output, and increases the
verbosity to `Info` if `-Verbose` is used.
No longer necessary to restore/build. Removing them allows NuGet to
restore only the packages necessary for the current platform, vastly
reducing cache sizes and restore time.
My `~/.nuget/packages` directory was almost 1GB smaller with this
change.
The primary reason to do this is that the VS Code debugger is not
compatible with rc2.
Secondarily, we want to continue tracking CoreCLR/FX master branch,
which means to continue with the latest release candidates. Since we are
releasing in August, we will be able to pick up the converged RTM
version before release.
The only advantage of rc2 is that it is frozen; but we have this anyway
because we snap to particular builds.
This enables building PowerShell through VS Code. The build task
launches the installed version of PowerShell and runs
`Start-PSBuild` (after importing the module).
This enables a `launch` debug task to immediately debug the `powershell`
process, without having to attach to an external process.
The defaults of `justMyCode` and `stopAtEntry` have been reversed, so
that all code is debugged, and the process is stopped at entry for
easier debugging.
Note that an interactive PowerShell process requires access to `stdin`,
which the debug console does not provide, so once it requests access,
`System.Console` will throw a (correct) exception.
This bug arose because of a shortcut previously taken when generating
input for the type catalog generator. With a proper parser created, the
input to the generator is now correct, and so this test should succeed.
