forked from microsoft/node-api-dotnet
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Organize & rename projects and assemblies (microsoft#37)
- Loading branch information
Showing
131 changed files
with
1,442 additions
and
1,225 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
|
||
## Node API Project Layers | ||
|
||
 | ||
|
||
Solid lines separate assemblies; dotted lines separate namespaces within an assembly. Assemblies may depend only on other assemblies immediately below them. (Namespaces within an assembly may be inter-dependent.) | ||
|
||
Note that while the native API layer could be split into a separate assembly from a layering perspective, it is better to keep it together with the main class library: | ||
- Performance should be better: the native API layer includes many simple and frequently-called methods that are likely to be inlined by the compiler. But inlining isn't possible if they are in a separate assembly. Also loading an extra assembly contributes to startup time. | ||
- Practically, the native API layer is not very useful on its own, so it would just be an inconvenience to always have to bundle it with the main class library. | ||
|
||
Following is a description of the layered assemblies and namespaces, from the bottom up. | ||
|
||
### Microsoft.JavaScript.NodeApi assembly (.NET & AOT) | ||
- `Microsoft.JavaScript.NodeApi.Native` namespace - Exposes all the `napi_*` APIs for JavaScript / Node.js runtime interop. | ||
- `Microsoft.JavaScript.NodeApi` namespace - Core JavaScript value types, collection types, along with supporting types like `JSException`, `JSExportAttribute`, `JSCallbackArgs`, `JSReference`, `JSPropertyDescriptor`. | ||
- `Microsoft.JavaScript.NodeApi.Interop` namespace - Types that support richer interop between .NET and JavaScript, including `JSContext`, The `*Builder*` types, and `JSCallbackOverload`. Also includes threading support in `JSSynchronizationContext`, `JSAsyncScope`. | ||
- `Microsoft.JavaScript.NodeApi.DotNetHost` namespace - Only the `NativeHost` class must be in the main assembly because it gets AOT-compiled. (The class doesn't need to have `public` accessibility though.) | ||
|
||
### Microsoft.JavaScript.NodeApi.DotNetHost assembly (.NET only) | ||
- `Microsoft.JavaScript.NodeApi.DotNetHost` namespace - Supports static binding to .NET assemblies built as Node API modules as well as dynamic binding to arbitrary .NET assemblies / APIs. Includes `ManagedHost`, `JSMarshaler`, and supporting types. | ||
|
||
### Microsoft.JavaScript.NodeApi.Generator assembly (.NET only) | ||
- `Microsoft.JavaScript.NodeApi.Generator.CSharp` namespace - A C# source generator that emits code at compile time that enables JavaScript to statically bind to .NET APIs in the compiled assembly. | ||
- `Microsoft.JavaScript.NodeApi.Generator.TypeScript` - A command-line tool that generates TypeScript type definitions for either statically- or dynamically-bound .NET assemblies. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.