Replace TypeBasedComponentFinderStrategy's use of reflection about dotnet HOT 11 CLOSED

This might be a good starting point: https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/how-to-load-assemblies-into-the-reflection-only-context

from dotnet.

Thanks! The existing TypeBasedComponentFinderStrategy needs to continue to exist, because a number of existing users are stuck on .NET 4, which doesn't have access to Roslyn. But we could certainly create an additional strategy that uses Roslyn. I'm just finishing off some tweaks to the Structurizr for Java version, and will start work again on the .NET version very soon (there are some major features now missing; e.g. documentation and deployment diagrams).

from dotnet.

I actually started taking a look at using Mono.Cecil for analysis last night, although I didn't get too far. The nice thing about it is that it is still available for .NET 4.0 and apparently works faster than built-in .NET reflection. I'll keep on it after work today.

from dotnet.

Cecil might be the best option for maintaining support for older framework versions but it'd be a breaking change since Cecil's type metadata classes don't inherit from the abstract base types within .NET itself. Because of that, Component would need to have a public change for the TypeObject property and then through almost everything in the Analysis namespace (ComponentFinder and the abstract base ComponentFinderStrategy are the only reflection-agnostic types).

I think it'd be good to go through with this, but given the weight of the change I don't feel that it'd be appropriate to just do the work and PR it up without some discussion first.

from dotnet.

I've just started making some changes to the reflections-based analysis code (porting the changes I made to the Java version) and I don't think that TypeObject property is actually needed any more. :-)

from dotnet.

Well, it does get used in TypeBasedComponentFinderStrategy.FindDependencies but a move away from .NET reflection to Cecil or Roslyn would require that entire function to be rewritten anyway. I saw that the Model class would set the property as well but that's not really using it, heh.

from dotnet.

Are there further changes coming? Looks like there are still dependencies on reflection with ITypeMatcher and TypeRepository still using System.Type instead of CodeElement.

from dotnet.

I had a play with the reflection only loading and it doesn't quite work as well as simply loading the assemblies. I'm happy to split out the reflection code from the Structurizr.Core assembly so that you can implement a Cecil or Roslyn ComponentFinderStrategy. Thoughts?

from dotnet.

That might be a good idea, but ITypeMatcher I think should still eschew the use of System.Type so that its implementors could be used by the Cecil based strategy I'm considering, instead of needing to duplicate them.

from dotnet.

I've done the refactoring and the Structurizr.Core library can now be targeted at .NET Standard 1.3 (there were a few other .NET Framework dependencies that needed removing in addition to the reflection code). It should now be possible to use the Structurizr.Core library with UWP projects and create an implementation of the ComponentFinderStrategy that doesn't use reflection.

from dotnet.

Okay. I'll update what I've done probably some time on Saturday. I ended up creating a new project for a Cecil based analysis implementation that includes the full feature set of the reflection based analysis, although every type includes Cecil somewhere in the name which feels kind of gross.

I see three possibilities for "normalizing" the type naming for the analysis implementations. The first, which is easiest, would be to match Cecil in the type names in the Cecil implementation with Reflection in the reflection implementation. The second would be to move the reflection types to a new Structurizr.Analysis.Reflection namespace and the Cecil ones to Structurizr.Analysis.Cecil and have them share the same common names.

The third, which would be the most work, would be to create an abstract class for type data as provided by any particular reflection system (.NET reflection, Cecil, Roslyn, etc.) and create adapters for the type data classes from each system. That way, it might be possible to simply provide a concrete repository and adapter for each system.

I favour the third option for the long run, but either of the first two would probably be best for now.

from dotnet.