8

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).

chandler
  • 1,134
  • 1
  • 17
  • 33
  • 2
    What does "specific to my projects" mean? At runtime, there is no notion of "your solution" as opposed to "packages"; there are just assemblies. – SLaks Jun 29 '16 at 20:22
  • You can't get that at run-time - at run-time there's no distinction between a project reference and an assembly reference. You'd have to look at the solution definition (`.sln`) file and determine the outputs for each project. What's the purpose? Why do you need to distinguish the two? – D Stanley Jun 29 '16 at 20:23
  • 3
    You can [apply a custom attribute to your own assemblies](http://stackoverflow.com/a/1936982/382780) to filter them. Is it an option to add this to the projects in your solution? – 31eee384 Jun 29 '16 at 20:24
  • 2
    "GetAssemblies ... get every assembly including your references." - while true may not mean what you seem to expect. `GetAssemblies` returns only assemblies loaded so far, and not *all* referenced assemblies. – Alexei Levenkov Jun 29 '16 at 20:25
  • @SLaks specific to my projects means specific to the projects in the solution – chandler Jun 29 '16 at 20:37
  • @31eee384 unfortunately that would not work in this context, thanks for the suggestion though – chandler Jun 29 '16 at 20:41
  • So you want to get a collection of `Assembly` objects for all of the DLLs that are built by projects in your solution? Is that right? – Zack Jun 29 '16 at 20:51
  • @Zack I want the assembly of the project itself like Project1.dll – chandler Jun 29 '16 at 20:56
  • It sounds like you want a list of strings that represent the names of the generated assemblies from projects in your solution... is *that* right? – Zack Jun 29 '16 at 21:03
  • @Zack yeah if it is the name of the actual project's dll – chandler Jun 29 '16 at 21:12

3 Answers3

21

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.

chandler
  • 1,134
  • 1
  • 17
  • 33
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.

Zoran Horvat
  • 10,924
  • 3
  • 31
  • 43
0

What I usually do in this case is setting a prefix name and then get all Assemblies with this prefix, for example, naming my projects like EX."ProjectName" I could use:

Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
List<Assembly> myAssemblies = new List<Assembly>();

foreach (Assembly assembly in assemblies)
{
    if (assembly.GetName().Name.Contains("EX."))
    {
        myAssemblies.Add(assembly);
    }
}

Hope this helps.

guijob
  • 4,413
  • 3
  • 20
  • 39