Getting Stub instead of real type in "FollowCustomCondition"

[micha-frey]

Hi all,

we are currently setting up the first tests with ArchUnitNET (btw. great framework 😊 ), but we are facing an issue with inside the "FollowCustomCondition" for PropertyMembers. The type that we get for the evaluation is marked with "IsStub == true" and that also probably means, that the base class is not set etc. See the following screenshot for the full rule.

Unfortunately, if we try to reproduce it in a small test project, we are not receiving the stubs. Any idea, what we can do to fix this, or is this somehow a bug in ArchUnitNET?

Thanks in advance,
Michael

[micha-frey]

I have also find out, that even when the full classes are in the "loaded architecture" the base classes seems to be stubs when calling

_architecture.GetClassOfType()

results in the following issues:

That behavior makes it really hard to use rules like "AreAssignableTo" as the result highly depends on whether stubs where used or not.

[alexanderlinne]

Hi @FreyAtGit, glad to hear that you like the library.

With the information given I can really only make assumptions about what might go wrong. Stub types are generated for assemblies that are not explicitly loaded or requested to be loaded as a transitive dependency. That means that if you load your assembly through new ArchLoader().LoadAssemblies(…).Build(), then only the types from assemblies explicitly given as a parameter are loaded as non-stub types. Alternatively, you can also use LoadAssembliesIncludingDependencies(…) which includes the direct dependencies of explicitly loaded assemblies or LoadAssembliesIncludingDependencies(…, true) which also includes transitive dependencies.

Regarding your picture, I could unfortunately not reproduce that. If I query a non-stub type through GetClassOfType then it is also non-stub when lookup up as the base class of another type.

As a next step, I would recommend including all dependencies in your architecture to rule out any other bugs. Also, could you check which version of the library you are using?

[micha-frey]

Hi @alexanderlinne,

the assemblies are loaded directly. In one case, alle types are in the same assembly. So, I don't think that it is related to missing loaded assemblies. And I would guess that I would not get any class if I would query one, that it is not loaded or just a simple "outside" dependency.

I tried to point out, that if I query for each class separately I get the non-stub instance. So, the information is somehow there, but the base classes are not using these instances, they are creating stubs.

If I try the reproduction in a simple test project, then I also had no success yet. There I get for the base classes the same instances as if I would query them directly.

Just a guess without looking in your code: Are there performance optimization rules that create stubs even if the real type is loaded in the architecture?

[alexanderlinne]

No, there are no such optimizations. In previous versions there were problems with multiple instances being created for the same type, but those should be resolved with 0.11.3. Did you check which version you are using?

[micha-frey]

Oh sorry, forgot to mention. We are currently with version 0.11.2. Would you recommend trying it with 0.11.3?

[alexanderlinne]

Yes, then we can rule out whether this has been fixed with the changes included in 0.11.3

[micha-frey]

With the version 0.11.3, I am getting exceptions during loading of the architecture (same key already added to dictionary). I am investigating. Stay tuned ;)

[micha-frey]

The exception is in the TypeFactory.GetOrCreateGenericInstanceTypeInstanceFromTypeReference(). By just looking at the code, I don't understand how this can happen besides parallel execution / parallel modifications of the _allTypes dictionary.

[alexanderlinne]

Since the methods creating the type instances are calling each other recursively this can happen when the same type that is currently being instantiated is also created as part of the recursive call. So we would need to add the type to the map before the recursive call in line 180 and add the generic arguments to the type instance afterwards. However, I can't come up with a test that leads to this error. At the point where the exception is thrown, could you have a look at the type that it is trying to add? Then we can maybe figure out the general structure of a type that leads to this behaviour and write a test case.

[micha-frey]

The issue seems to be a problem in the recursion. See the callstack

So, it passed (false branch) the TryGetValue check and then the method is called recursively adding the value and then it is not checked again whether the value is already in.

The type that is failing is "System.Linq.IGrouping`2<User,T>, System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

[micha-frey]

When I fix this dictionary issue locally, then it feels like the version 0.11.3 would fix the "stub"-issue :) So, maybe I will wait for the next version and try it again.