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

LorenzMeyer · ‎03-15-2011

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

MichaelRobb · ‎03-15-2011

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/

LorenzMeyer · ‎03-16-2011

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

RichardWatson · ‎03-16-2011

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.

GeraldMarbury · ‎03-31-2011

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.

MichaelRobb · ‎03-31-2011

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.

GeraldMarbury · ‎03-31-2011

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

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

MichaelRobb · ‎04-01-2011

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

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

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.

GeraldMarbury · ‎04-01-2011

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)

RichardWatson · ‎04-01-2011

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