diff options
| -rw-r--r-- | Documentation/README.md | 2 | ||||
| -rw-r--r-- | Documentation/project-docs/oss-signing.md | 18 | ||||
| -rw-r--r-- | Documentation/project-docs/public-signing.md | 18 | ||||
| -rw-r--r-- | Documentation/project-docs/strong-name-signing.md | 2 |
4 files changed, 20 insertions, 20 deletions
diff --git a/Documentation/README.md b/Documentation/README.md index 4ca98785bd..9a16da0e9f 100644 --- a/Documentation/README.md +++ b/Documentation/README.md @@ -29,7 +29,7 @@ Project Docs - [Branching Guide](project-docs/branching-guide.md) - [API Review Process](project-docs/api-review-process.md) - [Strong Name Signing](project-docs/strong-name-signing.md) -- [Open Source Signing](project-docs/oss-signing.md) +- [Public Source Signing](project-docs/public-signing.md) - [Repo Organization](project-docs/repo-organization.md) - [Project NuGet Dependencies](project-docs/project-nuget-dependencies.md) diff --git a/Documentation/project-docs/oss-signing.md b/Documentation/project-docs/oss-signing.md deleted file mode 100644 index 2e8616f9e8..0000000000 --- a/Documentation/project-docs/oss-signing.md +++ /dev/null @@ -1,18 +0,0 @@ -Open Source Signing -=================== - -For reasons listed over on [Strong Naming](strong-name-signing.md), all .NET Core assemblies are strong-named. - -To enable you to build assemblies that have a matching identity to what Microsoft would build, we leverage a new signing mechanism called _Open Source Signing (OSS)_. This lets you clone the dotnet/corefx repository, build and then drop the resulting assembly in your application with zero changes to consuming libraries. By default, all .NET Core projects build using OSS. - -OSS is very similar to [delay signing](http://msdn.microsoft.com/en-us/library/t07a3dye(v=vs.110).aspx) but without the need to add skip verification entries to your machine. This allows you to load the assembly in most contexts, or more precisely in any context that doesn't require validating the strong-name signature. - -When running on the full .NET Framework we only support using OSS assemblies for debugging and testing purposes. Microsoft does not guarantee that you can successfully load OSS assemblies in all scenarios that are required for production use. For list of known scenarios where OSS does not work when running on .NET Framework, see below. - -However, in the context of ASP.NET 5 on .NET Core, or .NET Native, Microsoft supports using OSS assemblies for production uses. Make note, however, that while ability to load OSS binaries is supported on these platforms, the API and contents of the assembly itself is unsupported (due to it being privately built). - -Known issues when debugging and testing OSS assemblies on .NET Framework: - -- You will not be able to install the assembly to the [Global Assembly Cache (GAC)](https://msdn.microsoft.com/en-us/library/yf1d93sz.aspx) -- You will not be able to load the assembly in an AppDomain where shadow copying is turned on. -- You will not be able to load the assembly in a partially trusted AppDomain diff --git a/Documentation/project-docs/public-signing.md b/Documentation/project-docs/public-signing.md new file mode 100644 index 0000000000..9f18357dd3 --- /dev/null +++ b/Documentation/project-docs/public-signing.md @@ -0,0 +1,18 @@ +Public Signing +=================== + +For reasons listed over on [Strong Naming](strong-name-signing.md), all .NET Core assemblies are strong-named. + +To enable you to build assemblies that have a matching identity to what Microsoft would build, we leverage a new signing mechanism called _Public Signing_. This lets you clone the dotnet/corefx repository, build and then drop the resulting assembly in your application with zero changes to consuming libraries. By default, all .NET Core projects build using public signing. + +Public signing is very similar to [delay signing](http://msdn.microsoft.com/en-us/library/t07a3dye(v=vs.110).aspx) but without the need to add skip verification entries to your machine. This allows you to load the assembly in most contexts, or more precisely in any context that doesn't require validating the strong-name signature. + +When running on the full .NET Framework we only support using public signed assemblies for debugging and testing purposes. Microsoft does not guarantee that you can successfully load public signed assemblies in all scenarios that are required for production use. For list of known scenarios where public signing does not work when running on .NET Framework, see below. + +However, in the context of ASP.NET 5 on .NET Core, or .NET Native, Microsoft supports using public signed assemblies for production uses. Make note, however, that while ability to load public signed binaries is supported on these platforms, the API and contents of the assembly itself is unsupported (due to it being privately built). + +Known issues when debugging and testing public signed assemblies on .NET Framework: + +- You will not be able to install the assembly to the [Global Assembly Cache (GAC)](https://msdn.microsoft.com/en-us/library/yf1d93sz.aspx) +- You will not be able to load the assembly in an AppDomain where shadow copying is turned on. +- You will not be able to load the assembly in a partially trusted AppDomain diff --git a/Documentation/project-docs/strong-name-signing.md b/Documentation/project-docs/strong-name-signing.md index ce3543fde9..14c9e97c35 100644 --- a/Documentation/project-docs/strong-name-signing.md +++ b/Documentation/project-docs/strong-name-signing.md @@ -21,4 +21,4 @@ There are three major problems that developers run into after strong naming thei 2. _Virality_. Once you've strong-named an assembly, you can only statically reference other strong-named assemblies. -3. _No drop-in replacement_. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling _all_ consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, [strong-names are used for identity, and not for security](http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx)). Failing that, however, we've introduced a new concept called [Open Source Signing](oss-signing.md) that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default. +3. _No drop-in replacement_. This is a problem for open source libraries where the strong-name private key is not checked into the repository. This means that developers are unable to build to their own version of the library and then use it as a drop-in replacement without recompiling _all_ consuming libraries up stack to pick up the new identity. This is extremely problematic for libraries, such as Json.NET, which have large incoming dependencies. Firstly, we would recommend that these open source projects check-in their private key (remember, [strong-names are used for identity, and not for security](http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx)). Failing that, however, we've introduced a new concept called [Public Signing](public-signing.md) that enables developers to build drop-in replacements without needing access to the strong-name private key. This is the mechanism that .NET Core libraries use by default. |