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).
@@ -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"`.
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.
@@ -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 `<RuntimeIdentifier>` tag. For example, for Windows 10 x64 machine, the project file is:
* 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
