maxmustermann/PowerShell
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
PowerShell/src/Microsoft.PowerShell.Commands.Utility/Microsoft.PowerShell.Commands.Utility.csproj

41 lines
1.7 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 Microsoft.PowerShell.Commands.Utility project</Description>
Update PowerShell to build against dotnet 5.0-RC.1 (#13643)
2020-09-23 23:04:01 +02:00
<NoWarn>$(NoWarn);CS1570;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>Microsoft.PowerShell.Commands.Utility</AssemblyName>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\System.Management.Automation\System.Management.Automation.csproj" />
Use `Microsoft.PowerShell.MarkdownRender` package from `nuget.org` (#14090)
2020-12-09 21:29:45 +01:00
<PackageReference Include="Microsoft.PowerShell.MarkdownRender" Version="7.2.0-preview.2" />
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="singleshell\installer\MshUtilityMshSnapin.cs" />
<Compile Remove="gen\UtilityMshSnapinResources.cs" />
<Compile Remove="gen\ConvertFromStringResources.cs" />
<Compile Remove="gen\ConvertStringResources.cs" />
<Compile Remove="gen\FlashExtractStrings.cs" />
<Compile Remove="gen\ImmutableStrings.cs" />
Enable Send-MailMessage on CoreCLR (#3869) * Enable Send-MailMessage for PowerShell Core * Update cmdlet entry in DefaultCommands.Tests.ps1 * Changes per code review: * Add check for SMTP server * Send mail to/from currently logged-in user on currently-named machine * Do not try to clear/create the mailbox before the test * Add validation of Subject
2017-06-20 03:19:25 +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\UtilityMshSnapinResources.resx" />
<EmbeddedResource Remove="resources\ConvertFromStringResources.resx" />
<EmbeddedResource Remove="resources\ConvertStringResources.resx" />
<EmbeddedResource Remove="resources\FlashExtractStrings.resx" />
<EmbeddedResource Remove="resources\ImmutableStrings.resx" />
</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
<ItemGroup>
Bump Microsoft.CodeAnalysis.CSharp from 3.7.0 to 3.8.0 (#14075) Bumps [Microsoft.CodeAnalysis.CSharp](https://github.com/dotnet/roslyn) from 3.7.0 to 3.8.0. - [Release notes](https://github.com/dotnet/roslyn/releases) - [Changelog](https://github.com/dotnet/roslyn/blob/master/docs/Breaking%20API%20Changes.md) - [Commits](https://github.com/dotnet/roslyn/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
2020-11-13 04:33:53 +01:00
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.8.0" />
Bump .NET to version `5.0.100-rtm.20526.5` (#13920)
2020-11-03 01:51:35 +01:00
<PackageReference Include="System.Threading.AccessControl" Version="5.0.0" />
<PackageReference Include="System.Drawing.Common" Version="5.0.0" />
Bump `NJsonSchema` from `10.2.2` to `10.3.1` (#14040)
2020-11-13 23:19:30 +01:00
<PackageReference Include="NJsonSchema" Version="10.3.1" />
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>
</Project>
Reference in a new issue Copy permalink