So I am building a complex case here with inheritance and IOC, need to use ActivatorUtilities to inject instances and pass parameters... no matter what I do I get the following error:
System.InvalidOperationException: 'A suitable constructor for type
'blabla.ISimpleTest' could not
be located. Ensure the type is concrete and all parameters of a public
constructor are either registered as services or passed as arguments.
Also ensure no extraneous arguments are provided.'
So in order to discard what could be the problem and ensure there is no constructor issues, I created a very very simple scenario that gives me the same error.
startup.cs
services.AddScoped<ISimpleTest, SimpleTest>();
the class and the interface, very simple here:
public interface ISimpleTest
{
}
public class SimpleTest : ISimpleTest
{
public SimpleTest()
{
}
}
test
var theInstance = ActivatorUtilities.CreateInstance<ISimpleTest>(ServiceProvider);
Additional notes
The ServiceProvider instance is fine (the rest/entire application depends on it).
Tried with and without adding the public constructor(empty params)
Tried also constructor with params, same error.
Tried to specify the params[] parameter, by sending null or empty array, same issue.
Extra test:
Just to confirm it's properly registered, I tried to get the instance using the Service provider, and works without issues:
//No issues this way:
var yyy = ServiceProvider.GetService<ISimpleTest>();
What am I doing here wrong? According to documentations, this should be enough to work
Related
I encountered a Problem with the DI framework of netcore. I am aware about the different ways to register an type in the DI container.
Specifically I am interested in the .AddSingleton method. There are many overlaods of this method.
My Problem is that I want to ensure that when I register the same class in different ways (with an interface and just with the class type), then two instances are created, one for each "registration" way.
Lets say I have an Interface called ISomeInterface an one implementation of it named ImplementationOfSomeInterface.
In my case I want the DI system to create an instance whenever the ImplementationOfSomeInterface is requested. Further I have some places where I define the dependency just with the interface ISomeInterface.
The Problem is that the DI system returns 2 instances of ImplementationOfSomeInterface. One for the case where the dependency is related of the class and one for the case where the dependency is given by the Interface.
I already checked many documentation and tutorials, but they all just explain the differences of AddSingleton, AddScoped etc...
// registration with the class type
services.AddSingleton<ImplementationOfSomeInterface>()
//registration with an interface and the corresponding 'same' class type
services.AddSingleton<ISomeInterface, ImplementationOfSomeInterface>();
//--------- now the usage of it -------------------
public TestClassA(SomeInterfaceImplementation instance)
{
var resultingInstA = instance;
}
public TestClassB(ISomeInterface instance)
{
var resultingInstB = instance;
}
//I would expect that resultingInstA is pointing to the very same object of
//resultingInstB => but they are different!
I would expect that resultingInstA is pointing to the very same object of resultingInstB => but they are different!
How can I achieve that I get the same instance back?
You can do it by registering an instance of the class rather than just the type.
var instance = new ImplementationOfSomeInterface();
services.AddSingleton(instance);
services.AddSingleton<ISomeInterface>(instance);
Now any attempt to resolve ImplementationOfSomeInterface or ISomeInterface will both return the instance initialized here.
I want to mock the following line of code:
ResponseEntity<String> response = client.callPostService(url, dto, new ParameterizedTypeReference<String>(){});
Attempt
#Test
public void testFunction{
HTTPSClient client = Mockito.mock(HTTPSClient.class);
Mockito.when(client.callPostService(any(String.class),any(Dto.class), new ParameterizedTypeReference<String>{}))
}
I get errors regarding the parameters I have placed.
You shouldn't mix Mockito's argument matchers (like any(), eq() etc.) and the real objects while configuring behavior for a mock.
So, in your case the next would be correct:
Mockito.when(client.callPostService(any(String.class),any(Dto.class), Mockito.any(ParameterizedTypeReference.class))).thenReturn(...)
or (since Java 8):
Mockito.when(client.callPostService(any(String.class),any(Dto.class), Mockito.any())).thenReturn(...)
The latter also doesn't raise the compiler warning about the unchecked cast of generic type because of enhanced type inference.
Below is a minimal example of the problem I am currently encountering:
using System.Net.WebSockets;
using AutoFixture;
using AutoFixture.AutoMoq;
using FluentAssertions;
using Xunit;
...
[Fact]
public void Test1()
{
var fixture = new Fixture().Customize(new AutoMoqCustomization() { ConfigureMembers = true });
var sut = fixture.Create<WebSocket>();
sut.Should().NotBeNull();
}
[Fact]
public void Test2()
{
var fixture = new Fixture().Customize(new AutoMoqCustomization() { ConfigureMembers = true });
var sut = new Mock<WebSocket>().Object;
fixture.Inject(sut);
sut.Should().NotBeNull();
}
...
When I run the first test, I get the following exception:
AutoFixture.ObjectCreationExceptionWithPath : AutoFixture was unable to create an instance from Moq.Mock`1[System.IO.Stream] because creation unexpectedly failed with exception. Please refer to the inner exception to investigate the root cause of the failure.
Inner exception messages:
System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
The second test succeeds.
I would like to be able to create an instance of a class using AutoFixture which takes a WebSocket as a constructor parameter, without the need to inject a mock object first (ultimately, so that I can use an AutoMoqData attribute, and get rid of some boilerplate). Have I got any misusage or misunderstanding going on here, or would this be better placed as a GitHub issue? In the interim, is there anything I can do to work around this issue?
You observe this issue because of the AutoFixture's factory discovery strategy. When you try to create an object of an abstract type, AutoFixture still inspects the type to find a static factory method to activate the object. In your particular case, the WebSocket type contains such methods, so some of them is used. It looks like it doesn't work well with auto-generated input values, so fails with an exception.
You can customize AutoFixture, to always mock the WebSocket type:
fixture.Register((Mock<WebSocket> m) => m.Object);
Just tested with the latest versions of products (AutoFixture 4.5.0, Moq 4.10.0) and it works like a charm.
I have the following setup code:
MockOf<IObjectSet<Dummy>>().Setup(c => c.AddObject(dummy)).Verifiable();
MockOf<IObjectContextWrapper>().Setup(c => c.GetObjectSet<Dummy>()).Returns(MockOf<IObjectSet<Dummy>>().Object);
where Dummy is an empty class definition, and dummy is a Dummy. MockOf<T>() is a mock managing feature on a base class, which basically makes sure that each time it's called on a type, it returns the same mock instance.
The test containing this setup code fails with a TypeLoadException and the following message:
System.TypeLoadException : Type 'IObjectSet`1Proxy389e220f10aa4d9281d0b9e136edc1d4' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=a621a9e7e5c32e69' is attempting to implement an inaccessible interface.
at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type)
at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
at System.Reflection.Emit.TypeBuilder.CreateType()
at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.GenerateCode(Type proxyTargetType, Type[] interfaces, ProxyGenerationOptions options)
at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)
at Moq.Mock1.<InitializeInstance>b__0()
at Moq.Mock1.InitializeInstance()
at Moq.Mock`1.get_Object()
at OddEnds.Tests.Data.EntityFramework.RepositoryTest.Delete_DeletesObjectFromObjectSet() in RepositoryTest.cs: line 43
I have imported System.Data.Objects and referenced both System.Data.Entity.dll and Microsoft.Data.Entity.CTP.dll in both the test project and the project where the class being tested resides. The build succeeds with no errors, warnings or messages (except a few related to Code Contracts...)
How do I fix this?
Are any of the interfaces or class you are using in your tests internal? Are you using something like [assembly: InternalsVisibleTo("YourTestAssembly")] in order to get things to compile?
If so, you'll also need to add one for DynamicProxyGenAssembly2 in order for Moq to dynamically generate the proxy for the classes.
//goes in the AssemblyInfo.cs where the internal interfaces / classes are defined
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
Here is a relevent post about the topic
http://sonofpirate.blogspot.com/2009/09/my-first-foray-into-unit-testing-with.html
I hope this helps
I found that in my case I had created a Dummy class instance to be used in my unit test which happened to be private (as I didn't really want to share the test object outside).
My code was along these lines:
var mockMonitor = new Mock<ICacheMonitor<int, PrivateObject>>();
where the PrivateObject was a private class definition within my TestClass.
The fix in my case is therefore to ensure that any of the types in your Mock constructor are public.
public class PrivateObject () {}
(Obviously I wouldn't call my public object a PrivateObject either...)
I tripped across another case which I couldn't figure out at first. I was working on a proxy for an interface created inside of my unit test...
public IDoWork
{
void DoWork();
}
It took me forever to figure out that the problem was not with that interface, but was, rather, that the unit test itself was not public:
class TestSomething // missing public keyword
{
// .. some test which tries to create a mock of the interface
public IDoWork
{
void DoWork();
}
}
So, while IDoWork is says it's public, it really is not since it's enclosed in a private class.
Hope this helps someone.
i have a HttpModule that creates an CommunityPrincipal (implements IPrincipal interface) object on every request. I want to somehow store the object for every request soo i can get it whenever i need it without having to do a cast or create it again.
Basically i want to mimic the way the FormsAuthenticationModule works.
It assigns the HttpContext.User property an object which implements the IPrincipal interface, on every request.
I somehow want to be able to call etc. HttpContext.MySpecialUser (or MySpecialContext.MySpecialUser - could create static class) which will return my object (the specific type).
I could use a extension method but i dont know how to store the object so it can be accessed during the request.
How can this be achieved ?
Please notice i want to store it as the specific type (CommunityPrincipal - not just as an object).
It should of course only be available for the current request being processed and not shared with all other threads/requests.
Right now i assign my CommunityPrincipal object to the HttpContext.User in the HttpModule, but it requires me to do a cast everytime i need to use properties on the CommunityPrincipal object which isnt defined in the IPrincipal interface.
I'd recommend you stay away from coupling your data to the thread itself. You have no control over how asp.net uses threads now or in the future.
The data is very much tied to the request context so it should be defined, live, and die along with the context. That is just the right place to put it, and instantiating the object in an HttpModule is also appropriate.
The cast really shouldn't be much of a problem, but if you want to get away from that I'd highly recommend an extension method for HttpContext for this... this is exactly the kind of situation that extension methods are designed to handle.
Here is how I'd implement it:
Create a static class to put the extension method:
public static class ContextExtensions
{
public static CommunityPrinciple GetCommunityPrinciple(this HttpContext context)
{
if(HttpContext.Current.Items["CommunityPrinciple"] != null)
{
return HttpContext.Current.Items["CommunityPrinciple"] as CommunityPrinciple;
}
}
}
In your HttpModule just put the principal into the context items collection like:
HttpContext.Current.Items.Add("CommunityPrincipal", MyCommunityPrincipal);
This keeps the regular context's user property in the natural state so that 3rd party code, framework code, and anything else you write isn't at risk from you having tampered with the normal IPrincipal stroed there. The instance exists only during the user's request for which it is valid. And best of all, the method is available to code as if it were just any regular HttpContext member.... and no cast needed.
Assigning your custom principal to Context.User is correct. Hopefully you're doing it in Application_AuthenticateRequest.
Coming to your question, do you only access the user object from ASPX pages? If so you could implement a custom base page that contains the cast for you.
public class CommunityBasePage : Page
{
new CommunityPrincipal User
{
get { return base.User as CommunityPrincipal; }
}
}
Then make your pages inherit from CommunityBasePage and you'll be able to get to all your properties from this.User.
Since you already storing the object in the HttpContext.User property all you really need to acheive you goal is a Static method that acheives your goal:-
public static class MySpecialContext
{
public static CommunityPrinciple Community
{
get
{
return (CommunityPrinciple)HttpContext.Current.User;
}
}
}
Now you can get the CommunityPrinciple as:-
var x = MySpecialContext.Community;
However it seems a lot of effort to got to avoid:-
var x = (CommunityPrinciple)Context.User;
An alternative would be an Extension method on HttpContext:-
public static class HttpContextExtensions
{
public static CommunityPrinciple GetCommunity(this HttpContext o)
{
return (CommunityPrinciple)o.User;
}
}
The use it:-
var x = Context.GetCommunity();
That's quite tidy but will require you to remember to include the namespace where the extensions class is defined in the using list in each file the needs it.
Edit:
Lets assume for the moment that you have some really good reason why even a cast performed inside called code as above is still unacceptable (BTW, I'd be really interested to understand what circumstance leads you to this conclusion).
Yet another alternative is a ThreadStatic field:-
public class MyModule : IHttpModule
{
[ThreadStatic]
private static CommunityPrinciple _threadCommunity;
public static CommunityPrinciple Community
{
get
{
return _threadCommunity;
}
}
// Place here your original module code but instead of (or as well as) assigning
// the Context.User store in _threadCommunity.
// Also at the appropriate point in the request lifecyle null the _threadCommunity
}
A field decorated with [ThreadStatic] will have one instance of storage per thread. Hence multiple threads can modify and read _threadCommunity but each will operate on their specific instance of the field.