Fix#5260 - with this fix folks shouldn't hit the version mismatch check.
The approach is to see if the dotnet in the current PATH has a compatible SDK. Folks will have a globall installed dotnet if they've installed VS, VSCode C# ext or have installed the .NET Core SDK. This verion may not have the SDK required by PSCore. And the global cannot see user local dotnet SDK installs. So if the global dotnet doesn't have the right SDK, we prepend the path to the user's local dotnet dir.
Also, updateed $dotnetCLIRequiredVersion to read its value from global.json so there is one less source of the truth (for the SDK version).
- Build PowerShell.Core.Instrumentation.dll - Resource-only binary for the ETW resources.
- Create a registration script for registering/unregistering the ETW provider.
- Revert refactoring changes so that it doesn't break remoting to Windows PowerShell 5.1
- Fix the rest of the supported types for remoting
- Put remoting sensitive private members in a descriptive region
This PR is divided into the following areas:
1. Add/Rename the PowerShell/Windows ETW manifest to the repo and change both the provider id (guid) and name. See #4939.
The manifest is at tools/resxgen/PowerShell-Core-Instrumentation.man
2. Generate a resx file containing the string resources needed for logging ETW events to syslog.
This is accomplished by tools\resxgen\resxgen.psm1 and resxgen.ps1. The tool generates two files
A resx file containing string resources for each message string from the manifest. This is generated in the System.Management.Automation\gen directory.
A C# class (EventResource) that provides the mapping between the integer event id and the associated string resource name. The file is generated in the System.Management.Automation\CoreCLR directory with a compile-time condition of UNIX
NOTE: The EventResource.cs class generated by resgen is explicitly ignored in the csproj file; it is not used.
3. SMA\utils\tracing\PSSysLogProvider.cs
Implements the abstract LogProvider class and is the syslog equivalent of PSEtwLogProvider. The class contains a number of logical methods for logging lifecycle, health, and normal events.
4. SMA\utils\tracing\SysLogProvider.cs
This is the Syslog equivalent of ETW's log provider class and implements a Log method versus ETW's EventWrite. It is also responsible for resolving event ids to resource names and performing the Syslog call. There is a large comment block in the class XML doc that describes the types of log output it produces.
5. SMA\utils\tracing\PSEtwLog.cs
PowerShell's current implementation is tightly coupled to this class; with code calling it directly for all events. To simplify integration of syslog, I updated the class to create an instance of PSSysLogProvider on Linux and removed the Linux-specific stub file.
6. SMA\engine\PropertyAccessor.cs
This class provides a wrapper around PowerShellProperties.json and has been extended to have Unix-specific assessors for configuring logging. Note that the file is expected to be in the $PSHOME directory to ensure SxS.
Currently, there are four configuration properties:
- LogIdentity - the string identifier for the source application. This defaults to 'powershell' and can be configured to enable distinguishing between side-by-side installations.
- LogLevel - configures the tracing level (log level). Informational is the defauilt.
- LogChannels - used to enable operational and analytic logging. Operational is the default.
- LogKeywords - used to configure enabling tracing by keyword. All keywords other than `UseAlwaysAnalytic` are enabled by default.
NOTE: This will likely change. PowerShell sometimes confuses the analytic channel with this keyword and sends logging to the wrong channel. Once this is cleared up, `UseAlwaysAnalytic` and `UseAlwaysOperational` keywords will likely be removed.
Additional Notes:
1. The current implementation writes directly to syslog and writing to a separate log file is still pending.
2. The generated class and resx are not part of the build; instead, it is expected that Resxgen should be run when events are added to the manifest. To fully automate the process, resxgen will need to be updated to generate the other dependent enums such as 'PSChannel', 'PSEventId', 'PSTask', 'PSOpcode', etc. You will see parsing logic in resxgen.psm1 to prepare for that but it is not enabled at this point.
4. Documentation is pending that documents the format of the syslog output as well as associated configuration.
5. As mentioned at the start, tests are pending
- Update `installpsh-suse.sh` to work with the .tar.gz binary archive.
- Remove `download.sh` as it's not used anywhere now. (checked with PowerShellGet and OneGet, they are using a local copy of download.sh).
* Add Remove-Alias Command. Add Remove-Alias Test. Add Remove-Alias to .psd1.
* Fix code-formatting. Fix ErrorAction on Remove-Alias instead of preference variable. Remove unnecessary Get-Alias calls. Switch Force parameter to auto property. Add ValueFromPipeline to Remove-Alias Name parameter.
* Remove empty lines. Add Remove-Alias to Unix Module .psd1. Add Remove-Alias to approved Commands test. Remove Try/Catch for SessionstateException. Add WriteError for aliasnotfound exception.
* Add ErrorAction Stop to all Get-Alias and Set-Alias Cmdlets in all tests for consistency. Add Should BeNullOrEmpty to "should throw if alias does not exist" test to verify that foo alias really is not there before removing it.
* Changed Remove-Alias parameter Name to String-Array. Changed Cmdlet Process Logic to work with String Array. Added Alias named "ral". Added test case for Alias "ral". Added "ral" Alias to list of approved Aliases. Replaced foo and bar values in all tests with better names.
* Remove "ral"-alias test as this is covered in DefaultCommands.Tests.ps1. Add test for removing multiple alias at once. Fix wrong curly braces positioning.
* Remove $FullCLR in DefaultCommands.Tests.ps1 for Remove-Alias and "ral" alias.
* Add Alias "ral" to Remove-Alias Cmdlet.
* Remove "ral" alias as this is handled by using the [Alias()] attribute on the Remove-Alias Cmdlet.
* Replace alias names used in Remove-Alias Cmdlet tests with GUIDs to avoid collisions
This replaces the code that scanned a script block for suspicious strings.
The previous implementation:
* Tokenized input (generating many strings for garbage collection)
* Used multiple threads
This approach is based on Rubin-Karp and does not allocate any memory
other than a small array to hold the running hash values.
I tested the new and old approaches on 2200 files in the PowerShell repo.
The old code ran in about 1.8-2.1s (ignoring time spent reading files)
The new code runs in about 0.6s and is more stable due to no garbage.
small fixes found while doing current work item
-replace expects a regex when I wanted to do a literal replace.
Have Sync-PSTags fix any issues it find
Using the assembly name to hint at the source of the classes was
problematic in multiple ways.
This change stores the actual filename in an attribute on the assembly.
So for a given type, one can get the assembly this way:
[SomeType].Assembly.GetCustomAttributes() |
? { $_ -is [System.Management.Automation.DynamicClassImplementationAssemblyAttribute] } |
% { $_.ScriptFile }
Since DCOM is not supported in corefx there was a great deal of dead code in the computer cmdlets.
This PR removes all vestiges of DCOM support from:
- Rename-Computer
- Restart-Computer
- Stop-Computer
removing about 4500 lines of dead code. Also, tests are updated to provide more complete coverage.
I also removed test-connection completely to make way for @iSazonov upcoming PR to improve coverage in tests, I created some test hook code which will test the cmdlet code without actually calling the WMI method to restart/rename/stop the system
Previously we used IScriptPosition for context (e.g. error reporting)
during parameter binding, but in some cases we want more information, so
we'll use the Ast instead.
This change just adds the Ast, it doesn't make explicit use of it.
