Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
jason-field
@jason-field

I'm trying to find an example of how to use DryIoc with Azure Functions. Specifically I have a number of existing registration modules I'be built over time to register components with DryIoC container. I want to re-use these as part of an Azure Functions project. However I can't seem to find any examples of how to either get hold of the underlying DryIoC container from Microsoft's Dependency set of services (from within a FunctionsStartup derived class), or the alternative which is to hook in a DryIoc container into MS set of services. Any pointers or suggestions? I'm following the examples from MS about using DI with Azure functions, and using a class that inherits from FunctionStartup.

Instead of below Where I'm passing in MS servicecollection into y module (to do the registrations I want to pass in the DryIoc container

public override void Configure(IFunctionsHostBuilder builder)
 {
            builder.Services.AddHttpClient();
            builder.Services.AddLogging(x => x.AddDebug());

            var module = new HandlerModule();
            module.Register(builder.Services);
  }
Maksim Volkau
@dadhi
@jason-field I am not using Azure Functions so it is hard to help. Are you using DryIoc.Microsoft.DependencyInjection package?
I would've asked this question on StackOverflow, I saw some folks discussing AF DI there.
Maksim Volkau
@dadhi
@jason-field Also there were a number of issues in DryIoc repo related to AF, may be those issues or their authors may help you https://github.com/dadhi/DryIoc/search?q=azure+functions&type=issues
jason-field
@jason-field
hi @dadhi . From what I can see the normal route to link to the two (MS DI and DryIoc) requires hooking in a custom service provider factory. This method doesn't seem to be available from the IFunctionsHostBuilder interface. Conversely I've read on SO that MS are using DryIoc under the covers for Azure functions. But I'm not sure how to get access to the methods to retrieve the underlying instance of DryIoc from the IFunctionsHostBuilder interface (if it is using DryIoC underneath)
Maksim Volkau
@dadhi
Ok, you did formulate the question! Now let's find the answer. I will try to google it.
Maksim Volkau
@dadhi
@jason-field Hello, I have found the project wirh Aur
@jason-field Could you try the similar approach with the DryIoc? If verified, maybe it will make sense to create the extension.
jason-field
@jason-field
Hi @dadhi Thanks for this. I'll take a look and shortly see how it pans out.
Maksim Volkau
@dadhi
@jason-field I have quickly assembled some code, did not test or publish it yet, but you may try: https://github.com/dadhi/DryIoc/blob/master/src/DryIoc.AzureFunctions/DryIocAzureFunctions.cs
jason-field
@jason-field
Thanks @dadhi I'll have a play with it later tonight.
jason-field
@jason-field
Hi @dadhi . I ran a quick test today, and the integration looks good so far. I'll start hooking in my other registration modules to see how well it performs in a wider set of use cases. But so far, its looking good. Thank you!
Maksim Volkau
@dadhi
@jason-field Good to hear, ping me if you find something.
jason-field
@jason-field
Hi @dadhi . I have deployed an Azure function into a test Azure cloud environment, running with DryIoc as the DI container. Looking good so far.
Maksim Volkau
@dadhi
logging is working?
@jason-field Also, maybe a dumb question, could you run the sample app without Azure account?
jason-field
@jason-field
Hi @dadhi . I first run it locally (using the Azure functions emulator) for local testing before I publish it into the Azure Function App environment. Is that what you mean?
I know the DI is working as it wires up a NHibernate session factory and then queries an Azure SQL server instance. Just PoC at the moment. The dependencies are all defined in a DryIoc container.
Maksim Volkau
@dadhi
@jason-field ok, thanks
Maksim Volkau
@dadhi
@jason-field Now I wonder should I release this as a package without testing it myself and rely on people telling what's wrong :)
jason-field
@jason-field
@dadhi To your question, How did you test previous IOC integrations?
Maksim Volkau
@dadhi
I have created the samples and I didn't need the azure account for them. But probably it is time.
jason-field
@jason-field
You probably don't need an account now. You can use the emulator if needs be
Maksim Volkau
@dadhi
@jason-field I have just released the DryIoc.AzureFunctions v1-preview-01 on NuGet https://www.nuget.org/packages/DryIoc.AzureFunctions/
jason-field
@jason-field
Thanks @dadhi ! I'll give it a whirl
jason-field
@jason-field
Hi @dadhi . One request with regards to the nuget package. Can you ship both a .NET standard version 2.0/2.1) as well as a .NET 5 version? Not everyone will have switched up to the newer version of the runtime as yet
Maksim Volkau
@dadhi
@jason-field It is netstantard2.0 as of now.
LP
@grofit
Is there any reason why a set of types bound/registered against an interface wouldnt be resolvable as an IEnumerable<InterfaceTypeHere> within a constructor? as I have this pattern used in a few places and it works fine, but now I have added a new class following same sort of approach as others it refuses to populate the constructor of it with an enumerable of all types matching that interface
but its baffling as it works everywhere else following this same pattern, only difference is that this is through an inherited classes constructor which delegates to a base constructor, but its still going through the correct constructor, just passing in an empty enumerable, or at least an enumerable that resolves to 0 entries
LP
@grofit
public class SomethingRegistry : SomethingElse
{
    // ...
    public SomethingRegistry(IEnumerable<ISomething> somethings = null) : base(somethings) {} // Only constructor
    // ...
}

container.Register<ISomething, Something1>();
container.Register<ISomething, Something2>();
// ...
container.Register<ISomethingRegistry, SomethingRegistry>();

var registry = container.Resolve<ISomethingRegistry>(); // 0 ISomething passed in
As I say though I have this exact same pattern elsewhere on another object which takes an enumerable of an interface and that is registered same way and works fine (several of these sorts of things actually), but only difference is they dont have a base constructor call
Maksim Volkau
@dadhi
Does it work if remove default null in constructor wirh somethings = null?
sorry, mobile phone, fast typing...
LP
@grofit
Removed that, event tried doing a to list on it before sending to base. Other ones which work have same default null as well
Just to confirm too when I debug I can see its got an enumerable, just it's empty, as if I ToList it and debug in base constructor I can see it coming from parent in the stack and that it is a list object, so it's like dryioc is satisfying the argument but the provided enumerable didn't match anything
Maksim Volkau
@dadhi
ok, I will checked that.
check
LP
@grofit
Lol I'm on a phone too I feel your pain with it just auto in-correcting everything
Maksim Volkau
@dadhi

I have put your code into the sample, but it seems to work fine:

https://dotnetfiddle.net/6nnJIi

The full code:
using System;
using System.Collections.Generic;
using System.Linq;
using DryIoc;

public class Program
{
    public static void Main()
    {
        var container = new Container();

        container.Register<ISomething, Something1>();
        container.Register<ISomething, Something2>();

        container.Register<SomethingElse>();
        container.Register<ISomethingRegistry, SomethingRegistry>();

        var registry1 = container.Resolve<SomethingElse>();
        Console.WriteLine("Somethings count: " + registry1.Somethings.Count());

        var registry2 = container.Resolve<ISomethingRegistry>();
        Console.WriteLine("Somethings count: " + registry2.Somethings.Count());
    }

    public interface ISomething {}
    public class Something1 : ISomething {}
    public class Something2 : ISomething {}
    public interface ISomethingRegistry 
    {
        IEnumerable<ISomething> Somethings { get; }
    }
    public class SomethingElse : ISomethingRegistry
    {
        public IEnumerable<ISomething> Somethings { get; private set; }
        public SomethingElse(IEnumerable<ISomething> somethings = null) { Somethings = somethings; }
    }
    public class SomethingRegistry : SomethingElse
    {
        public SomethingRegistry(IEnumerable<ISomething> somethings = null) : base(somethings) {}
    }
}
So the question maybe in the container configuration - the rules you are using.
Or maybe the sequence of registrations and resolutions.
So look and if you have anything to add into the example...
LP
@grofit
It's going through an abstraction system but for all intents and purposes it should be how you have it there, but I'm baffled as it works elsewhere, will try to dig deeper when I get on pc next, as it's also in blazor so it's a nightmare to debug anything past front facing classes :(
Thanks for taking the time out to look into it though
LP
@grofit
fml...
I did binding directly and then resolved immediately, its telling me some 3rd party class is not bindable, which is totally correct but I think Blazor was swallowing that exception and just silently failing :(
sorry to waste your time, BUT you have in a round about way solved it for me :D
Maksim Volkau
@dadhi
Ok, cool. More than happy that it's working. No so many bugs lately :)
Jason
@ukkiwisurfer
I'm having a few issues trying to work out how to have component dependencies registered using Microsoft's service collection, registered into a DryIoc container. The use case is registering a Refit client using MS DI, but resolving the dependency in DryIoc. Can anyone point me to a concrete example? I'm using the MS CreateDefaultBuilder() extension.
Maksim Volkau
@dadhi