1

I am loading a dll from an external place using < codebase > element in the application configuration. I want to know where the assembly gets instantiated?

I made < codebase > to point to my local drive (outside of appbase) and also a network shared drive and ran the fuslogvw and process monitor to see what's going on. But I wasn't able to tell what's truely happening under the hood.

Link below explains as it goes to an application cache specific to the user. http://msdn.microsoft.com/en-us/magazine/cc164080.aspx

Link below explains as it goes to a special GAC cache. http://www.developer.am/c-net-platform/?page=understanding-the-codebase-element

Overall, I understand it as it should be loaded into some cache location but I was not able to confirm it. Please help. I like to know the exact location where the ddl is gets loaded and stored.

Thank you

hak
  • 11
  • 3

1 Answers1

0

The CLR will automatically download the file and store it in the user's download cache
A sub directory under
[WinRoot]\Documents and Settings\UserName\Local Settings\Application Data\Assembly.
When referenced in the future, the CLR will load the assembly from this directory rather than access the URL.

Mohsen Heydari
  • 7,256
  • 4
  • 31
  • 46
  • Hi, Thanks for the response, what format the file will have? Were you able to confirm on your local? I am using Windows 7 and I looked at the C:\users\\[username]\AppData\Local\assembly\ but I was not able to see anything new generated there after the dll is loaded. I am testing it with a console app. Either I am looking at a wrong user's folder or I am looking at a wrong location in windows 7. Can you please point me to a right place? Thank you so much. – hak Mar 18 '13 at 13:44
  • Is the DLL strongly Named or its a weaked Named assembly pal? – Mohsen Heydari Mar 18 '13 at 13:48
  • currently i have some DLLs (related to outlook addinns) on my local (windows7), here C:\Users\mheydari\AppData\Local\assembly\dl3\W3OHV7GR.ZXY\4R8GD7L0.88D\beac7d62\73ac084b_1502ce01 – Mohsen Heydari Mar 18 '13 at 13:51
  • It is strongly named. I see some dlls in the folder as well. I created a "helloworld" dll. strong named but this one doesn't show up in the folder. I see things like entity framework, hp, etc but I don't see my helloworld dll in the folder. That's why I am wondering where exactly this dll gets instantiated(loaded). – hak Mar 18 '13 at 14:30
  • in visual stadio comand prompt use "gacutil –l" to list dlls installed in Global Assembly Cash: http://msdn.microsoft.com/en-us/library/9x295t9k.aspx inform me you were successful, – Mohsen Heydari Mar 18 '13 at 14:45
  • it's not there. I ran the app to load the dll and tried "gacutil -l > C:\dlls.txt" but didn't find it in the log. I have a feeling that it might be using the dll directly from the filesystem or from the shared network loaction instead of downloading it to a local cache location. – hak Mar 18 '13 at 15:01
  • Below is the log from fuslogvw => Isn't it saying that it's using it from the network share? LOG: Attempting download of new URL file://servername/Packages/HelloWorld.dll. LOG: Assembly download was successful. Attempting setup of file: \\servername\Packages\HelloWorld.dll LOG: Entering run-from-source setup phase. LOG: Assembly Name is: HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fef53c419abf18d0 LOG: Binding succeeds. Returns assembly from \\servername\Packages\HelloWorld.dll. LOG: Assembly is loaded in default load context. – hak Mar 18 '13 at 15:07
  • see http://stackoverflow.com/questions/2092641/whats-this-folder-structure-for-local-user-gac – Mohsen Heydari Mar 18 '13 at 15:10
  • Is it because my user account has a full access to the network share? What happens if the app user doesn't have a full access? Will it then download the dll to a local cache? I am not sure if I am thinking logically here.. – hak Mar 18 '13 at 15:11
  • I might try that now. I will let you know. – hak Mar 18 '13 at 15:40
  • 1
    Finally, figured it out. If the codebase uses filesystem directly, the dlls are loaded from the folder directly even with the user account only have read access. if the codebase is uses http: then it's loaded into c:\\users\\username\\appdata\\local\\assembly\\d13\\ and this information can be seen by using System.Reflection.Assembly.GetExecutingAssembly().Location – hak Mar 18 '13 at 16:49
  • This is good because originally I was researching to see if this dll is loaded into the Gac or not because if the dll is loaded into Gac, it may impact other applications. Thank you for your help!! – hak Mar 18 '13 at 16:54
  • For the similar reason to the Shadow copy, using Http is a better solution than using the file system because when it's using the file system, the update of the dll cannot be done because during the execution it locks the dll. :) – hak Mar 18 '13 at 16:58