- `ConvertFrom-Markdown` is used for converting a markdown document or string to a MarkdownInfo object. It can optionally return an HTML or a VT100 encoded string in addition to an AST of the markdown document.
- `Show-Markdown` is used to either display the VT100 encoded string on the console or redirect the HTML string to the browser.
- `Set/Get-MarkdownOption` cmdlets are used to view or set markdown rendering options.
* update to latest package references
* update runtime framework
* update sdk
* automatically read NuGet package dependency info from csproj, where version info is fully qualified
* update file.wxs
ConvertFrom-Markdown is used for converting a markdown document or string to a MarkdownInfo object.
It can optionally return a HTML or VT100 encoded string in addition to a AST of the markdown document.
Show-Markdown is used to either display the VT100 encoded string on console or redirect the HTML string to the browser.
Set/Get-MarkdownOption cmdlets get be used to view or set markdown rendering options.
To support PowerShell modules built with .NET Windows Compatibility Pack, we decided that it was best to ship the WCP assemblies with PS Core. This also adds many new .NET APIs be default while only adding ~3.5 MB additional disk footprint (to a ~137 MB install currently).
Also update the build to adopt the official .NET Core 2.1.
The main purpose of this was to enable full symbols for windows release build.
Also makes explicit where we are optimizing and where we are not optimizing due to https://github.com/dotnet/corefx/issues/29700
- Can compile a source from strings (TypeDefinition and MemberDefinition).
- Can compile from files.
- Can compile only to a file (without loading the produced assembly).
- Do not recompile and don't reload if the sources have not changed.
- Implement `-IgnoreWarnings` to not treat warnings as errors. By default, the cmdlet considers warnings as errors.
- Add VisualBasic support.
- Add new `-CompilerOptions` parameter to allow setting Roslyn command line parameters including:
- Parser options.
- Compile options.
- Emit options.
**ATTENTION:** The `CompilerOptions` can be specified along with other options like `-OutputAssembly`, `-Language` and `-IgnoreWarnings`. The explicit setting parameters will take precedence over the same settings specified in `-CompileOptions`.
See docs about the compiler options:
https://github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/CommandLine.mdhttps://github.com/dotnet/roslyn/blob/master/docs/compilers/Visual%20Basic/CommandLine.md
**ATTENTION:** `-OutputType` default is `Library`. If `-OutputType` is absent the `-OutputType` default overlaps a value in `CompileOptions`. In other words output type ("target" ot "t" in command line) is always ignored in `CompileOptions`. We have to use `-OutputType` to set an output type.
`AssemblyVersion` and `FileVersion` are now inferred from the `Version` property, which is inferred by `VersionPrefix`. So now both `AssemblyVersion` and `FileVersion` are 6.0.0.0 for each of PowerShell assemblies, and the `ProductVersion` and `InformationalVersion` are 6.0.0.
* Update assemblies versions by MSBuild and create a new PowerShellAssembly.props file to consolidate properties.
* Move import on first place
* Move to "6.0.0-beta.3"
* 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
Use 2.0 CLI/SDK of version `2.0.0-preview1-005952` to keep in sync with the .NET Core 2.0 //Build dogfood instructions. The version of `Microsoft.NetCore.App` in use is `2.0.0-preview1-002106-00`.
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.
- 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.
Travis Plunk