VS 2008 GetReferencedAssemblies

[gduke24]

When I call this sub in VS 2008 I am only getting the references returned that are used in my assembly. Is there a method that returns ALL references?

Thanks!

 

[JohnH]

You can call it recursive for each assembly. Since there are cross-references the list would never stop if you didn't keep track of already listed assemblies, this can for example be done with a dictionary. Here's some sample code:

Private references As New Dictionary(Of String, Reflection.AssemblyName())
Private Sub ListAllReferencedAssemblies(ByVal asm As Reflection.Assembly)
    Dim name As String = asm.GetName.Name
    If Not references.ContainsKey(name) Then
        references(name) = asm.GetReferencedAssemblies()
        For Each asmName As Reflection.AssemblyName In asm.GetReferencedAssemblies()
            ListAllReferencedAssemblies(Reflection.Assembly.ReflectionOnlyLoad(asmName.FullName))
        Next
    End If
End Sub

A sample call for current assembly, and displaying the list by writing it to console:

references.Clear()
Me.ListAllReferencedAssemblies(Me.GetType.Assembly)
For Each asm As String In references.Keys
    Console.WriteLine("assembly {0} has these references:", asm)
    For Each asmName As Reflection.AssemblyName In references(asm)
        Console.WriteLine(vbTab & asmName.Name)
    Next
Next

 

[gduke24]

Yes, we discussed that, but unfortunatly that would cost me too much running time. Uh, what about altering the way I am building the dlls? Is there a way to possibly include all references in a dll when building in 2008?

 

[JohnH]

Yes, we discussed that, but unfortunatly that would cost me too much running time.

? The code I posted finishes within a few milliseconds.

Uh, what about altering the way I am building the dlls? Is there a way to possibly include all references in a dll when building in 2008?

Are you talking about unused references? If so I think you may be confusing loaded assemblies with references.

 

[gduke24]

? The code I posted finishes within a few milliseconds.

Yea, we have written our own deployment mechanism. I would have to loop through recursively and cross check against what I had already deployed evertime I wanted to deploy a new program.

Are you talking about unused references? If so I think you may be confusing loaded assemblies with references.

Yes, sorry I am talking about unused references. I need these references to be included within the dll so maybe the GetReferencedAssemblies would read them from the dll and I wouldn't have to change my architecture.

 

[JohnH]

The point is that when compiling an assembly any design-time references are discarded if no type of that assembly is actually used in code. So at runtime the GetReferencedAssemblies return all the references the assembly rely on. If an assembly load other assemblies at runtime with reflection you have to look into the AppDomain.GetAssemblies which lists all loaded assemblies. Apart from that I fail to see how a design-time reference that is not used conflicts with your deployment strategy.

 

[gduke24]

Alright, so how do I get the references I want from AppDomain.GetAssemblies if the assembly is different from the current one running?

 

[JohnH]

What is an AppDomain?

Represents an application domain, which is an isolated environment where applications execute.

So the only way to see what goes on in an AppDomain is to run the app, or load the assembly into the current executing domain, or create a new domain and load the assembly there.

AppDomain.GetAssemblies is not about references, it is about assemblies that are actually loaded in the domain at the current time of execution.

I still don't see what relevance an unused design-time reference has. If it is so crucial for you to include this in the type information why not actually use a type in the assembly? You only need a variable declaration to do that. Also since this is about design-time references why don't you just read the project file?

 

[gduke24]

What is an AppDomain?

So the only way to see what goes on in an AppDomain is to run the app, or load the assembly into the current executing domain, or create a new domain and load the assembly there.

AppDomain.GetAssemblies is not about references, it is about assemblies that are actually loaded in the domain at the current time of execution.

I still don't see what relevance an unused design-time reference has. If it is so crucial for you to include this in the type information why not actually use a type in the assembly? You only need a variable declaration to do that. Also since this is about design-time references why don't you just read the project file?

We are talking about a huge application here with hundreds of programs which was all built on top of each other. It would cost me months to go through and declare variables for all the unused references. I would love to just read and parse the project file, but it is not included with what we deliver to our customers. Can I get all the unused references using the AppDomain.GetAssemblies? Is this even practical? I really would just love the compiler to include them when compiling the dll so that the GetReferencedAssemblies would pull them back.

 

[gduke24]

Does anybody know if Microsoft deployment will do this?

 

[JohnH]

Can I get all the unused references using the AppDomain.GetAssemblies? Is this even practical? I really would just love the compiler to include them when compiling the dll so that the GetReferencedAssemblies would pull them back.

No, it was only suggested as a possibility to find additional reflection loaded assemblies at runtime (after they are actually loaded), since it was unclear what you were doing, and that you were indicating a use for types not declared in code.
The compiler doesn't include these references because no part of the compiled code is using them. So why are these assemblies even referenced in source project?

Does anybody know if Microsoft deployment will do this?

Yes, MS deployment reads the project file and includes all files specified.

 

[gduke24]

No, it was only suggested as a possibility to find additional reflection loaded assemblies at runtime (after they are actually loaded), since it was unclear what you were doing, and that you were indicating a use for types not declared in code.
The compiler doesn't include these references because no part of the compiled code is using them. So why are these assemblies even referenced in source project?

They are underlying classes that were created to add possible future flexibility to enable changing DBs if we so desired for instance (just one possibility among others). These classes are never run by themselves, but they are essential. They are referenced in my project because I need to use the base and the base needs to use these projects. So, in turn my project needs to reference everything from the base as well to complete the heirchy.

The problem with the recursion is that it will get all the files, but it has to get the same files everytime a new project is run and there are hundreds of files before you reach the base.

Yes, MS deployment reads the project file and includes all files specified.

How does this work if the project files aren't included as part of the running system.

 

[JohnH]

because I need to use the base and the base needs to use these projects.

Well, I not argue more about this, but if any part of your code uses a type from a referenced assembly then that assembly will be included in the GetReferencedAssemblies list, if not is has no place in the compiled assemblys type system

How does this work if the project files aren't included as part of the running system.

Are you kidding? Project files along with other source files are never deployed with the compiled assemblies they produce. When compiled the application is finished in the development process, after deploying it to client the user can run the exe and have fun with the application you wrote. In basic terms the development and deployment process:
A: write code, VS save in text file.
B: compile, VS reads the text file and make the binary assembly, for example an exe file.
C: deploy, copy the exe (usually by a proper installer) to client system.
D: client can consume the application by executing the exe.

 

[gduke24]

Well, I not argue more about this, but if any part of your code uses a type from a referenced assembly then that assembly will be included in the GetReferencedAssemblies list, if not is has no place in the compiled assemblys type system

I never came in here to argue. I came in here for some help. My problem is that the GetReferencedAssemblies isn't pulling all the references listed in my project because some aren't used. I wanted to know if there is a way to retrieve those reference names from the dll OR if they aren't included in the dll is there a way to force the compiler to include them?

Are you kidding? Project files along with other source files are never deployed with the compiled assemblies they produce. When compiled the application is finished in the development process, after deploying it to client the user can run the exe and have fun with the application you wrote. In basic terms the development and deployment process:
A: write code, VS save in text file.
B: compile, VS reads the text file and make the binary assembly, for example an exe file.
C: deploy, copy the exe (usually by a proper installer) to client system.
D: client can consume the application by executing the exe.

Once again I think your under estimating the scope of my project. I contain over 2000 dlls and about 1000 exes. That is what my folder contains. As the system runs I am going to need to deploy down these files from this folder. This folder doesn't contain any vb.proj files. So, it will grab a dll and get its referenced assemblies and so forth recursively until it has retreived all the assemblies needed to run?

 

[JohnH]

My problem is that the GetReferencedAssemblies isn't pulling all the references listed in my project because some aren't used. I wanted to know if there is a way to retrieve those reference names from the dll OR if they aren't included in the dll is there a way to force the compiler to include them?

No. When not used they remain project references that can only be packaged from the project meta sources, but they are not assembly references.