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.
This was left out of date as of #655. It is also needed to be a
subsection of the detailed build notes section.
Some typos and superfluous information were fixed.
The readme is getting quite large, so in an effort to shorten it, the
Git installation instructions (which have nothing to do with PowerShell,
but are helpful for new users), are now in `CONTRIBUTING.md`. Thus, if
someone is totally new to Git, they will be far more likely to review
our contributing guidelines, and so read our rules and best practices.
Cloning the source code was cleaned up so that initializing the
submodules is done in a separate step. This simplifies the first step,
making it more likely to succeed (and narrowing the possible failures).
Per dotnet/cli#1783, this should resolvePowerShell/PowerShell#638.
Unfortunately, per dotnet/cli#1839, the Ubuntu package feed is
out-of-date. So now Travis and AppVeyor aren't quite in sync. This is
not great, but the Ubuntu version of CLI does not have the same
regression that the Windows version had.
The readme has been updated to note how to install an actually
up-to-date copy on Linux.
If not specified, "deb" is used as default on Linux. This should be
updated to check the distribution and required package build
dependencies.
Dependency names switched per package type, since specific package names
are different. Should check if this causes an issue on OS X when the
names are empty.
This package contains the Windows runtime assemblies of packages that
are not actually supported on Linux. The assemblies exist in the Linux
runtime folder. While the code cannot be executed, this allows
PowerShell to use the Windows specific types in its function calls
without crashing (and allows compiling with these types in the first
place). This is *not* an ideal work-around, but we are waiting on a
better package from .NET that contains Linux runtime assemblies that
throw `PlatformNotSupported` exceptions on use.
OS X's ping command requires the flags to be specified before the
arguments. I also reduced the ping count so that the tests execute a bit
faster. This resolves#556.
- Exports the IsCore, IsLinux, IsOSX, and IsWindows variables
- Imported by the default PSL profile
- Can be used automatically in Pester tests and Open PowerShell sessions
- Should maybe become a default module once it is polished
- PowerShellGitHubDev module does not explicitly use it because on
FullCLR PowerShell (normal Windows development) it will not be
imported automatically
