-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Facility aspnet.systemweb #350
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -34,7 +34,7 @@ | |
</PropertyGroup> | ||
|
||
<PropertyGroup Condition="'$(TargetFramework)'=='net45'"> | ||
<DefineConstants>$(DefineConstants);FEATURE_PERFCOUNTERS;FEATURE_GAC;FEATURE_ISUPPORTINITIALIZE;FEATURE_REMOTING;FEATURE_SECURITY_PERMISSIONS;FEATURE_SYSTEM_WEB;FEATURE_SYSTEM_CONFIGURATION;FEATURE_WINFORMS;FEATURE_SERIALIZATION;FEATURE_URIMEMBERS;FEATURE_GETCALLINGASSEMBLY;FEATURE_APPDOMAIN;FEATURE_CODEDOM;FEATURE_ASSEMBLIES;FEATURE_REFLECTION_METHODBODY;CASTLE_SERVICES_LOGGING;FEATURE_EVENTLOG</DefineConstants> | ||
<DefineConstants>$(DefineConstants);FEATURE_PERFCOUNTERS;FEATURE_GAC;FEATURE_ISUPPORTINITIALIZE;FEATURE_REMOTING;FEATURE_SECURITY_PERMISSIONS;FEATURE_SYSTEM_CONFIGURATION;FEATURE_WINFORMS;FEATURE_SERIALIZATION;FEATURE_URIMEMBERS;FEATURE_GETCALLINGASSEMBLY;FEATURE_APPDOMAIN;FEATURE_CODEDOM;FEATURE_ASSEMBLIES;FEATURE_REFLECTION_METHODBODY;CASTLE_SERVICES_LOGGING;FEATURE_EVENTLOG</DefineConstants> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Was kind of hoping we could get rid of this. |
||
</PropertyGroup> | ||
|
||
<PropertyGroup Condition="'$(TargetFramework)'=='netstandard1.6'"> | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
<Project Sdk="Microsoft.NET.Sdk"> | ||
|
||
<PropertyGroup> | ||
<TargetFrameworks>net461</TargetFrameworks> | ||
</PropertyGroup> | ||
|
||
<PropertyGroup> | ||
<SignAssembly>False</SignAssembly> | ||
<GeneratePackageOnBuild>False</GeneratePackageOnBuild> | ||
</PropertyGroup> | ||
|
||
</Project> |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,7 +7,7 @@ Windsor supports so called *open generic components*, that is components that ar | |
For example: | ||
|
||
```csharp | ||
Container.Register(Component.For(typeof(IRepository<>)).ImplementedBy(typeof(MyRepository<>)).LifestylePerWebRequest()); | ||
Container.Register(Component.For(typeof(IRepository<>)).ImplementedBy(typeof(MyRepository<>)).LifestyleTransient()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Web Requests really did not need to be tied to generics |
||
``` | ||
|
||
This single component can then be used to satisfy dependencies on various closed versions of `IRepository<T>`: | ||
|
@@ -28,7 +28,7 @@ public class MyRepository<T>: IRepository<T>, IRepository | |
} | ||
|
||
// registration | ||
Container.Register(Component.For(typeof(IRepository<>)).Forward<IRepository>().ImplementedBy(typeof(MyRepository<>)).LifestylePerWebRequest()); | ||
Container.Register(Component.For(typeof(IRepository<>)).Forward<IRepository>().ImplementedBy(typeof(MyRepository<>)).LifestyleTransient()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here |
||
``` | ||
|
||
In this case the open generic component exposes two services: the generic and non-generic version of repository interface. What should happen when the nen-generic one is requested? | ||
|
@@ -91,5 +91,5 @@ To instruct Windsor to use your implementation of `IGenericImplementationMatchin | |
Container.Register(Component.For(typeof(IRepository<>)) | ||
.Forward<IRepository>() | ||
.ImplementedBy(typeof(MyRepository<>), new RepositoryGenericCloser()) | ||
.LifestylePerWebRequest()); | ||
.LifestyleTransient()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again. Generics and Web Requests ... not a thing. |
||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,16 +38,6 @@ Container.Register(Component.For<MyTransientComponent>().LifestyleTransient()); | |
|
||
:information_source: **What transients are good for:** Transient lifestyle is a good choice when you want to be in control of instance's lifetime. When you need new instance, with new state every time. Also transient components don't need to be thread safe, unless you explicitly use them in multi-threaded situations. In most applications you'll find that a large percentage of your components will end up as transient. | ||
|
||
### PerWebRequest | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not a thing so I removed it from the main docs concerning lifestyles. We should be using scopes. |
||
|
||
Instance of a component will be shared in scope of a single web request. The instance will be created the first time it's requested in scope of the web request. Releasing it explicitly does nothing. Instance will be released upon the end of the web request. | ||
|
||
This is how you register a component as per web request: | ||
|
||
```csharp | ||
Container.Register(Component.For<MyPerWebRequestComponent>().LifestylePerWebRequest()); | ||
``` | ||
|
||
## Standard lifestyles: the less common ones | ||
|
||
The lifestyles described above are the bread and butter of most applications. Occasionally though you'll need a more specialized lifestyle. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,7 +16,7 @@ That's however as far as we can get for what we want from `ISession`. When it's | |
|
||
### The `PerWebRequest` lifestyle | ||
|
||
To change the `ISession` lifestyle to be per web request, we need to specify that in the registration. So we need to change it to the following: | ||
Please install the `Castle.AspNet.SystemWebFacility` NuGet first. To change the `ISession` lifestyle to be per web request, we need to specify that in the registration. So we need to change it to the following: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do believe this documentation is super dated. I did the minimum here, but after changing this I think there is a bit of work that needs to happen here to clear out the cruft. |
||
|
||
```csharp | ||
Kernel.Register( | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
# System Web Facility | ||
|
||
The system web facility provides legacy `scoped` management of lifestyles using [http modules](https://msdn.microsoft.com/library/ms178468.aspx) for desktop clr web based projects. | ||
|
||
## How does it work? | ||
|
||
Your objects consumed within a `PerWebRequest` lifestyle will effectively live for as long as that web request thread is active. It also use HttpContext.Current to track the lifecycle | ||
of the instance. Once the web request has completed the instance gets released. | ||
|
||
## What do I need to set it up? | ||
|
||
You will need 3 things to get this going: | ||
|
||
- Assembly reference to System.Web | ||
- NuGet reference for [Microsoft.Web.Infrastructure](https://www.nuget.org/packages/Microsoft.Web.Infrastructure/) | ||
- NuGet reference for [Castle.AspNet.SystemWebFacility](https://www.nuget.org/packages/Castle.AspNet.SystemWebFacility/) | ||
|
||
After the release of v3.0 we expect you would not need this, but if you are still having problems with module registration | ||
you might also need to update your web.config with the following: | ||
|
||
```xml | ||
<configuration> | ||
<system.web> | ||
<httpModules> | ||
<add name="PerRequestLifestyle" type="Castle.Facilities.AspNet.SystemWeb.Lifestyle.PerWebRequestLifestyleModule, Castle.AspNet.SystemWebFacility"/> | ||
</httpModules> | ||
</system.web> | ||
</configuration> | ||
``` | ||
|
||
## How do I register objects? | ||
|
||
You would new up a windsor container as usual then use the ComponentRegistration extensions of the facility to stipulate | ||
'PerWebRequest' lifestyles. Like so: | ||
|
||
```csharp | ||
|
||
var container = new WindsorContainer(); | ||
container.Register(Component.For<PerWebRequestComponent>().LifestylePerWebRequest()); | ||
|
||
``` | ||
|
||
If you need the attribute based lifestyle approach you it is also available: | ||
|
||
```csharp | ||
|
||
[PerWebRequest] | ||
public class PerWebRequestComponentWithAttributedLifestyle | ||
{ | ||
} | ||
|
||
var container = new WindsorContainer(); | ||
container.Register(Component.For<PerWebRequestComponentWithAttributedLifestyle>().Named("P")); | ||
|
||
``` | ||
|
||
## I have problems and need help! | ||
|
||
Please sign in to [GitHub](https://github.com/castleproject/Windsor) and raise an issue. Please be clear and | ||
concise, if we have a code repro we can most definitely guide you. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
<Project Sdk="Microsoft.NET.Sdk"> | ||
|
||
<PropertyGroup> | ||
<TargetFrameworks>net45</TargetFrameworks> | ||
</PropertyGroup> | ||
|
||
<Import Project="..\..\buildscripts\common.props"></Import> | ||
|
||
<PropertyGroup> | ||
<OutputType>Library</OutputType> | ||
<TreatWarningsAsErrors>true</TreatWarningsAsErrors> | ||
<AssemblyName>Castle.Facilities.AspNet.SystemWeb.Tests</AssemblyName> | ||
<RootNamespace>Castle.Facilities.AspNet.SystemWeb.Tests</RootNamespace> | ||
</PropertyGroup> | ||
|
||
<PropertyGroup> | ||
<!--This was the only way at the time of writing to $(OutputType) to honour the 'Exe' setting. This can probably be deleted from netcoreapp2.0(inclusive) onwards. Pathing dependencies: build.cmd --> | ||
<RuntimeIdentifier Condition="'$(OS)'=='Windows_NT'">win7-x64</RuntimeIdentifier> | ||
</PropertyGroup> | ||
|
||
<ItemGroup> | ||
<PackageReference Include="Castle.Core" Version="4.2.0" /> | ||
<PackageReference Include="NUnit" Version="3.6.1" /> | ||
</ItemGroup> | ||
|
||
<ItemGroup> | ||
<ProjectReference Include="..\Castle.Facilities.AspNet.SystemWeb\Castle.Facilities.AspNet.SystemWeb.csproj" /> | ||
<ProjectReference Include="..\Castle.Windsor\Castle.Windsor.csproj" /> | ||
</ItemGroup> | ||
|
||
<ItemGroup> | ||
<Reference Include="System.Configuration" /> | ||
<Reference Include="System.Web" /> | ||
</ItemGroup> | ||
|
||
</Project> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hope you are ok with this?