0

I'm using Spring.Net to dynamic load my object graph.

10 .exe consoles will start on the same time and via Spring.Net they will instantiate the same libraries. The consoles have no references to the libraries. 1 out of 10 times I get an Exception when Spring.Net (using reflection) creates the instances. I’m not sure why this happens, but probably it has something to do with the 10 consoles starting on the same time. It seems to happen often when the server has been rebooted (Windows Server 2008 R2)

Any ideas are appreciated!

Here is an stacktrace where it cannot load a reference to odp.net (referenced from the GAC)

System.IO.FileLoadException: Could not load file or assembly 'Oracle.DataAccess, Version=2.112.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)

Marijn
  • 10,367
  • 5
  • 59
  • 80
Stig
  • 1,974
  • 2
  • 23
  • 50
  • Are those libraries in the GAC or in the directory of the exe? – Daniel Hilgarth May 17 '11 at 07:23
  • Oracle.DataAccess is only in the GAC. – Stig May 17 '11 at 07:34
  • Are all exe files in the same directory? – Daniel Hilgarth May 17 '11 at 07:37
  • yes, 10 .exe in the same folder. – Stig May 17 '11 at 07:41
  • The simplest solution will be to put every exe into its own folder along with the required DLLs... – Daniel Hilgarth May 17 '11 at 07:44
  • I don't want to make a wrong workaround. I really like to know what goes wrong! – Stig May 17 '11 at 08:08
  • Nothing goes wrong. You have ten applications that try to access the same files at the same time and therefore they block each other. – Daniel Hilgarth May 17 '11 at 08:36
  • Oracle.DataAccess is not in the folder but only in the GAC. Also i want to see documentation that says it is error prone to run mulitple .exe in the same folder. – Stig May 17 '11 at 08:56
  • Just use your own head. The problem is that those programs seem to start *at the same time*. If they try to access the same file at the same time, it will result in the above exception. Period. Don't be so stubborn. – Daniel Hilgarth May 17 '11 at 08:58
  • BTW: Your [other problem](http://stackoverflow.com/questions/6014500/enterpriselibrary-the-process-cannot-access-the-file-because-it-is-being-used-b) is also caused by this. – Daniel Hilgarth May 17 '11 at 09:00
  • Hi Daniel. I do not think I am stubborn. All to often a developer fix a problem by fixing the wrong issue. Often this gives problems later on. If it is discouraged by Microsoft of course I would split it up. But if this is not the problem I want to fix the real issue. – Stig May 17 '11 at 09:25
  • Sure, curing the real problem is always preferred. But me and other people (in the other question), already told you, what the real problem is. The provided solution isn't a workaround. Not believing us is stubborn and makes me wonder, why you are asking in the first place. – Daniel Hilgarth May 17 '11 at 09:30
  • And by the way. Oracle.DataAccess is (as I wrote) loaded from the GAC so I do not see how your solution should fix anything! – Stig May 17 '11 at 09:31
  • BTW: It has nothing to do with Microsoft or .NET per se. As I already said a few times: The problem is that several processes try to access the same file at the same file. And that's it for me. Do what ever you want. – Daniel Hilgarth May 17 '11 at 09:31
  • Hi Daniel, please comment on the fact that Oracle.DataAccess is in the GAC. Why should splitting the .exe to different folders help? I appreciated any help. – Stig May 17 '11 at 10:03
  • Not just the exes. Also the referenced assemblies, including Oracle.DataAccess. – Daniel Hilgarth May 17 '11 at 10:04
  • So you discouraged the use of GAC? I would think that MS would have made this flawless... There are lots of reasons to use the GAC so i cannot stop using it. – Stig May 17 '11 at 10:21
  • MS discourages it themselves: http://msdn.microsoft.com/en-us/library/yf1d93sz%28v=VS.100%29.aspx: "You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private". – Daniel Hilgarth May 17 '11 at 10:26
  • MS writes _You should share assemblies by installing them into the global assembly cache only when you need to_. The Oracle dll's comes with the installation of a Oralce client. There can be different version on each server, therefor you should never distribute the Oracle.DataAccess.dll with your program. Unfortunately. – Stig May 17 '11 at 10:34
  • then the existence of the private DLL is per deployment. You should provide the .dll and just delete it if the target server has a specific version installed. – Jaguar May 17 '11 at 15:12

0 Answers0