Archloader.Build() throws exception if project file contains UserSecretsId-Attribute

[SeEnglert]

Reproduction steps:

• Create a new Project
• Add UserSecretsId attribute to the PropertyGroup. E.g.:

<PropertyGroup>
  ...
  <TargetFramework>net9.0</TargetFramework>
  <UserSecretsId>abcdefgh-ijkl-mnop-qrst-uvwxyz123456</UserSecretsId>
  <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
  ...
</PropertyGroup>

• Execute "new ArchLoader().LoadAssemblies(assemblies.ToArray()).Build();" and pass the assembly with the UserSecretsId attribute into LoadAssemblies()
• The execution of Build() fails and an exception is thrown:
  System.ArgumentException: 'Attribute type Microsoft.Extensions.Configuration.UserSecrets.UserSecretsIdAttribute is not an attribute.'

[jpdurot]

Hello @SeEnglert,

I just started playing with this library yesterday so my answer may not be 100% relevant, but I faced a similar issue. I don't think it's specifically related to User Secrets attribute but more by the fact that the library containing the attribute you mention has not been loaded by the ArchLoader.
After digging into the code, I could spot the location where the issue happens:

ArchUnitNET/ArchUnitNET/Loader/MonoCecilAttributeExtensions.cs

Lines 20 to 27 in 929d0cb

	var attributeType = typeFactory.GetOrCreateStubTypeInstanceFromTypeReference(
	attributeTypeReference
	);
	if (!(attributeType.Type is Attribute attribute))
	{
	throw new ArgumentException(
	$"Attribute type {attributeType.Type.FullName} is not an attribute."
	);

#
The attributeType variable is of type TypeInstance<UnavailableType> and so attributeType.Type property is not of Attribute type.
I guess there is something different when handling types for which we don't have any information, but for attributes I think we could still create an attribute model even if we have no clue what this class is about because by design in C# every annotation on a class, method, property, field has to inherit from Attribute

@alexanderlinne Would you have an idea how to handle this use case ? I would be happy to help but I don't have any knowledge about this library yet.

[alexanderlinne]

Hi @jpdurot, I've actually had this exact error myself one time when working on ArchUnitNET itself. In this case a test that loads assemblies by filename was failing with some other attributes. The cause was that I had older .NET 8 binaries in my bin folder that the tests were trying to load. My assumption is that they were built with a different runtime version, but I had cleaned my repository trying to resolve this issue and was not able to reproduce it afterwards.

So my first assumption would be that this may be something similar. However, @SeEnglert mentions that this also happens with a completely new project. I'd be reluctant to introduce additional special logic here, especially since this type should be available.

@SeEnglert could you provide an example repository that demonstrates the issue?

[jpdurot]

Thanks for the quick reply! I'm realizing that I forgot to mention the exact context:
I get the issue when analyzing a single DLL (with nothing else in the directory) and got the issue because I had the HttpGet attribute on some methods of my class (it's a controller). AspNetCore framework libraries not being loaded in my context (console application creating an Architecture through ArchBuilder), I think that's why I faced this issue.
I would love to use your library to analyze dependencies between all my assemblies but don't want external dependencies to whatever runtime and/or third-party nuget packages. ( I would like to have only my assemblies in a directory)
Currently it kind of work for dependency to external types, I mean there is no exception like for external attributes, however they are considered as belonging to the assembly I'm analyzing (I can understand we don't get the real assembly since we don't have any information about it)

[jpdurot]

I could spend more time digging into the code of the library to understand. I talked about 2 different things in my previous comment that are actually not related, let's go back to the original issue about attributes (I will open a new issue to discuss the second one)

When analyzing the types to get the dependencies, if a dependency is not part of the loaded assemblies, it ends up creating an instance of UnavailableType and it works perfectly. However, when it comes to attributes the library throws an exception which seems, to me, an inconsistent behavior compared to other kind of types.
I tried to replace the code throwing the exception by:

if (!(attributeType.Type is Attribute attribute))
{
    attribute = new Attribute(attributeType.Type, null, null);
}

and it seems to work, when I navigate through dependencies of my assembly (arch.Types.SelectMany(type => type.Dependencies)) I can see types from external assemblies as well as attributes.
I think this replacement is fine since all C# annotations are by design inheriting from System.Attribute, please correct me if I'm wrong

[alexanderlinne]

So I was able to replicate this error as a test case and think that you are correct in that it should be handled similarly to what we currently have with UnavailableType. However, just wrapping the returned type as an attribute would lead to somewhat inconsistent behaviour. We would then have it added as an Attribute to the assembly but only added as UnavailableType to the architecture.

[jpdurot]

Is there anything better we could do in this case ? I mean, in a context where assemblies are provided manually the user must be aware that some info will be missing because he's not providing a full context. When dealing with attributes I see 2 options: either we add it as an attribute object, or we discard it. We could also create an UnavailableAttribute class (inheriting Attribute) to better reflect (semantically speaking) the information we have about it, but in the end we will always have an UnavailableType added to the architecture.

[alexanderlinne]

For now, we can avoid the bug by wrapping the UnavailableType. I think the proper solution will be to change the type of Attributes in IHasAttributes from IEnumerable<Attribute> to IEnumerable<IType>. Then we have the fact that the attributes must not necessarily be available properly reflected in the interface. This is a breaking change, so I'd implement this in a later version.

[alexanderlinne]

@jpdurot As a follow up: is your use case that you do not have the dependencies of the loaded assembly available, or would they be available but are just not loaded by ArchUnitNET?

[jpdurot]

Sorry for the last reply. In my use case I have a directory with all the assemblies built by our CI (around 3,000) but no dependencies at all. I'm fine to have UnavailableType for every external type, I can know from which assembly they belong to so it's enough