Recording from HAVIT Educational windows from 25th September 2019.
Most common mistakes in using Tasks and in asynchronous code [Jiří Činčura, HAVIT Educational window, 25.9.2019]
Leave a reply
Category Archives: .NET Framework
C# Puzzle: this = new Foo();
Can you imagine a situation when this code compiles and runs?
public void Reset()
{
this = new Foo();
}
See the result: https://dotnetfiddle.net/JheuMu.
C# ref returns [Jiří Činčura, HAVIT Educational window, 28.3.2019]
Recording from HAVIT Educational windows from 28th March 2019. Jiří Činčura presented the ref returns in C#.
Castle Windsor – Support for ASP.NET WebForms 4.7.2
We are proud to announce Castle Windsor Support for ASP.NET WebForms.
Sources, documentation and usage example can be found on GitHub, NuGet package Havit.CastleWindsor.WebForms is in the public NuGet feed.
C# Puzzle: out parameters
This method usually outputs false.
Can you imagine a situation where it outputs true?
static bool Test(out int x, out int y)
{
x = 123;
y = 45;
return (x == y);
}
You can find the solution in .NET Fiddle.
C# Puzzle: Exceptions
What is the output when you run this code?
try
{
try
{
throw new Exception("A");
}
catch
{
throw new Exception("B");
}
finally
{
throw new Exception("C");
}
}
catch (Exception ex)
{
Console.Write(ex.Message);
}
See the result: https://dotnetfiddle.net/6SWPqL
Quartz.NET, Castle Windsor – LifeStyle Per Job (Scoped)
If you have ever tried to use Quartz.NET (a famous job-scheduling library) with Castle Windsor (IoC/DI container) you might need to register a component whose life-style should be bound to the job itself (LifestylePerJob). There are plenty of alternatives available which all have the same characteristics – they do not work:
- LifestylePerThread – does not reset the thread when running a new job
- BoundTo<Job>() – does not support typed factories when resolved inside the job
- BoundTo<object>() – does not support typed factories when resolved inside the job
- Quartz.IJobFactory + LifestyleScoped – does not support typed factories when resolved into the job (the scope from JobFactory is not propagated inside the job!)
There is a “simple” workaround for such scenarios. You can use LifestyleScoped but you have to begin/end the scope in the job.
If you use the job itself just as a plumbing class where the work itself is encapsulated in a separate service (and you should do this) then you can simply inject both a service-factory and the kernel and then do the scope-work in the job itself:
public class MyJob : IJob
{
private readonly IServiceFactory<MyService> myServiceFactory;
private readonly IKernel kernel;
public MyJob(IServiceFactory<MyService> myServiceFactory, IKernel kernel)
{
this.myServiceFactory = myServiceFactory;
this.kernel = kernel;
}
public void Execute()
{
using (var scope = kernel.BeginScope())
{
// use your way to work with factories ;-)
using (var myService = myServiceFactory.Create())
{
myService.DoWork();
}
// BTW: we have an extension method
myServiceFactory.ExecuteAction(service => service.DoWork());
}
}
}
…the MyService class has all the dependencies you need and as you use it using the factory it behaves as the pseudo-resolution-root for this scenario. You might use the kernel.Resolve+Release in the job but I always prefer not to… ;-)
