You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pure.DI can copy comments from setup calls into generated documentation comments for the composition class, composition arguments, and composition roots.
1928
+
1929
+
Use regular `//` comments before API calls when you want Pure.DI to include the text in the generated documentation:
1930
+
1931
+
```c#
1932
+
DI.Setup("Composition")
1933
+
.Bind<IService>().To<Service>()
1934
+
// Provides the main service.
1935
+
.Root<IService>("Service");
1936
+
```
1937
+
1938
+
For `Setup(...)` and composition roots, XML documentation comments written with `///` replace the automatically generated documentation:
1939
+
1940
+
```c#
1941
+
/// <summary>
1942
+
/// Application composition.
1943
+
/// </summary>
1944
+
DI.Setup("Composition")
1945
+
.Bind<IService>().To<Service>()
1946
+
/// <summary>
1947
+
/// Provides the main service.
1948
+
/// </summary>
1949
+
.Root<IService>("Service");
1950
+
```
1951
+
1952
+
The generated root member keeps the user-defined XML documentation:
1953
+
1954
+
```c#
1955
+
/// <summary>
1956
+
/// Provides the main service.
1957
+
/// </summary>
1958
+
publicIServiceService
1959
+
{
1960
+
get { ... }
1961
+
}
1962
+
```
1963
+
1964
+
For other setup calls, such as `Arg<T>(...)`, comments are used as documentation text in the generated constructor documentation. Use regular `//` comments there unless you want XML markup to be shown as text.
1965
+
1966
+
</details>
1967
+
1968
+
<details>
1969
+
<summary>Code generation workflow</summary>
1970
+
1971
+
```mermaid
1972
+
flowchart TD
1973
+
start@{ shape: circle, label: Start }
1974
+
setups[fa:fa-search DI setups analysis]
1975
+
types["`fa:fa-search Types analysis
1976
+
constructors/methods/properties/fields`"]
1977
+
subgraph dep[Dependency graph]
1978
+
option[fa:fa-search Selecting a next dependency set]
1979
+
creating[fa:fa-cog Creating a dependency graph variant]
For different IDEs, you can use the _AGENTS.md_ file as is by simply copying it to the root directory. For use with _JetBrains Rider_ and _Junie_, please refer to [these instructions](https://www.jetbrains.com/help/junie/customize-guidelines.html). For example, you can copy any _AGENTS.md_ file into your project (using _Pure.DI_) as _.junie/guidelines.md._
This example demonstrates the creation of an [Avalonia](https://avaloniaui.net/) application in the pure DI paradigm using the Pure.DI code generator.
5
+
This example shows how to build an [Avalonia](https://avaloniaui.net/) application with Pure.DI, using generated composition roots for view models and infrastructure services instead of a runtime container.
6
+
7
+
> [!TIP]
8
+
> XAML binds to virtual composition roots such as `App` and `Clock`. `Hint.Resolve` is disabled because the sample uses explicit roots instead of generated service-locator methods.
6
9
7
10
> [!NOTE]
8
-
> [Another example](samples/SingleRootAvaloniaApp) with Avalonia shows how to create an application with a single composition root.
11
+
> [Another example](/samples/SingleRootAvaloniaApp) with Avalonia shows how to create an application with a single composition root.
9
12
10
13
The definition of the composition is in [Composition.cs](/samples/AvaloniaApp/Composition.cs). This class sets up how the object graphs will be created for the application. Do not forget to define any necessary composition roots, for example, these can be view models such as _ClockViewModel_:
This example demonstrates the creation of a [Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models#blazor-server) application in the pure DI paradigm using the Pure.DI code generator.
5
+
This example shows how to build a [Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models#blazor-server) application with Pure.DI while still integrating with the ASP.NET Core hosting and service-provider pipeline.
6
+
7
+
> [!NOTE]
8
+
> The composition is installed as the host service-provider factory. Components can still use the standard Blazor/ASP.NET Core service infrastructure, while application view models come from generated Pure.DI roots.
6
9
7
10
The composition setup file is [Composition.cs](/samples/BlazorServerApp/Composition.cs):
@@ -29,7 +33,7 @@ partial class Composition : ServiceProviderFactory<Composition>
29
33
}
30
34
```
31
35
32
-
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself.
36
+
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself. Only registered roots can be resolved through the Microsoft `IServiceProvider`, so each view model consumed by the host must be listed with `Root`.
33
37
34
38
The web application entry point is in the [Program.cs](/samples/BlazorServerApp/Program.cs) file:
Copy file name to clipboardExpand all lines: readme/BlazorWebAssemblyApp.md
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,10 @@
4
4
5
5
[Here's an example](https://devteam.github.io/Pure.DI/) on GitHub Pages.
6
6
7
-
This example demonstrates the creation of a [Blazor WebAssembly](https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models#blazor-webassembly) application in the pure DI paradigm using the Pure.DI code generator.
7
+
This example shows how to build a [Blazor WebAssembly](https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models#blazor-webassembly) application with Pure.DI, exposing generated roots through the WebAssembly host container.
8
+
9
+
> [!NOTE]
10
+
> WebAssembly uses `builder.ConfigureContainer(composition)` instead of `UseServiceProviderFactory`. Keep browser-specific services, such as `HttpClient`, registered in the normal Blazor service collection.
8
11
9
12
The composition setup file is [Composition.cs](/samples/BlazorWebAssemblyApp/Composition.cs):
@@ -31,7 +35,7 @@ partial class Composition : ServiceProviderFactory<Composition>
31
35
}
32
36
```
33
37
34
-
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself.
38
+
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself. Only registered roots can be resolved through the Microsoft `IServiceProvider`, so each view model consumed by the host must be listed with `Root`.
35
39
36
40
The web application entry point is in the [Program.cs](/samples/BlazorWebAssemblyApp/Program.cs) file:
This example demonstrates the creation of a simple console application in the pure DI paradigm using the Pure.DI code generator. All code is in [one file](/samples/ShroedingersCat/Program.cs) for easy reading:
5
+
This example shows the smallest Pure.DI console application: abstractions, implementations, bindings, and the composition root are kept in one place so the generated object graph is easy to inspect. All code is in [one file](/samples/ShroedingersCat/Program.cs) for easy reading:
6
+
7
+
> [!TIP]
8
+
> The `Setup` method is a compile-time hint for the generator. It is not called at runtime, so it can stay private and contain only composition configuration.
This example is very similar to the [simple console application](ConsoleTemplate.md), except that this is a [native AOT](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) application.
5
+
This example shows how the simple console composition can be published as a [native AOT](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/) application. Pure.DI generates plain C# object creation code, so the dependency graph remains friendly to trimming and ahead-of-time compilation.
6
+
7
+
> [!TIP]
8
+
> Native AOT works best when construction is explicit and reflection-light. Prefer generated roots and bindings over runtime service-location patterns in AOT samples.
6
9
7
10
The [project file](/samples/ShroedingersCatNativeAOT/ShroedingersCatNativeAOT.csproj) looks like this:
This example is very similar to the [simple console application](ConsoleTemplate.md), except that the composition is [defined](/samples/ShroedingersCatTopLevelStatements/Program.cs) as top-level statements and looks a little less verbose:
5
+
This example shows the same object graph as the [simple console application](ConsolePageTemplate.md), but defines the composition directly in [Program.cs](/samples/ShroedingersCatTopLevelStatements/Program.cs) with top-level statements. It keeps the setup compact while still producing the same compile-time validated composition:
6
+
7
+
> [!TIP]
8
+
> Top-level statements are convenient for small samples. For larger applications, move setup into a partial composition class so roots, lifetimes, and infrastructure bindings are easier to navigate.
This example demonstrates the creation of an Entity Framework application in the pure DI paradigm using the Pure.DI code generator.
5
+
This example shows how to combine Pure.DI with Entity Framework services supplied by Microsoft dependency injection. Pure.DI builds the application graph, while the external service provider supplies the `DbContext` and EF infrastructure.
6
+
7
+
> [!TIP]
8
+
> `PersonsDbContext` is intentionally not bound in Pure.DI. It is requested from the external `ServiceProvider`, while Pure.DI owns the application root and factories such as `Func<Person>`.
6
9
7
10
The composition setup file is [Composition.cs](/samples/EF/Composition.cs):
@@ -23,7 +27,7 @@ partial class Composition : ServiceProviderFactory<Composition>
23
27
}
24
28
```
25
29
26
-
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself.
30
+
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself. When Pure.DI cannot resolve framework services such as `DbContext`, `ServiceProviderFactory<T>` delegates those requests to the configured Microsoft dependency injection provider.
27
31
28
32
The console application entry point is in the [Program.cs](/samples/EF/Program.cs) file:
29
33
@@ -79,6 +83,8 @@ partial class Program(
79
83
}
80
84
```
81
85
86
+
The external service provider should be configured before resolving `composition.Root`. If a required EF service is missing, Pure.DI will fail when the root is created instead of hiding the missing registration.
87
+
82
88
The [project file](/samples/EF/EF.csproj) looks like this:
This example demonstrates the creation of a gRPC service in the pure DI paradigm using the Pure.DI code generator.
5
+
This example shows how to build a gRPC service with Pure.DI and ASP.NET Core hosting. The generated composition exposes the service and application dependencies through the Microsoft service-provider pipeline.
6
+
7
+
> [!TIP]
8
+
> The gRPC service type itself is a composition root. Keep the ASP.NET Core gRPC registration (`AddGrpc`) in `Program.cs`, and let Pure.DI create the service graph.
6
9
7
10
The composition setup file is [Composition.cs](/samples/GrpcService/Composition.cs):
@@ -28,7 +31,7 @@ partial class Composition : ServiceProviderFactory<Composition>
28
31
}
29
32
```
30
33
31
-
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself.
34
+
The composition class inherits from `ServiceProviderFactory<T>`, where `T` is the composition class itself. Only registered roots can be resolved through the Microsoft `IServiceProvider`, so the gRPC service type is declared as a root.
32
35
33
36
The web application entry point is in the [Program.cs](/samples/GrpcService/Program.cs) file:
0 commit comments