List explicitly as .csproj files the scenarios for which the offline package cache is important
Produces new artifacts designed for various scenarios, such as:
* Docker (where xml doc files are not needed)
* Azure web apps (where 1.x SDKs must still be supported, but xml docs are not needed)
In some cases, private keys for certificates is not completely available. When attempting to decrypt key material,
this can cause 'CryptographicException: Keyset does not exist'. This changes the order in which key material
decryption looks up private keys to first key the certificate options provided explicitly to the API, and then
falling back to the cert store for decryption keys.
Removing this from .App in 2.1.3 because this was unused, and the capability is not actually supported by VS. This will be re-added in the future versions of .App when we land the VS integration for in-process hosting.
cref https://github.com/aspnet/IISIntegration/pull/969
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
Changes:
* Add a test project with simple unit tests for the shared framework
* Add root-level Directory.Build.props/targets files
* Cleanup .csproj files to reduce duplication
The MicrosoftNETPlatformLibrary property instructs the .NET Core SDK to treat a particular package as the shared framework platform. This affects how the SDK will trim references and publish output, determines how the runtimeconfig files are generated, and may affect how optimizations are preformed by other tools. In some installations of .NET Core, the ASP.NET Core shared framework is not available. This change adds properties to let the SDK determine on which platforms ASP.NET Core is enabled.
Create an internal abstraction for finding the default directories for key storage. This allows us to run tests without squashing on keys on the developer machine. It also allows us to isolate test runs from reach other.
- We're removing the buffer arugment from the API as a result of a mini review. This is a pre-emptive reaction to avoid breakage when the change comes in.
The default implementation of EncryptedXml doesn't support using the RSA
key from X509Certificate to decrypt xml unless that cert is in the X509
CurrentUser\My or Localmachine\My store. This adds support for
decrypting with the X509Certificate directly. This is useful for Linux
(often Docker) scenarios, where the user already has a .pfx file, but
may not have added it to X509Store.
- Remove unnecessary tasks and scripts
- Ensure the KOREBUILD_DOTNET_* environment variables are preserved in the docker build context
- Other MSBuild cleanup of the targets
This retargets all data protection libraries to ns2.0. This means .NET
Framework applications will need to upgrade to .NET Framework 4.6.1.
This upgrade makes available API to .NET Core that was previously only
available on .NET Framework, such as encrypting keys at rest with
certificates.
New API for .NET Core users:
- IDataProtectionBuilder.ProtectKeysWithCertificate(string thumbprint)
- CertificateXmlEncryptor
- ICertificateResolver
- DataProtectionProvider
- .Create(string applicationName, X509Certificate2 certificate)
- .Create(DirectoryInfo keyDirectory, X509Certificate2 certificate)
- .Create(DirectoryInfo keyDirectory, Action<IDataProtectionBuilder>
setupAction, X509Certificate2 certificate
Other minor changes in this commit:
- Fixed samples that were using obsolete logging API
- Remove calls to api-sets, instead using kernel32. .NET Core 2.0 no
longer requires using api-sets as Nano Server now forwards kernel32
calls
- Made minor improvements to the TypeForwardingActivator
- Remove dead code an unused api baselines
- Enable more tests on macOS/Linux that previously only ran on Windows