Could not Load File or Assembly

Question

Migrating in numerous ways.....

Trying to run an .exe (VS2010), from SQLServer 2005 DB as a SQL job. SQL DB is on x86 machine (Server 2003), .exe is on x64 (Server 2008 R2)machine, as is all ArcGIS software, license manager, etc.
     * Note: The same job ran fine with everything loaded onto the SQL DB box. SDE and ArcGIS Desktop were installed.

Migration entailed removing all ArcSDE & ArcGIS components from the SQLServer box and loading them onto the Server 2008 R2 box.

When running the job, I am receiving the following error:

Executed as user: Domain\xyz. ... System.TypeInitializationException: The type initializer for 'ParcelsImport.modParcelsImport' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'ESRI.ArcGIS.System, Version=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86' or one of its dependencies. The system cannot find the file specified.  File name: 'ESRI.ArcGIS.System, Version=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86'     at ParcelsImport.LicenseInitializer..ctor()     at ParcelsImport.modParcelsImport..cctor()    WRN: Assembly binding logging is turned OFF.  To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.  Note: There is some performance penalty associated with assembly bind failure logging.  To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].       --- End of inner exception stack trace ---     at ParcelsImport.modP.  The step failed.

I verified that the .dlls were referenced on the x64 machine and that they were in the GAC. I also read some other threads that talked about changing the build from "Any Computer" to x86, but this has not worked for me.

Does anyone have any suggestions?

AlexanderGray · Answer

Right now we have a separate DB group who manages the majority of the City's databases. Then we have our SDE databases. What the overall intent is, is to have the SDE databases on our own SQL Server instance apart from an instance that currently has not only our databases, but other databases in the same instance of SQL Server.

In addition, the idea was to also separate out the license manager and all ArcSDE components to its own server, separate from the database server.

I don't view any of that being an issue as ESRI supports the separation of ArcSDE from SQL. However, what I am trying to trouble shoot is all the peripheral montage that comes with it. Prior to our separation (or if you would like, still currently in production) are numerous SQL jobs that we run on a nightly, weekly, and monthly basis. These jobs can include SSIS packages, .exes, and python scripts. The idea was to take these "GIS-oriented" pieces and put them on the ArcSDE server (not the database server), so everything is in one (a GIS Server/non-database) location and let the jobs continue to run, but call the .exes from a different location. It seems to work just fine (on other .exes) until I get to the "GIS" executables.

This is the direction management wanted to head, so I get to figure it out.....I did modify the reference paths in the .exe to use a universal naming convention so it should be able to access the .dlls on the other server, I would think. Still at a loss.....it almost seems like something very small.....

Richards post is right the dlls must be installed on the server calling the exe, he gets the points.

I am not sure why you need an ArcSDE server at all.  ArcGIS desktop, server, engine do direct connect to the database server very well.  All you need is the Geodatabase/arcsde schema installed on your database, you don't actually need ArcSDE running.  Your ArcSDE server could become your GIS server with the ArcGIS components installed.  In any case you will need to figure out how to launch the jobs remotely from the database server to the GIS server.  You could have a service running on the GIS machine that looks to a job queue and have the database server place a request in that queue to launch a specific exe with specific arguments, that could be as simple as a file placed in a folder on the remote GIS server.  There are other ways of making remote calls too that are worth investigating before implementing anything.

RichardWatson · Answer

I did modify the reference paths in the .exe to use a universal naming convention so it should be able to access the .dlls on the other server, I would think.

That is not how the Microsoft assembly loading mechanism works.  It is going to look in the GAC of the server which is executing the bits and not the server that the executable image is on.

If you really want to understand this then you can use the fuslogvw utility.  Microsoft calls the assembly loading machine Fusion and this is the Fusion Log Viewer.

MichelleBoivin · Answer

Right now we have a separate DB group who manages the majority of the City's databases. Then we have our SDE databases. What the overall intent is, is to have the SDE databases on our own SQL Server instance apart from an instance that currently has not only our databases, but other databases in the same instance of SQL Server.

In addition, the idea was to also separate out the license manager and all ArcSDE components to its own server, separate from the database server.

I don't view any of that being an issue as ESRI supports the separation of ArcSDE from SQL. However, what I am trying to trouble shoot is all the peripheral montage that comes with it. Prior to our separation (or if you would like, still currently in production) are numerous SQL jobs that we run on a nightly, weekly, and monthly basis. These jobs can include SSIS packages, .exes, and python scripts. The idea was to take these "GIS-oriented" pieces and put them on the ArcSDE server (not the database server), so everything is in one (a GIS Server/non-database) location and let the jobs continue to run, but call the .exes from a different location. It seems to work just fine (on other .exes) until I get to the "GIS" executables.

This is the direction management wanted to head, so I get to figure it out.....I did modify the reference paths in the .exe to use a universal naming convention so it should be able to access the .dlls on the other server, I would think. Still at a loss.....it almost seems like something very small.....