 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / April 2005Detect if assembly exists
Hi, I'd like to know if an assembly exists in the GAC or directory, and therefore can be loaded if required. The only thing I know about the assembly is it's fullname like the AssemblyName.FullName property. I found out I could try to load the assembly with Assembly.Load() and catch the FileNotFoundException, but this would also load the assembly if it exists. I only want to check if it exists. A workaround would be using Assembly.Load in a separate AppDomain, and unload the domain after I am finished. But that seems to be quite nasty to me. How do I determine if an assembly (by it's fullname) exists in a proper way? > I'd like to know if an assembly exists in the GAC > or directory, and therefore can be loaded if required. [quoted text clipped - 4 lines] > Assembly.Load() and catch the FileNotFoundException, > but this would also load the assembly if it exists. For assembies in the GAC you can use the barely documented interface to query it. For unamanged access to the native GAC (IAssemblyCache) interface: http://blogs.msdn.com/junfeng/articles/229648.aspx For managed wrappers to the GAC interface: http://blogs.msdn.com/junfeng/articles/229649.aspx KB article on the same topic: http://support.microsoft.com/?id=317540 I'm not sure what your options are for assemblies outside of the GAC if, as you say, you don't want to load them. Regards, Will > For managed wrappers to the GAC interface: > > http://blogs.msdn.com/junfeng/articles/229649.aspx Thank you! I needed that. It's a better resource then what I found. > I'm not sure what your options are for assemblies outside of the GAC if, as > you say, you don't want to load them. Well, I have been thinking on that. And I think I have found a solution. Not sure for that, so if someone could verify it? I found out that I can get the AssemblyName of a .NET .dll file (aka assembly) by simply calling the static method AssemblyName.GetAssemblyName(). The only parameter is a filename string. The remarks of this method: > This will only work if the file contains an assembly manifest. This method causes the file to be opened and closed, but the assembly is not added to this domain. Now I only need to know the assemblies which the CLR would load in the filesystem (not the GAC). I think I can determine the directory which the CLR will try to search for the files by getting the AppDomain.BaseDirectory property. However, does the CLR search in subdirectories? And ís this the directory the in which the CLR will search? With the directory I can search for .dll files, and try to get the AssemblyName with the mentioned method. And with the managed GAC interfaces I can search for the AssemblyName in the GAC. So this would be the answer to my question. But is it? Could someone verify my solution? Unfortunately AFAIK the only way to really tell is to actually load the assembly, especially if you want to know specifically which one would get loaded (in case there are more then one). There are binding redirects, publisher policy, machine policy, search paths and search order, etc. that all effect which assembly, if any, will actually get loaded. Loading it into another appdomain does work and it's not particularly nasty, but it is slow. You could turn on shadow copying so you could update the bits without unloading the appdomain. > Hi, > [quoted text clipped - 21 lines] > > <Id>0vTSK2aLzUuYKFCKl7ZnBA==</Id> David Levine schreef: > Unfortunately AFAIK the only way to really tell is to actually load the > assembly, especially if you want to know specifically which one would get > loaded (in case there are more then one). There are binding redirects, > publisher policy, machine policy, search paths and search order, etc. that > all effect which assembly, if any, will actually get loaded. Well, in my case it does not matter which assembly will be loaded. However, I have not thought about the security policies. Also config files could change the behaviour. Moreover, it is even possible that the assemblies are not available anymore at the time they are requested. (dynamic assemblies over HTTP?) > Loading it into another appdomain does work and it's not particularly nasty, > but it is slow. You could turn on shadow copying so you could update the > bits without unloading the appdomain. I am worried about the memory space the executing computer will need. The fact is, I am working on a module framework with the modules distributed in packages (ZIP-archives). In every package is a metadata file included with AssemblyName's in string format. I want to check if all the referenced assemblies exist, before loading the package, to improve performance and to notify the user about the conflicting package if necessarily. It is very possible that the loader would have to load a large amount of assemblies in the AppDomain, because of all the references in the packages (think about all the .NET class library references!). The reason why I'd like to check the references is because it would be stupid if a user would have to download and *run* a package to see if the required assemblies are installed. Therefore I'd like like to check this even before the package is executed. So, could this "check" action require so much memory of the computer that it would cause an enormous performance drop? If not, then this solution would be not so bad after all... Bart Verkoeijen >> Loading it into another appdomain does work and it's not particularly >> nasty, but it is slow. You could turn on shadow copying so you could [quoted text clipped - 19 lines] > it would cause an enormous performance drop? > If not, then this solution would be not so bad after all... Just loading the assembly does not cause all the other assemblies it statically references to get loaded - that only happens when the assembly executes some code that refers to a type that is defined in another assembly. Another issue with pre-checking is that it will only detect if all required static dependencies are present, but dynamic references cannot be check in that manner. For example, if the assembly called Load (or one of its variants) you have no way of knowing what it is trying to load until it actually executes. Another issue is if you want to check system assemblies you need to know what the CLR binding policy is for the application - use the latest or use only a specific version. For example, if the application is built against v1.1 of the CLR and the machine it is installed on only has v2.0 installed, then it might run using v2.0 of the CLR, or it might insist on using only v1.1. There is nothing in the manifest to indicate which option to use - it is a host configurable option. I think a better approach would be to require that all required non-system assemblies are part of the zip file, and write a little verification program to check that. This way you do the validation at packaging time and not at runtime, and you also ensure that all possible required assemblies are distributed along with the module. Also, I would not worry about the system assemblies - don't even check them. If that's not suitable then I'd not do any checking...if a required assembly is missing then it wont load or will fail shortly thereafter. David Levine schreef: > I think a better approach would be to require that all required non-system > assemblies are part of the zip file, and write a little verification program > to check that. This way you do the validation at packaging time and not at > runtime, and you also ensure that all possible required assemblies are > distributed along with the module. Also, I would not worry about the system > assemblies - don't even check them. Actually, I have implemented this already. A package can contain "library" assemblies. These assemblies are required by "module" assemblies. However, I did not like the idea of many different packages containing the same library-assemblies. Therefore these common assemblies should be shipped with the Host. But this will require the check again... But then again, if I publish a new version of the Host, and the strong named common assemblies have changed, many old packages could be broken! This would not be the case if the required assemblies are included in the package. Therefore my "same" a few sentences ago isn't right: "same" also requires versions to be equal. I think it is very difficult to ship common assemblies with the host. The GAC is not invented without a good reason... ;) Therefore, I have to agree with your advice, and try to forget the size of the packages... ;) Thanks for your help! Your reply realy got me thinking... -- Bart Verkoeijen > However, I did not like the idea of many different packages containing the > same library-assemblies. Therefore these common assemblies should be [quoted text clipped - 11 lines] > > Thanks for your help! Your reply realy got me thinking... Glad I could help. I'm working on solving a similar (more complex) problem right now.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.