Reverse looking up a .NET assembly dependency.
Has anyone had the joy of figuring out what application installed an assembly into the global assembly cache? I have some Citrix servers with additional assemblies in their global assembly cache and I need to figure out what application installed these so we can figure out what is different in the build process of the servers. Any ideas?
I've looked at the manifest for the dll but unfortunately it doesn't say more than it's own configuration.
I've looked at the manifest for the dll but unfortunately it doesn't say more than it's own configuration.
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
AngelD
16 years ago
Have no qlue but maybe one of these can help
ActiveX/COM Inspector
http://oaklandsoftware.com/download_inspectors.html
Select "Show GAC Panel" from Options -> Panels
Then in the GAC tab right-click the Global Assembly and select Open
Others:
Reflector
http://www.aisto.com/roeder/dotnet/
Remotesoft .NET Explorer
http://www.remotesoft.com/dotexplorer/
ActiveX/COM Inspector
http://oaklandsoftware.com/download_inspectors.html
Select "Show GAC Panel" from Options -> Panels
Then in the GAC tab right-click the Global Assembly and select Open
Others:
Reflector
http://www.aisto.com/roeder/dotnet/
Remotesoft .NET Explorer
http://www.remotesoft.com/dotexplorer/
Posted by:
kkaminsk
16 years ago
That's definitely a great set of tools! What I am seeing from my research and looking at these tools is that you can find out what an EXE is dependant on for .NET assemblies but it is probably impossible to reverse look up the dependency. If someone made a command line tool to read EXE headers and output the .NET assembly dependencies then I'd be in business.
Fortunately I found my issue, I had to second guess the patch level answer I got and found that the systems that were different had the XMLParser version 4 SP2 installed. I thought an application installed these .NET assemblies but it looks to be a more recent version of the parser. Thanks for that tool list AngelD! I'll definitely be keeping those in my pocket for future .NET headaches.
Fortunately I found my issue, I had to second guess the patch level answer I got and found that the systems that were different had the XMLParser version 4 SP2 installed. I thought an application installed these .NET assemblies but it looks to be a more recent version of the parser. Thanks for that tool list AngelD! I'll definitely be keeping those in my pocket for future .NET headaches.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.