Still not dependency-injection friendly

[Aleksanderis]

Some (quite long) time ago there were significant improvements towards better DI control with introducing IJobActivator. However it's still not very DI friendly and too much coupled.
If I want to reference IJobActivator just to do some light-weight contracts manipulation, I need to add Microsoft.Azure.WebJobs nuget. One nuget is OK, but that's what happens if I add it:

It adds a bunch of additional packages, even though in this particular project I just need IJobActivator (and potentially maybe some other contracts). I know about nuget "development dependencies" and about "ignore dependencies" - sometimes it helps, sometimes not. There are many different cases, when all these not always needed dependencies resurface and being added anyway.

I wonder why simple functions (as WebJobs often position themselves) need so many dependencies.. My "simple function" nuget package size is about 10mb. If I have 3-5 such "functions" to create separate nugets is a bit too much overload (usually I put them into one package, which works in general, but it's againts separation of concerns). I understand there are reasons these dependencies are needed on the very end (on the "startup" project), but it would be good to have a bit more control over it.

Any thoughts about it? Are all of these references really needed? Even their namespaces so different.;)

[mathewc]

The issue is that IJobActivator was added to the WebJobs.Host package/assembly when i really should have lived in the WebJobs.Core package/assembly which has minimal dependencies. In general, all our simple contracts like this belong in core. The WebJobs.Host assembly of course brings in a lot of dependencies.

That said, I'm trying to understand your exact scenario. If you're writing some job functions, don't you need the entire host package anyways? That's what you'll need to run ultimately. Is your goal to write simple functions living in assemblies with minimal dependencies, that later get loaded into a host exe that pulls in all the required runtime packages? If so, I expect there are types other than IJobActivator that will complicate your goal of purity.

[Aleksanderis]

Yes, you almost got my exact scenario, but there is just a little bit longer chain of projects.;)
Let me try to describe it in a simple way.. I have:

1. WebJobs host project - with all needed WebJobs references (which is OK, but still 10mb per "simple function" ;))
2. Some other non-webjobs projects (i.e. ASP.NET MVC project)
3. Contracts, IOC projects (where IOC types are registered, no other logic/functions) - common for all type of projects (webjobs, mvc, etc)

So if I use IJobActivator in Contracts/IOC projects, it happens like in my screenshot. And the most scary part - if I create a nuget from Contracts/IOC projects and, since it's common, I can add it to some other non-webjob project. At the end it would also add a bunch of WebJob references..

Although I managed to workaround it after all - it's not a perfect solution, but works for me in 90% of cases.;)
I referenced Microsoft.Azure.WebJobs nuget as peer/development dependency (developmentDependency="true"):
<package id="Microsoft.Azure.WebJobs" version="2.0.0" targetFramework="net461" developmentDependency="true" />

But.. as I mentioned in my original post, this is not absolutely bulletproof and there are cases when ALL dependent packages still can be added where they are not needed. Don't remember exactly the case, but it was something related to nugets manipulation on solution level - like updating nugets for several projects, consolidating nugets, or something like that. In other words - something that I would considered as Nuget manager issues/features.

[mathewc]

This should no longer be an issue after all the DI work done in v3. Also related: #1917.