diff --git a/docs/design/features/assemblyloadcontext.md b/docs/design/features/assemblyloadcontext.md index 9fe61fc89ebab83be3c2b1f75cce834f385bf670..73e12f8d774bb26c4a7e8abea7abaec95fd6da4d 100644 --- a/docs/design/features/assemblyloadcontext.md +++ b/docs/design/features/assemblyloadcontext.md @@ -2,7 +2,7 @@ This concept is not new to .NET Core but has existed since the days of .NET Framework (see [this](https://blogs.msdn.microsoft.com/suzcook/2003/05/29/choosing-a-binding-context/) for details) where it operated behind the scenes and not exposed for the developer to interact with, aside from loading your assembly in one based upon the API used to perform the load. -In .NET Core, we have exposed a [managed API surface](https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Loader/ref/System.Runtime.Loader.cs) that developers can use to interact with it - to inspect loaded assemblies or create their own **LoadContext** instance. Here are some of the scenarios that motivated this work: +In .NET Core, we have exposed a [managed API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) that developers can use to interact with it - to inspect loaded assemblies or create their own **LoadContext** instance. Here are some of the scenarios that motivated this work: * Ability to load multiple versions of the same assembly within a given process (e.g. for plugin frameworks) * Ability to load assemblies explicitly in a context isolated from that of the application. @@ -52,11 +52,11 @@ If the *Default LoadContext* fallback also did not resolve the load (or was not ## Tests -Tests are present [here](https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Loader). +Tests are present [here](https://github.com/dotnet/runtime/tree/master/src/libraries/System.Runtime.Loader/tests). ## API Surface -Most of the **AssemblyLoadContext** [API surface](https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Loader/ref/System.Runtime.Loader.cs) is self-explanatory. Key APIs/Properties, though, are described below: +Most of the **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs) is self-explanatory. Key APIs/Properties, though, are described below: ### Default @@ -89,4 +89,4 @@ As part of .NET Standard 2.0 effort, certain assembly load APIs off the **Assemb * Assembly.LoadFile - creates a new (anonymous) load context to load the assembly into. * Assembly.Load(byte[]) - creates a new (anonymous) load context to load the assembly into. -If you need to influence the load process or the load context in which assemblies are loaded, please look at the various Load* APIs exposed by **AssemblyLoadContext** [API surface](https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Loader/ref/System.Runtime.Loader.cs). +If you need to influence the load process or the load context in which assemblies are loaded, please look at the various Load* APIs exposed by **AssemblyLoadContext** [API surface](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Loader/ref/System.Runtime.Loader.cs). diff --git a/docs/project/library-servicing.md b/docs/project/library-servicing.md index 5fa1c9d5ed79cd301b376a8c10af9842999aa80e..f2444236df2ade6b3490798af9ad751df55e7637 100644 --- a/docs/project/library-servicing.md +++ b/docs/project/library-servicing.md @@ -31,7 +31,7 @@ Where the `AssemblyVersion` is set to the old version before updating. To determ ## Update the package index -If you incremented the `AssemblyVersion` in the last step, you'll also need to add an entry to [packageIndex.json](https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.Private.PackageBaseline/packageIndex.json). Find the entry for your library in that file (again, making sure you're in the correct release branch), then find the subsection labeled `AssemblyVersionInPackageVersion`. There, add an entry that maps your new `AssemblyVersion` to your new `PackageVersion`. For an example, see [this PR](https://github.com/dotnet/corefx/commit/fe796bbb8f658c98407b189244d37a68d25a6b32#diff-122916076db7087dbc454352fada61eeR107), where we bumped the `PackageVersion` of `Microsoft.Diagnostics.Tracing.EventSource` from `2.0.0` to `2.0.1`, and bumped the `AssemblyVersion` from `2.0.0.0` to `2.0.1.0`. Therefore, we added an entry to `packageIndex.json` of the form `"2.0.1.0": "2.0.1"`. +If you incremented the `AssemblyVersion` in the last step, you'll also need to add an entry to [packageIndex.json](https://github.com/dotnet/runtime/blob/master/src/libraries/pkg/Microsoft.Private.PackageBaseline/packageIndex.json). Find the entry for your library in that file (again, making sure you're in the correct release branch), then find the subsection labeled `AssemblyVersionInPackageVersion`. There, add an entry that maps your new `AssemblyVersion` to your new `PackageVersion`. For an example, see [this PR](https://github.com/dotnet/runtime/commit/d0e4dcc7ebf008e7b6835cafbd03878c3a0e75f8#diff-ec9fd7a62cb0c494d86029014940382cR107), where we bumped the `PackageVersion` of `Microsoft.Diagnostics.Tracing.EventSource` from `2.0.0` to `2.0.1`, and bumped the `AssemblyVersion` from `2.0.0.0` to `2.0.1.0`. Therefore, we added an entry to `packageIndex.json` of the form `"2.0.1.0": "2.0.1"`. ## Add your package to packages.builds diff --git a/docs/project/public-signing.md b/docs/project/public-signing.md index 8a23cf0ec7c6fb3bb73cb82b40fa6242412c7d50..a39868c5fdbb85be21e3d3f0f2e7809b558f56bf 100644 --- a/docs/project/public-signing.md +++ b/docs/project/public-signing.md @@ -3,7 +3,7 @@ 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. +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/runtime 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. diff --git a/docs/workflow/testing/coreclr/viewing-jit-dumps.md b/docs/workflow/testing/coreclr/viewing-jit-dumps.md index 4f36d26c4b850cdd2e371a6d1d98115c8b4aff24..6a5c41b86c276290fdbf1a5da10e3f5757a8a01b 100644 --- a/docs/workflow/testing/coreclr/viewing-jit-dumps.md +++ b/docs/workflow/testing/coreclr/viewing-jit-dumps.md @@ -11,7 +11,7 @@ The first thing to do is setup the .NET Core app we want to dump. Here are the s * Cd into `src/coreclr` * Perform a release build of the runtime by passing `release` to the build command. You don't need to build tests, so you can pass `skiptests` to the build command to make it faster. Note: the release build can be skipped, but in order to see optimized code of the core library it is needed. * Perform a debug build of the runtime. Tests aren't needed as in the release build, so you can pass `skiptests` to the build command. Note: the debug build is necessary, so that the JIT recognizes the configuration knobs. -* Install the (latest) [.NET CLI](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md), which we'll use to compile/publish our app. +* Install the (latest) [.NET CLI](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md), which we'll use to compile/publish our app. * `cd` to where you want your app to be placed, and run `dotnet new console`. * Modify your `csproj` file so that it contains a RID (runtime ID) corresponding to the OS you're using in the `` tag. For example, for Windows 10 x64 machine, the project file is: diff --git a/docs/workflow/testing/using-your-build.md b/docs/workflow/testing/using-your-build.md index 248c70c36ec4f32fefdeed0e299df05ccfb45202..df9fa79f0674c63c772c179405e244909f432e0b 100644 --- a/docs/workflow/testing/using-your-build.md +++ b/docs/workflow/testing/using-your-build.md @@ -27,7 +27,7 @@ After setting up dotnet you can verify you are using the newer version by: `dotnet --info` -- the version should be greater than 3.0.0-* -For another small walkthrough see [Dogfooding .NET Core SDK](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md). +For another small walkthrough see [Dogfooding .NET Core SDK](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md). ## Create sample self-contained application diff --git a/docs/workflow/using-dotnet-cli.md b/docs/workflow/using-dotnet-cli.md index 00238d84563cea4b963f1c9c0d9bf27106df5190..08486c5a59b94d54cec497d5f2e8432035e252e6 100644 --- a/docs/workflow/using-dotnet-cli.md +++ b/docs/workflow/using-dotnet-cli.md @@ -7,7 +7,7 @@ For other walkthroughs see: - [Using Your Build - Update CoreCLR from raw binary output](./testing/using-your-build.md) - [Using CoreRun To Run .NET Core Application](./testing/using-corerun.md) -- [Dogfooding .NET Core SDK](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md). +- [Dogfooding .NET Core SDK](https://github.com/dotnet/runtime/blob/master/docs/project/dogfooding.md). ## Prerequisites diff --git a/src/libraries/System.Text.Json/porting_guide/README.md b/src/libraries/System.Text.Json/porting_guide/README.md index c2adf9ae59bf0e61a32cded0f95a42d33b4ae188..0f09372899ff9b36e08d8dfa4a6d36dc4cc141da 100644 --- a/src/libraries/System.Text.Json/porting_guide/README.md +++ b/src/libraries/System.Text.Json/porting_guide/README.md @@ -5,7 +5,7 @@ * The `System.Text.Json` APIs that are included in .NET Core 3.0 are designed primarily for performance critical scenarios and hence emphasize runtime performance and reducing allocations over high usability and convenience. Furthermore, the in-box JSON stack does not aim to provide feature parity with `Newtonsoft.Json`, especially since it is in its infancy. That said, we still want to make it easier for those whose needs can be fulfilled by the new APIs and those who are looking for better performance. This guide captures some of the common pitfalls and programming patterns that are useful to note when trying to use the new in-box APIs. - Please help contribute to this porting guide to help others onboard to the new APIs. - For an overview on the objectives, constraints, and design requirements of the new APIs, please see the [roadmap](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Text.Json/roadmap/README.md). - - If you have any feedback or feature requests, feel free to submit issues: https://github.com/dotnet/corefx/issues + - If you have any feedback or feature requests, feel free to submit issues: https://github.com/dotnet/runtime/issues ## Common Pitfalls, Patterns, and Tips