Could not Load File or Assembly

[MichelleBoivin]

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\XXXX. ... 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?

[RichardWatson]

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.

On which machine is the .exe executing?  Note that I am not asking where it physically is but rather on which machine is it running on.  Sounds like it is running on the x86 machine and that machine does not have the ESRI bits installed.  It won't use the assemblies on the 64 bit machine unless the .exe is executing on that machine.

[MichelleBoivin]

On which machine is the .exe executing?  Note that I am not asking where it physically is but rather on which machine is it running on.  Sounds like it is running on the x86 machine and that machine does not have the ESRI bits installed.  It won't use the assemblies on the 64 bit machine unless the .exe is executing on that machine.

Thanks you for your response.
I believe the ,exe is executing on the x86 machine but being called from the x64 machine. The SQL job Step syntax is an OSCmdExec, calling this executable from the x64 machine "\\GIS_LM\ArcGIS\Custom\Executables\ParcelsImport.exe" -s GS002. GS002 is the server variable that is being passed. So basically what you're saying is the "idea" of having everything on one machine and hitting the SQL database server won't work without having AT LEAST the .NET assemblies installed on the SQL databser server?

[RichardWatson]

The .exe has to run on the machine with the ESRI bits installed.  I don't quite understand your configuration/situation but it appears that the database is on the x86 machine and that you are launching a process, from SQL*Server, on that machine using CmdExec.  That fact that the physical .exe is on another machine is not relevant.

I think that most large users run the database on a machine which either has no ESRI bits installed or just ArcSDE (a.k.a. ArcGIS Server Enterprise Basic).  That works for them because they are not trying to use CmdExec.  Windows provides the ability for processes to communicate across machines so if your database really needs to do this then you could architect a solution which would accommodate your configuration.  This starts to get deep.

[MichelleBoivin]

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.....

[RichardWatson]

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.

[AlexanderGray]

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.