And RotaHttpContext class looks below (this class generated by target framework .net framework 4.8 with WebForm);
[DependencyInjectionInfo(typeof (IEntityCore), "RotaHttpContextToUse")]
public class RotaHttpContext: IRotaHttpContext
With this implementation we were able to read property from RotaHttpContext in runtime. As you can see below we need this class on CommonEntityBase.cs and with above DI mechanism we can access GetUserId property in RotaHttpContext class.
Everything was as we wanted so far. This implemantation worked for Entity classes. Now we want to use the GetUserId() property (in RotaHttpContext) for collection objects as well. For this purpose we added below code inside to IEntityCollectionCore
public class RotaHttpContext : IRotaHttpContext
With this change, we thought that we could use this property in collection classes as well. But it didn't turn out as we expected. We cannot access to GetUserId property because RotaHttpContextToUse always comes up NULL. I think for collection classes we didn't implement DI mechanism but I don't undertand why.
Below is the part we are trying to access from the collection class.
public void SetTransferObjects(Rota.DataTransfer.DokKonsKonteynerYukuTransferObjectList transferObjectList)
var rotaHttpContextToUse = RotaHttpContextToUse.GetUserId();
We couldn't understand why we couldn't use this method over Collection classes as it is in Entity classes, we request your help on this matter.
First of all, it's really not recommended to alter framework interfaces. If you need to use the DI system, please add your code to a partial class of CommonEntityBase instead, as you can then use future runtime versions without the necessity of porting code over. The DI system will check the exposed properties on the full type, not IEntityCore, for injection
Our DI system is invoked when entity classes are instantiated, not when collections are instantiated, so the property you added to the collection isn't set by the DI system
What I wonder is why don't you use a singleton for the httpcontext? ASP.NET's HttpContext is also a singleton after all. It also frees you from having references to a singleton ASP.NET object at the entity level (which is really not where it belongs)
The criteria and directions you specify are so important to us. Now we understand why we can't DI in the section in collection and after your mail we tried a number of different solutions.
We decided to manage the HttpContext information in the runtime by creating a project that supports multi-target framework (.net framework 4.8 and .net 6) and referencing it to the related projects (WebForm and .NetCore WebApi). We proved it with a little POC study.