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

14 lines
471 B
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">
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>
<Description>Generates C# typed bindings for .resx files</Description>
Use new value for `TargetFramework` as `net5.0` instead of `netcoreapp5.0` (#12486)
2020-04-27 17:40:09 +02:00
<TargetFramework>net5.0</TargetFramework>
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>resgen</AssemblyName>
<OutputType>Exe</OutputType>
Improve powershell startup time (#8341) Major changes are as follows: - Avoid `SecuritySupport.IsProductBinary` and unnecessary AMSI/suspicious code scan at startup time - Update `CompiledScriptBlockData.IsProductCode` to avoid unnecessary calls to `IsProductBinary`, which attempts to retrieve catalog signature of the target file. - Update `PerformSecurityChecks` to skip AMSI and suspicious code scan for the `.psd1` file that contains a safe `HashtableAst` only. - Use customized `ReadOnlyBag` instead of `ImmutableHashSet` so that we can avoid loading the `System.Collections.Immutable.dll` completely. - Replace `SHA1` with `CRC32` when generating module analysis cache file name - This remove the loading of `System.Security.Cryptography.Algorithms.dll` at startup - Move `ConvertFrom-SddlString` to C# to remove the `Utility.psm1` file. - Crossgen `Microsoft.ApplicationInsights.dll` and enable tiered compilation - Even pwsh with crossgen assemblies spends a lot time in jitting at the startup, about `191.6ms` comparing with `24.7ms` for Windows PowerShell. - Jitting `Microsoft.ApplicationInsights.dll` takes about `51.6ms`. - By crossgen `Microsoft.ApplicationInsights.dll` and enable tiered compilation, the jitting time drops to about `98.9ms`.
2018-12-02 21:52:39 +01:00
<TieredCompilation>true</TieredCompilation>
Port PowerShell to .NET Core 3.0 (#9597)
2019-05-21 07:43:51 +02:00
<TieredCompilationQuickJit>true</TieredCompilationQuickJit>
Update PowerShell to build with .NET Core SDK 2.1.300-rc1-008662 (#6718) * Build Update - Change `TargetFramework` to `netcoreapp2.1` and removed unnecessary `RuntimeFrameworkVersion` from `PowerShell.Common.props` - Update dotnet SDK to 2.1.300-rc1-008662 - Update `TypeGen` target in `Build.psm1` to work with 2.1 - Rename macOS runtime to `osx-x64` as the old build logic expects 10.12 and breaks running on 10.13 system. - Remove `PackageReference` to `System.Memory` as it's part of dotnetcore 2.1 - Update search for `crossgen` executable to find the matching version * Test Update - Update test tools `WebListener` to latest `asp.net core` - Marked `AuthHeader Redirect` tests as `Pending` due to change in CoreFX
2018-05-03 01:58:39 +02:00
<RuntimeIdentifiers>win7-x86;win7-x64;osx-x64;linux-x64</RuntimeIdentifiers>
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>
</Project>
Reference in a new issue Copy permalink