maxmustermann/PowerShell
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
PowerShell/src/System.Management.Automation/System.Management.Automation.csproj

77 lines
4.1 KiB
XML
Raw Normal View History

Remove Unicode BOM from text files (#11546)
2020-01-11 08:15:34 +01:00
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
Add VS 2017 solution file for powershell-win-core (#4748)
2017-09-19 02:13:29 +02:00
<Import Project="..\..\PowerShell.Common.props" />
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<PropertyGroup>
Update use of "PowerShell Core" to just "PowerShell" (#9513)
2019-05-11 00:34:27 +02:00
<Description>PowerShell's System.Management.Automation project</Description>
Update PowerShell to build against dotnet 5.0-RC.1 (#13643)
2020-09-23 23:04:01 +02:00
<NoWarn>$(NoWarn);CS1570;CS1734;CA1416</NoWarn>
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<AssemblyName>System.Management.Automation</AssemblyName>
</PropertyGroup>
Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflict with 'System.Diagnostics.EventLog' (#10305) * Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflicts * Add reference to 'System.Diagnostics.EventLog' to build Microsoft.PowerShell.Commands.Diagnostics on Unix * Stop compiling Get/New-WinEvent on Unix
2019-08-08 14:44:54 +02:00
<ItemGroup Condition=" '$(IsWindows)' == 'true' ">
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<ProjectReference Include="..\Microsoft.PowerShell.CoreCLR.Eventing\Microsoft.PowerShell.CoreCLR.Eventing.csproj" />
Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflict with 'System.Diagnostics.EventLog' (#10305) * Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflicts * Add reference to 'System.Diagnostics.EventLog' to build Microsoft.PowerShell.Commands.Diagnostics on Unix * Stop compiling Get/New-WinEvent on Unix
2019-08-08 14:44:54 +02:00
</ItemGroup>
<ItemGroup>
add comments about where most of the packages are from (#6016)
2018-01-31 21:16:48 +01:00
<!-- the following package(s) are from https://github.com/JamesNK/Newtonsoft.Json -->
Bump Newtonsoft.Json from 12.0.3 to 13.0.1 (#15084) Bumps [Newtonsoft.Json](https://github.com/JamesNK/Newtonsoft.Json) from 12.0.3 to 13.0.1. - [Release notes](https://github.com/JamesNK/Newtonsoft.Json/releases) - [Commits](https://github.com/JamesNK/Newtonsoft.Json/compare/12.0.3...13.0.1) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2021-03-23 18:25:14 +01:00
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
Additional Telemetry - Implementation of `RFC0036` (#10336)
2019-08-16 01:13:53 +02:00
<!-- the Application Insights package -->
Bump `Microsoft.ApplicationInsights` from `2.18.0` to `2.19.0` (#16413) * Bump Microsoft.ApplicationInsights from 2.18.0 to 2.19.0 Bumps [Microsoft.ApplicationInsights](https://github.com/Microsoft/ApplicationInsights-dotnet) from 2.18.0 to 2.19.0. - [Release notes](https://github.com/Microsoft/ApplicationInsights-dotnet/releases) - [Changelog](https://github.com/microsoft/ApplicationInsights-dotnet/blob/develop/CHANGELOG.md) - [Commits](https://github.com/Microsoft/ApplicationInsights-dotnet/compare/2.18.0...2.19.0) --- updated-dependencies: - dependency-name: Microsoft.ApplicationInsights dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * Update cgmanifest.json Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Travis Plunk <travis.plunk@microsoft.com>
2021-11-10 00:48:06 +01:00
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.19.0" />
add comments about where most of the packages are from (#6016)
2018-01-31 21:16:48 +01:00
<!-- the following package(s) are from https://github.com/dotnet/corefx -->
Update to latest .NET 6 GA build ` 6.0.100-rtm.21527.11` (#16309)
2021-10-28 20:40:52 +02:00
<PackageReference Include="Microsoft.Win32.Registry.AccessControl" Version="6.0.0" />
<PackageReference Include="System.Configuration.ConfigurationManager" Version="6.0.0" />
<PackageReference Include="System.DirectoryServices" Version="6.0.0" />
<!--PackageReference Include="System.IO.FileSystem.AccessControl" Version="6.0.0-preview.5.21301.5" /-->
<PackageReference Include="System.Management" Version="6.0.0" />
<PackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="6.0.0" />
<PackageReference Include="System.Security.AccessControl" Version="6.0.0" />
<PackageReference Include="System.Security.Cryptography.Pkcs" Version="6.0.0" />
<PackageReference Include="System.Security.Permissions" Version="6.0.0" />
<PackageReference Include="System.Text.Encoding.CodePages" Version="6.0.0" />
add comments about where most of the packages are from (#6016)
2018-01-31 21:16:48 +01:00
<!-- the following package(s) are from the powershell org -->
Update dependencies from PowerShell Gallery and NuGet (#11323)
2019-12-12 00:21:03 +01:00
<PackageReference Include="Microsoft.Management.Infrastructure" Version="2.0.0" />
Update version of `Microsoft.PowerShell.Native` and `Microsoft.PowerShell.MarkdownRender` packages (#16277)
2021-10-20 02:31:57 +02:00
<PackageReference Include="Microsoft.PowerShell.Native" Version="7.2.0" />
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
</ItemGroup>
Move powershell to .NET Core 2.0 (#3556) This change moves powershell to .NET Core 2.0. Major changes are: 1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`. 2. Refactor code to remove most CLR stub types and extension types. 3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed. 4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded). 5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this. 6. Replace the use of some APIs with the ones that take `SecureString`. 7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12. 8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
2017-04-17 20:52:38 +02:00
<PropertyGroup>
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<DefineConstants>$(DefineConstants);CORECLR</DefineConstants>
</PropertyGroup>
Move powershell to .NET Core 2.0 (#3556) This change moves powershell to .NET Core 2.0. Major changes are: 1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`. 2. Refactor code to remove most CLR stub types and extension types. 3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed. 4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded). 5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this. 6. Replace the use of some APIs with the ones that take `SecureString`. 7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12. 8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
2017-04-17 20:52:38 +02:00
<ItemGroup>
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<Compile Remove="cimSupport\cmdletization\xml\cmdlets-over-objects.objectModel.autogen.cs" />
<Compile Remove="cimSupport\cmdletization\xml\cmdlets-over-objects.xmlSerializer.autogen.cs" />
<Compile Remove="engine\TransactedString.cs" />
<Compile Remove="engine\TransactionManager.cs" />
<Compile Remove="engine\hostifaces\NativeCultureResolver.cs" />
<Compile Remove="engine\hostifaces\RunspaceInvoke.cs" />
Remove 'Suspend-Job' and 'Resume-Job' cmdlets from compilation (#7650) The classes for the cmdlets are present but the Cmdlet attribute has been removed. There is no reason why we should be compiling these files, and it very slightly impacts our code coverage numbers.
2018-08-30 02:11:20 +02:00
<Compile Remove="engine\remoting\commands\ResumeJob.cs" />
<Compile Remove="engine\remoting\commands\SuspendJob.cs" />
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<Compile Remove="logging\eventlog\EventLogLogProvider.cs" />
<Compile Remove="namespaces\SafeTransactionHandle.cs" />
Move powershell to .NET Core 2.0 (#3556) This change moves powershell to .NET Core 2.0. Major changes are: 1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`. 2. Refactor code to remove most CLR stub types and extension types. 3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed. 4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded). 5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this. 6. Replace the use of some APIs with the ones that take `SecureString`. 7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12. 8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
2017-04-17 20:52:38 +02:00
<Compile Remove="namespaces\SafeRegistryHandle.cs" />
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<Compile Remove="namespaces\TransactedRegistry.cs" />
<Compile Remove="namespaces\TransactedRegistryKey.cs" />
<Compile Remove="namespaces\TransactedRegistrySecurity.cs" />
<Compile Remove="utils\BackgroundDispatcher.cs" />
<Compile Remove="utils\perfCounters\CounterSetInstanceBase.cs" />
<Compile Remove="utils\perfCounters\CounterSetRegistrarBase.cs" />
<Compile Remove="utils\perfCounters\PSPerfCountersMgr.cs" />
<Compile Remove="gen\CoreMshSnapinResources.cs" />
<Compile Remove="gen\ErrorPackageRemoting.cs" />
Redirect ETW logging to Syslog on Linux (#5144) 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
2017-11-06 17:32:29 +01:00
<Compile Remove="gen\EventResource.cs" />
Minor formatting commits for Build.psm1 and csproj files (#4630)
2017-08-22 00:23:52 +02:00
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
<EmbeddedResource Remove="resources\CoreMshSnapinResources.resx" />
<EmbeddedResource Remove="resources\ErrorPackageRemoting.resx" />
</ItemGroup>
Skip compiling the non-supported cmdlets on Unix in System.Management.Automation.dll (#6939) This is to keep the cache in InitialSessionState in sync with the actual available cmdlet types in System.Management.Automation.dll
2018-06-06 05:08:49 +02:00
<ItemGroup Condition=" '$(IsWindows)' != 'true' ">
Add back ADSI and WMI type accelerators (#7085)
2018-06-21 18:57:14 +02:00
<Compile Remove="engine\ExtraAdapter.cs" />
<Compile Remove="engine\ManagementObjectAdapter.cs" />
Refresh and enable the `ComInterop` code in PowerShell (#13304)
2020-08-08 01:24:10 +02:00
<Compile Remove="engine\ComInterop\**\*.cs" />
Skip compiling the non-supported cmdlets on Unix in System.Management.Automation.dll (#6939) This is to keep the cache in InitialSessionState in sync with the actual available cmdlet types in System.Management.Automation.dll
2018-06-06 05:08:49 +02:00
<Compile Remove="engine\remoting\commands\ConnectPSSession.cs" />
Remove 'Suspend-Job' and 'Resume-Job' cmdlets from compilation (#7650) The classes for the cmdlets are present but the Cmdlet attribute has been removed. There is no reason why we should be compiling these files, and it very slightly impacts our code coverage numbers.
2018-08-30 02:11:20 +02:00
<Compile Remove="engine\remoting\commands\CustomShellCommands.cs" />
<Compile Remove="engine\remoting\commands\DisconnectPSSession.cs" />
<Compile Remove="engine\remoting\commands\ReceivePSSession.cs" />
Skip compiling the non-supported cmdlets on Unix in System.Management.Automation.dll (#6939) This is to keep the cache in InitialSessionState in sync with the actual available cmdlet types in System.Management.Automation.dll
2018-06-06 05:08:49 +02:00
<Compile Remove="engine\remoting\commands\TestPSSessionConfigurationFile.cs" />
</ItemGroup>
Migrate from project.json to MSBuild (#3398) - FullCLR build is disabled in this change. - FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts. - `dnxcore50` and `portable-net5+win8` target framework monikers are removed. - Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time. - I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400 The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information. Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
2017-03-23 21:04:52 +01:00
</Project>
Reference in a new issue Copy permalink