topic Re: EsriRegAsm.exe - creating *.ecfg files for Assemblies/Dlls on a build server in ArcObjects SDK Questions

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

LorenzMeyer — Tue, 15 Mar 2011 20:02:13 GMT

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

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

MichaelRobb — Tue, 15 Mar 2011 20:06:02 GMT

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

It was my understanding, from the Developer Summit, you must have a Licensed Product on the deploying machine.

The option, that may not work as ESRI does not use Registry to listen for Component Categories Items anymore, was to deploy using for example, an MSI such as Advanced Installer and use RegSvr32 for example, to register the .dll.

an XML file (config) is also created.
There is some info here as well:
http://blogs.esri.com/Dev/blogs/arcgisdesktop/

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

LorenzMeyer — Wed, 16 Mar 2011 09:07:09 GMT

It was my understanding, from the Developer Summit, you must have a Licensed Product on the deploying machine.

The option, that may not work as ESRI does not use Registry to listen for Component Categories Items anymore, was to deploy using for example, an MSI such as Advanced Installer and use RegSvr32 for example, to register the .dll.

an XML file (config) is also created.
There is some info here as well:
http://blogs.esri.com/Dev/blogs/arcgisdesktop/

Thanks for your reply.
ESRI is no longer using the registry for the component category registration. They now generate those *.ecfg (xml in a zip file) with the EsriRegAsm.exe tool. Those file then have to be installed in the following folder: %Program files%\Common Files\ArcGIS\Desktop10.0\Configuration\CATID
Our setup (installshield) copies those file to this location. We do not trigger the EsriRegAsm.exe tool in our setup.
At the moment, those *.ecfg files are generated by a developer (ArcGIS installed) with the EsriRegAsm tool and then included into the setup (for deployment). What we like to do now, is to generate those files directly on a build server, so that no developer has to generate them manually. It can not be, that on a build server, a licensed ArcGIS has to be installed, only for generating those files.
The other problem we have is, that we deploy our products against different ArcGIS versions, so we have to compile against different ArcGIS versions. The necessary libraries are all in the subversion system and we reference the libaries from this location. So installing ArcGIS on a build server is definitly not solution...

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

RichardWatson — Wed, 16 Mar 2011 17:02:39 GMT

I generated a number of these early in the 9.4 beta cycle for my VB6 projects.

The files are nothing more than xml configuration files in a renamed zip file. Just rename the ecfg to zip and then unpack them to discover the format. Once you know the format then you can generate them yourself.

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

GeraldMarbury — Fri, 01 Apr 2011 01:40:31 GMT

There appears to be a weird file not found error occuring on some custom DLL's when EsriRegAsm is being executed on Windows 7 x64. I believe ESRIRegAsm is loading Framework 4's 64bit RegAsm which in turn can't find the ESRI Framework 2.0 32bit dlls.

I say this because, when I modified C:\Program Files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe.config

from this

<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
    <supportedRuntime version="v2.0.50727"/>
</startup>

to this

<startup useLegacyV2RuntimeActivationPolicy="true">
   <supportedRuntime version="v2.0.50727"/>
</startup>

ESRIRegAsm.exe worked...

Also anybody thinking they can avoid using EsriRegAsm by using IComponentCategoryManager. Don't waste your time. IComponentCategoryManager does NOT register in the ecfg file. It puts it in COM!   ESRI, it would be nice if there was a IComponentCategory2 that could read and write the ecfg's correctly.

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

MichaelRobb — Fri, 01 Apr 2011 01:45:47 GMT

There appears to be a weird file not found error occuring on some custom DLL's when EsriRegAsm is being executed on Windows 7 x64. I believe ESRIRegAsm is loading Framework 4's 64bit RegAsm which in turn can't find the ESRI Framework 2.0 32bit dlls.

I say this because, when I modified C:\Program Files (x86)\Common Files\ArcGIS\bin\ESRIRegAsm.exe.config

from this

<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
    <supportedRuntime version="v2.0.50727"/>
</startup>

to this

<startup useLegacyV2RuntimeActivationPolicy="true">
   <supportedRuntime version="v2.0.50727"/>
</startup>

ESRIRegAsm.exe worked...

Also anybody thinking they can avoid using EsriRegAsm by using IComponentCategoryManager. Don't waste your time. IComponentCategoryManager does NOT register in the ecfg file. It puts it in COM!   ESRI, it would be nice if there was a IComponentCategory2 that could read and write the ecfg's correctly.

When you compile, because objects are still 32 bit, you must choose x86 as a CPU, not using 'ANY', otherwise, it will as you stated, your program dll will look for 64 bit files that don't exist.

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

GeraldMarbury — Fri, 01 Apr 2011 03:16:53 GMT

When you compile, because objects are still 32 bit, you must choose x86 as a CPU, not using 'ANY', otherwise, it will as you stated, your program dll will look for 64 bit files that don't exist.

Nice try Robb, I appeciate the quick response. I tried this and it still it didn't work. Like I said, what's weird is all my DLL's are "Any CPU" and some of them work, and some of them don't. The other interesting tidbit is since I made the change you suggested, although it does not create the ecfg files the error from RegAsm is not consistent with the error from EsriRegAsm. Now the 64bit RegAsm on the machine are raising

"Failed to load XXXXXX because it is not a valid .NET assembly"
where RegAsm used to say

"Could not load file or assembly 'ESRI.ArcGIS.System, Ver
sion=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86' or one of its dependencies. The system cannot find the file specified.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe [DLL PATH HERE] and
v/s
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe [DLL PATH HERE]

but the EsriRegAsm doesn't mention "Fail to load", it's still says "cannot find the file"

Excerpt of EsriRegAsm.exe output
**********************************
ESRIRegAsm::Register
Command line: "[DLL PATH HERE]" /p Desktop /e

Registry Capture On.
Registering managed library...
Managed Exception: The system cannot find the file specified. (Exception from
HRESULT: 0x80070002)
Registry Capture Off.

Operation Failed
04C10848

**********************************

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

MichaelRobb — Fri, 01 Apr 2011 13:57:53 GMT

Its Mike, you need to be using 3.5 framework, not 4 (that is not until release 10.1) from what I understood at the summit: You can not be using 'any CPU' when compiling and sending off to a 64 bit run processor hence why i mentioned x86. You can no longer use RegASM as a means, hence why esri incorporated their own. If your stating your dlls are ANY CPU, you will see failures as you see. You can verify this by hitting a 32 bit machine, and everything probably works. Hence why unable to find 10.0 esri.arcGisSystem dll, because they are only 32 bit dlls

Are you using .net 2010 professional or similar?
Which arc are you using? SP1 installed?
Have you tried contacting someone from ESRI?

Have you read http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/What_s_new_for_developers_at_10/0001000002zp000000/

and http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/ESRIRegAsm_utility/0001000004n6000000/

The registration logic within existing libraries does not need to be rewritten (categories are still identified using globally unique identifiers [GUIDs]), but existing libraries must be re-registered with ESRIRegAsm.exe or they will not function with any installation of ArcGIS after version 9.3.1.

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

GeraldMarbury — Fri, 01 Apr 2011 17:32:38 GMT

1) "Any" minny miny moe: When creating ArcGIS desktop extensions it doesn't matter which platform you use because ArcMAP/ArcCatalog with be the process and it is x86. Eitherway I tried the x86 option too.

2) Why RegAsm: The only reason I used RegAsm was to try to debug what was going wrong with ESRIRegAsm. ESRIRegAsm registers the assembly and listens for COM writes to the registry. I figured if RegAsm was having problems too, the problem was not in ESRIRegAsm

3) Are you using .net 2010 professional or similar? VS2008
4) Which arc are you using? SP1 installed? ArcGIS 10 sp1
5) Have you tried contacting someone from ESRI? Not yet, I was hoping somebody was watching this blog. I'm currently working on a way to write the xml file myself and pass it to ESRIRegAsm.

6) Have you read http://help.arcgis.com/en/sdk/10.0/a...00002zp000000/
and http://help.arcgis.com/en/sdk/10.0/a...00004n6000000/
LOL--Of course many, many times. Even when back to 9.4 version to see what changed. .

Thanks for your help Mike (Sorry O called you Robb)

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

RichardWatson — Fri, 01 Apr 2011 21:56:00 GMT

When you have assemblies that will not load then:

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!

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:)

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

GeraldMarbury — Mon, 04 Apr 2011 18:21:35 GMT

When you have assemblies that will not load then:

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!

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.

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

RichardWatson — Mon, 04 Apr 2011 18:29:57 GMT

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

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

GeraldMarbury — Tue, 05 Apr 2011 02:47:53 GMT

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