How to get the assemblies for each project in a solution not including references?

Question

Sorry if this is a repost/duplicate but I couldn't find anything relevant.

Here is what I have tried:

var assembly = Assembly.GetExecutingAssembly();

which gets you the executing assembly and with

var assemblies = AppDomain.CurrentDomain.GetAssemblies();

which can get every assembly including your references.

However, I want all the assemblies of the solution's projects (not packages/references).

Answer 1

In the meantime I am going to use

AppDomain.CurrentDomain.GetAssemblies().Where(x => x.FullName.Contains("SolutionName"));

because all my project's names include the solution name.

Not ideal and hope that someone has a better solution.

Answer 2

Others have already pointed out that there is no distinction among assemblies. Once you build the solutions, all deployed assemblies are just assemblies, whether your or included as references, it's all the same.

The only exact solution is to have the .sln file at your disposal. It is just an XML file with simple scheme and it is easy to dig data from it, provided that you do have access to it.

Another option might be to apply heuristics to make a distinction. For example, you may try to figure namespaces from types in the executing assembly. That is the entry point of the application and hence we could argue that it must have been part of the solution.

Then you can inspect assemblies obtained from GetAssemblies() and then inspect namespaces of types found contained in them. If you find overlapping between (parts) of namespace paths between some assembly and the executing assembly, you could declare them coming from the same source.

Once again, this is only a heuristic and it won't be satisfactory in general case. As a matter of fact, it is quite easy to come up with a counter-example.

But on the other hand, if I take my own solutions as a test set, this heuristic would work perfectly fine, thanks to the fact that all of my projects are coming with root namespace which is my company's name, and which is not true for the - quite obvious in this restricted domain.

One obvious counter-example is when you deploy some of your own projects as NuGet packages. Then they would share the namespace, but will not be part of the solution.

Bottom line is that this heuristic solution probably won't solve your problems. But I hope you will be able at least to pick part of it and mix it together with other ideas to come up with a proper solution.