You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Frozen Rule does not work correctly for multiple Types with same FullName #344
@alexanderlinne I created a little test project here.
I added already a FrozenRules.json with one entry. When i run the test again, the test case is sucessfull and it will add a new entry. In my expectation the test should fail.
@NicolaSeitz Is this a new issue for you specifically with the 0.11.3 preview? I've tested your project and get the same result e.g. with 0.10.6. This would make it no blocker to release 0.11.3.
Regarding the bug: I think, as currently implemented, there is not really a correct behaviour for your example. Frozen rules use the classes FullName as an identifier for the type and can therefore not differentiate between both classes. So given two failures, how would ArchUnitNET know which one was supposed to be accepted.
To resolve this, frozen rules would need to use the assembly qualified name to differentiate between these classes, but this would be a breaking change and would have to wait until we release 0.12
I discovered it when testing v0.11.3-preview, but haven't tested the current versions, sorry about this. But in this case, it is a no blocker for v0.11.3 and as you described, it probably would be a breaking change and therefore hast to wait until v0.12.
We do not currently have a roadmap for upcoming releases, they will be released as they are ready. I'll see to release 0.11.3 within the next days and then we can see how we may implement this.
I've started implementing a solution, but I'll need more time to find a proper solution to this problem. So I'll remove the milestone for now.
The Assembly Qualified Name cannot directly be used here since it also includes, among other things, the version number of the assembly, so each update would break the tests.
Activity
alexanderlinne commentedon Feb 14, 2025
@NicolaSeitz Is this a new issue for you specifically with the 0.11.3 preview? I've tested your project and get the same result e.g. with 0.10.6. This would make it no blocker to release 0.11.3.
Regarding the bug: I think, as currently implemented, there is not really a correct behaviour for your example. Frozen rules use the classes FullName as an identifier for the type and can therefore not differentiate between both classes. So given two failures, how would ArchUnitNET know which one was supposed to be accepted.
To resolve this, frozen rules would need to use the assembly qualified name to differentiate between these classes, but this would be a breaking change and would have to wait until we release 0.12
NicolaSeitz commentedon Feb 17, 2025
I discovered it when testing v0.11.3-preview, but haven't tested the current versions, sorry about this. But in this case, it is a no blocker for v0.11.3 and as you described, it probably would be a breaking change and therefore hast to wait until v0.12.
Do you have a Roadmap for the Releases?
alexanderlinne commentedon Feb 25, 2025
We do not currently have a roadmap for upcoming releases, they will be released as they are ready. I'll see to release 0.11.3 within the next days and then we can see how we may implement this.
alexanderlinne commentedon Jul 11, 2025
I've started implementing a solution, but I'll need more time to find a proper solution to this problem. So I'll remove the milestone for now.
The Assembly Qualified Name cannot directly be used here since it also includes, among other things, the version number of the assembly, so each update would break the tests.