CMake will now output the artifacts of the native build into the
ConsoleHost project, where .NET CLI picks it up as content and deploys
it automatically.
This is a breaking change that requires developers to update their
version of .NET CLI. In order to stop specifying where dotnet should
output the artifacts, we need to be able to guess their location
correctly, which requires knowing the current RID (and framework).
This is a breaking that stops publishing PowerShell by default, and
instead relies on `dotnet build`. Thus the artifacts will be output to a
new (RID, framework, and project dependent) location.
Publishing will still be needed to produce packages, but this logic will
be moved into `Start-PSPackage`.
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.
Note that we leave the ps1xml file parsing code alone in monad, as
third-party code may use the InitialSessionState interfaces directly and
thus ask for these files to be parsed. The removal of these files is a
pure performance work-around, where instead of parsing the XML, a
pre-parsed C# version of the file is loaded.
When executing a single command block, two bugs existed.
1) Exceptions were not reported, instead it core dumped
2) The error code was not set, instead 0 was returned
Fixing 1) required calling `Execute` instead of `ExecuteHelper` as the
latter handles exception through `ReportException`.
Fixing 2) required setting the listener's error code when an exception
was thrown, and resetting it for each command when an interactive
session is running.
