diff --git a/docs/docs/examples/complex-test-infrastructure.md b/docs/docs/examples/complex-test-infrastructure.md
index d05f883172..75af949e7e 100644
--- a/docs/docs/examples/complex-test-infrastructure.md
+++ b/docs/docs/examples/complex-test-infrastructure.md
@@ -252,6 +252,13 @@ Declare your dependencies with attributes and TUnit manages the orchestration.
 5. **Keep classes focused** - one responsibility per class
 6. **Use TUnit's orchestration** - avoid manual dependency management
 
+## Multiple Test Projects and SharedType.PerTestSession
+In larger solutions, it is often beneficial to structure tests into different test projects, sometimes alongside a common test library for shared  common code like infrastructure orchestration. Test runners like `dotnet test`, typically launch separate .NET processes for each test project. And because each test project runs as its own process, they cant share the dependencies.
+
+This means that classes configured with a `SharedType.PerTestSession` lifetime will be **initialized once per test project**, rather than once for the entire test session.
+
+If you intend for services or data to be shared across those separate test projects, you will need to consolidate the execution using a Test Orchestrator approach to load all projects into a single process and run `dotnet test` directly on that. 
+
 ## Summary
 
 TUnit's property injection system helps simplify complex test infrastructure setup through a declarative, type-safe approach. By handling initialization order, lifecycle management, and dependency injection, TUnit allows you to focus on writing tests that validate your application's behavior.
diff --git a/docs/docs/test-authoring/aot-compatibility.md b/docs/docs/test-authoring/aot-compatibility.md
index f7adbd0359..be30ef13e6 100644
--- a/docs/docs/test-authoring/aot-compatibility.md
+++ b/docs/docs/test-authoring/aot-compatibility.md
@@ -173,7 +173,7 @@ namespace MyTestProject;
 
 public class ServiceInjectionTests
 {
-    [ClassDataSource<DatabaseService>(Shared = SharedType.Globally)]
+    [ClassDataSource<DatabaseService>(Shared = SharedType.PerTestSession)]
     public required DatabaseService Database { get; init; }
 
     [ClassDataSource<LoggingService>]
diff --git a/docs/docs/test-lifecycle/property-injection.md b/docs/docs/test-lifecycle/property-injection.md
index 8c51c0436c..9e4dc7eaf2 100644
--- a/docs/docs/test-lifecycle/property-injection.md
+++ b/docs/docs/test-lifecycle/property-injection.md
@@ -317,10 +317,10 @@ public class IntegrationTests
 When using nested property injection, the `Shared` parameter becomes crucial:
 
 - **`SharedType.PerTestSession`**: Single instance for the entire test run - ideal for expensive resources like containers
-- **`SharedType.Globally`**: Single instance across all test sessions
-- **`SharedType.ForClass`**: One instance per test class
+- **`SharedType.PerAssembly`**: Single instance shared for every test in the same assembly as itself.
+- **`SharedType.PerClass`**: One instance per test class
 - **`SharedType.Keyed`**: Share instances based on a key value
-- **No sharing**: New instance for each injection point
+- **`SharedType.None`**: New instance for each injection point
 
 ### Best Practices