We Keep Coding

How to instantiate outside of a constructor?

How to replicate this code with Autofac syntax?
public static class MenuConfig
{
public static void Initialize()
{
var _menuService = DependecyFactory.GetInstance<IMenuService>();
Parameters.Menu = _menuService.Menu();
}
}
Before calling this a "duplicate question" please note that I'm looking for an Autofac command. I CANNOT inject the interface anywhere and then call "Resolve". What I need to is perform an "InstancePerRequest" inline and uninjected so I don't have to do this:
var _service = new Service(new Dependency(new context()));
LightInject has a method that allows instantiation from an interface OUTSIDE of a constructor like this:
var _service = DependecyFactory.GetInstance<IService>();
What is the equivalent method for Autofac?

When calling containerBuilder.Build() you get back a container which implements IContainer and ILifetimeScope, whenever you get hold of one of these interfaces, you can resolve types from it:
container.Resolve<IService>();
If you want this container to be static, you could add the container as a static property to the Program or Startup class (depending if you're creating a Console or ASP.NET application).
Remember that the root container will be around for the entire duration of your application, so this can result in unwanted memory leaks when used incorrectly. Also see the warning in the documentation.
Still, it's perfectly possible to do the memory management yourself by resolving an Owned<> version from your interface:
using (var service = Program.Container.Resolve<Owned<IService>>())
{
service.Value.UseService();
}
Anyway, since you mention a static class in the comments, the best solution is to change that into a non-static class and register it as a singleton with Autofac. Then you can inject a Func<Owned<IService>> serviceFactory into that singleton and create/dispose an instance of the service wherever you need it.
using (var service = serviceFactory())
{
service.Value.UseService();
}

This is simply not possible with Autofac. All other solutions involving Autofac will require code refactoring which may potentially break software functionality. So unfortunately, the most elegant and least disruptive solution is this:
var _service = new Service(new Dependency(new context()));
Since this is an edge case addressing only one part of the software, this compromise is acceptable. It would be nice, however, if Autofac implemented this functionality in some future release.

Integration test HttpClient using ASP.NET Core 2.0 How to mock DateTime.Now with dependency injection

Ive written a couple of unit tests while using dependency injection and the httpClient in the .net Core 2.0 framework.
Ive been testing my controllers like this:
var result = await __client.PostAsync("api/production-line/validate-assignment-deadline", null);
But now i wanted to mock an object and after searching a bit on the internet all i could find was to do it like this:
var controller = new ProductionLineController(mockProductionLineProvider);
which is not testing the routing and on top of that i would have to create a lot of objects. so i dont want mock my object in this way.
I would like to be able to replace the service with an mock object i havent found a way to get the IServiceCollection into my unittest method.
I would like to be able to do something like this:
var mockingDate = new DateTime(date.Year, date.Month, date.Day, 12, 00, 00);
__constantsMock.Setup(x => x.GetCurrentDateTime()).Returns(mockingDate);
services.Replace(new ServiceDescriptor(typeof(IConstants), ConstantsMock.Object));
var result = await __client.PostAsync("api/production-line/validate-assignment-deadline", null);
I hope you can help me think of ways to get to a solution that doesnt involve me having to create every object that i would inject normaly.
Thank you in advance
edit:
im indeed doing integration tests, i want to test everything but i need to be able to configure the result coming from a DateTime.Now so i made the constants class with a function to return the datetime.now and im trying to mock/stub the class/function. that way i can test multiple scenario's that could occur.

You are looking at the standard way of mocking; you create stubs for all the dependencies (you need to be able to control all of them!) and create the controller. Being able to mock the DI framework wouldn't really buy you anything; you would still need to provide all the dependencies to the class when you constructed it.
Use mocking libraries like NSubstitute to make it easier; if you feel like you have too many dependencies then I would suspect you need to refactor your design (perhaps that controller does too much).
Note that testing with actual HTTP requests is more of an integration test; you are testing the whole app instead of just one class. In that case you can set up different environments for your program and have one that will set up the injector with whatever extra mocks/test data you need.

Once you start doing something like issuing a request to an action, you're pretty much well outside of unit test territory. What you're doing here is integration testing.
As long as you're doing integration testing, you might as well use TestServer, which will actually give you a much more accurate platform for integration tests. Setting up all the dependencies manually doesn't do anything for you in ensuring that your application actually functions as it should. The full documentation is here, but basically, you just do:
_server = new TestServer(new WebHostBuilder()
.UseStartup<Startup>());
_client = _server.CreateClient();
The return of _server.CreateClient() is actually an instance of HttpClient, so your actual test code doesn't really need to change. However, now you've got a full mockup of all your services and config baked in.

The solution to my problem was as follows:
Make an extra starting class that inherits from your StartUp class
Give that class the following code:
public class UnitTestStartup : Startup
{
public static IServiceProvider ServiceProvider;
public static IServiceCollection Services;
public static Mock<IConstants> ConstantsMock;
public void ConfigureTestingServices(IServiceCollection services)
{
ServiceProvider = base.ConfigureServices(services);
Services = services;
ConstantsMock = new Mock<IConstants>();
services.Replace(new ServiceDescriptor(typeof(IConstants), ConstantsMock.Object));
}
}
Make the ConstantsMock (the service you want to mock) available in your baseclass
Like this:
protected Mock<IConstants> __constantsMock;
__constantsMock = UnitTestStartup.ConstantsMock;
have every unit test class inherit from your baseclass
override the __constantsMock with a new object and you're done

Dependency service Null Reference exception in unit testing

I am trying to include Unit testing to my Xamarin PCL project.
This is what I am basically doing :
Login Page class :
public bool isUserRemembered()
{
return DependencyService.Get<IUserDefaults>().getUserRemembered();
}
public void setRememberUser(bool check)
{
DependencyService.Get<IUserDefaults>().setUserRemembered(check);
}
UnitTest class (iOS) :
[Test]
public void RememberKeyTrueTest()
{
LoginPage page = new LoginPage();
bool isRemember = true;
page.setRememberUser(isRemember);
bool value = page.isUserRemembered();
if (value)
Pass();
else
Fail();
}
I get Null Reference Exception on this line : DependencyService.Get<IUserDefaults>().setUserRemembered(check).
Will dependency service work with unit testing? Or is there any work around it?

When I use Dependency Injection in my code, I use IoC (Inversion Of Control) to handle the creation of the dependencies in my production code, and manually create my dependencies in my unit tests.
My main reason for this is that it is explicit. Often I'll be using a Mocking framework to create fake instances so I don't want the extra complexity.
A suggestion on your code under test, you have swapped a dependency to your class for a dependency on your DependencyService. I'm not saying don't use the DependencyService but you could pass in the dependency to your constructor of the class. Then your test could pass in a fake instance and the production code would use the DependencyService to get you an IUserDefaults and pass it in. That would make your class easier to test.

Dependency Injection in MS Dynamics CRM

I am currently getting started with the extending of Microsoft Dynamics CRM using Plugins.
Is it possible to add Dependency injection to these plugins (for testing, loose coupling, etc. purposes)? Where can I register my IoC-container so that it's used over all the plugins of the same type?

We've been trying to unit test and apply dependency injection on our Dynamics CRM application. Unfortunately, as Microsoft support and consultants are confirmed, there is no supported way to do it. You may either transfer all of your plugin business logic to an another business class and apply dependency injection or stop thinking about it.
If you choose to fight back with Dynamics CRM, you need to define a static field on a plugin super class which will be your DI Container. As follows,
public abstract class SuperPlugin : IPlugin{
public void Execute(IServiceProvider serviceProvider){
// initialize a static container instance if not available
var containerWrapper = new ContainerWrapper{
Container = serviceProvider.GetService(typeof(IPluginExecutionContext)),
Resolver = //static resolver instance of dependency container
};
OnExecution(containerWrapper);
}
public abstract void OnExecution(IDependencyResolver resolver);
}
I really cannot understand why Microsoft doesn't simply let us register some components to the IServiceProvider implementation that they are using internally.
Ps. Since your SuperPlugin class is an IPlugin, you may forget to write the interface implementation on the sub class. But we encountered some bugs on Plugin Registration tool that is shipped with official Dynamics CRM SDK. So in case you may have the same problem you should also implement your plugins as follows,
public class MyPlugin : SuperPlugin, IPlugin{
public abstract void OnExecution(IDependencyResolver resolver){};
}
Edit: See a small example that explains the concept https://github.com/nakahparis/DIForCRM

Plugins in CRM are the Bane of Unit Testing:
Issues with non-plugin test
No way to temporarily disable
Easy to forget it is running
Issues with testing plugins themselves
Unable to unit test and attach to process
A lot to mock out, Pipeline, Service Provider etc
Runs multi-threaded
This has led me to the following solution for testing plugins:
Get rid of the plugin context as quickly as possible, extracting out all objects and service required from it right away.
Create an ExecutePlugin method to hook unit tests into, and immediately call this method after extracting the objects from the plugin context.
Push as much code as possible into the business layer.
This results in plugins that look like this (with a heavy use of extension methods to make this simpler):
public void Execute(IServiceProvider provider)
{
var context = provider.GetContext();
var service = provider.GetService(context);
var target = GetTarget<Contact>(context);
if (target == null || !target.ContainsAllNonNull(c => new
{
c.FirstName,
c.LastName,
}))
{
// Entity is of the wrong type, or doesn't contain all of the required attributes
return;
}
ExecutePlugin(service, target);
}
public void ExecutePlugin(IOrganizationService service, Contact target){
// Logic Goes Here
}
Once this is done, the only thing you need to unit test the ExceutePlugin is your own IOrganizationService that mocks out the required calls and you have your unit testing done. I don't even bother unit testing the Execute method. Either it'll work, or it won't and blow chow on the first use from within CRM.

What exactly are the steps to auto inject Func<T>?

I'm trying to set up a service class where I would like to inject a simple Func<OtherService> factory method in its constructor. Type OtherService is a class, which should be self-bound (and is indeed when I inject it without factory).
I've installed the latest Ninject core, and Ninject.Extensions.Factory NuGet packages. When I try to retrieve an instance from Ninject, I get an activation exception about not being able to activate IntPtr.
What am I doing wrong? If I understand correctly the documentation of the Factory extension, this type of Func binding should be automatic, without any configuration. Do I need to register the Factory extension anywhere, or create an explicit binding for OtherService? Any tips would be appreciated.
EDIT:
I have Ninject and Ninject.Extensions.Factory installed in a small separate project, where I do some customizations on Ninject. These are the following:
Kernel.Components.Add<IInjectionHeuristic, CustomInjectionHeuristic>();
Kernel.Components.Add<IActivationStrategy, TransientDisposableActivationStrategy>();
where the two custom handlers are for letting me use my custom [Service] attribute for indicating property injection, and for handling disposing of components which use my own IDisposableEx interface (with Disposed notification) for Ninject cache fine tuning.
public class CustomInjectionHeuristic : NinjectComponent, IInjectionHeuristic, INinjectComponent, IDisposable
{
public bool ShouldInject(MemberInfo member)
{
return member.IsDefined(typeof(ServiceAttribute), true);
}
}
public class TransientDisposableActivationStrategy : ActivationStrategy
{
public override void Activate(IContext context, InstanceReference reference)
{
var scope = context.GetScope();
// care about only transient scoped objects
if (scope != null) return;
if (reference.Instance is Component)
reference.Instance.As<Component>().Disposed +=
(sender, args) => context.Kernel.Components.Get<ICache>().Clear(sender);
if (reference.Instance is IDisposableEx)
reference.Instance.As<IDisposableEx>().Disposed +=
(sender, args) => context.Kernel.Components.Get<ICache>().Clear(sender);
}
}
And I also use the Ninject.Extensions.NamedScope extension for InCallScope() bindings.
Any of these customizations could have effect on proper work of the factory?
EDIT2:
I think I got it. The problem seems to be that I have to reference the Factory extension in my startup project, where I define bindings, and not in the class library where I have my basic Ninject setup. So the key is that I have to reference any binding-related extension in that project where I define the bindings. Anyway, sounds logical...

The problem seems to be that I have to reference the Factory extension in my startup project, where I define bindings, and not in the class library where I have my basic Ninject setup. So the key is that I have to reference any binding-related extension in that project where I define the bindings. Anyway, sounds logical...