EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server

[LorenzMeyer]

Hi all

I don't know if I'm the only tracking down this problem.
Assume that you have a build server (like hudson) and you like to build all your assemblies and dlls on this build server.
Note: on a build server there is NO ArcGIS installed! And we do not deploy with VisualStudio!

So, does anyone have an idea, on how to create the registration files (*.ecfg), which will be deployed on the users machine. The suspicous "esriregasm.exe" tool does not work standalone, it seems, that ArcGIS has to be installed. Those *.ecfg files contain the category registration for ArcMap or what else. Without those files, the developed tools won't work.

So, any hints would be appreciated...

Regards from Switzerland...

[GeraldMarbury]

When you have assemblies that will not load then:

1. Use Reflector and walk the references.  Using it sort of like the old Depends utility if you are old school.  Unfortunately, RedGate charges for it now but it is worth it!


2. Use the fuslogvw utility.  Make sure to explicitly set a custom directory.

How .NET finds and loads assemblies is complex.  Oh how I miss the good-old-days of PATH:)

tried fuslogvw
*** Assembly Binder Log Entry  (4/4/2011 @ 3:19:11 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  c:\Program files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = Win7Test64\Tester
LOG: DisplayName = msvcm90, Version=9.0.30729.4940, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ESRIRegAsm.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: msvcm90, Version=9.0.30729.4940, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90/msvcm90.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Common Files/ArcGIS/bin/msvcm90/msvcm90.EXE.
LOG: All probing URLs attempted and failed.

[RichardWatson]

msvcm90 appears to be part of the C++ redistributable runtime.  If your software has a dependency on components which are not part of the OS and are not required by ESRI then you must redistribute them.

Google on "redistribute msvcm90".

[GeraldMarbury]

:)I had no "Visible" dependencies on msvcm90. However, I was using Dotfuscator to link and obfuscate my assemblies. It appears the problem went away when a changed the setting "Emit Debugging Symbols" from "JIT Optimization; Sequence Points from MSIL".

Theory: To emit debugging symbols, the assembly must be somehow tightly coupled with the 2.0 runtime, namely msvcm90.dll (although not visible via Reflector). When the 4.0 runtime was started via the "supportedRuntime version" tag in the ESRIRegAsm.config it had a reference to msvcm100 not msvcm90, thus causing the file not found error. This also explains why altering the config file of ESRIRegAsm got around the problem.

I put all this is here so the next poor soul will not waste their time too.

Happy hunting..