Replies: 1 comment
-
I investigated a little further and it seems that there is a different between the scripting runner and Cake Frosting. As far as I can tell, the implementation of In a scripting project, calling public ICakeRegistrationBuilder As(Type type)
{
ServiceType = type; // <- this discards the previous registration
return this;
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I'm currently working on a module that provides a custom implementation of
IPackageInstaller
.My implementation is supposed to be a wrapper around the NuGet package installer (
NuGetPackageInstaller
fromCake.NuGet
).Since
NuGetPackageInstaller
is internal but implementsINuGetPackageInstaller
, I declared a dependency toINuGetPackageInstaller
by adding a constructor parameter and expected that the DI container would be able to resolve the dependency.My code looks something like this (I reduced it to the bare minimum to show the issue):
I'm loading both modules in the my project's
Main()
:In
NuGetModule.cs
, I found the correct registrationI expected this to work but get an error indicating that
INuGetPackageInstaller
cannot be resolved.I assume it has something to do with the two calls to
As<T>()
which seems to only register the type asIPackageInstaller
.If I pull the internal type out of
Cake.NuGet
and explicitly register it in my module, it could get it to work:Obviously this is not a solution I want to keep, since I'm relying on internals of the
Cake.NuGet
package.So my questions is, should the DI container be able to resolve
INuGetPackageInstaller
or is the current behaviour as intended?Beta Was this translation helpful? Give feedback.
All reactions