topic VB6 in ArcObjects SDK Questions

Custom extensions

Anonymous User — Fri, 23 Oct 2009 13:56:33 GMT

Original User: 164549

None of my custom developed extensions are showing up under Customize->Extensions, yet all the ESRI extensions are there. Is there some new development process or different setting needed to make them show up?

Custom extensions

SteveVan_Esch — Fri, 23 Oct 2009 21:53:57 GMT

Yes, at 9.4 the registration step has changed. Use the ESRIRegAsm.exe instead of Microsoft's regsvr32.exe.

ESRIRegAsm /p desktop /v 9.4 "C:\Test\MyAssembly.dll"

If you installed the ArcObjects SDK you should be able to right-click on the dll and see 'Register 9.4 Assembly'.

See this topic in the help:

ArcObjects SDK for Microsoft.NET/Migrating and upgrading your code/Migration from 9.3 to 9.4/Migrating ArcGIS 9.3 Desktop and Engine custom components to ArcGIS 9.4

Please post back if you're still having problems.

Thanks,
Steve

Custom extensions

Anonymous User — Mon, 26 Oct 2009 13:17:16 GMT

Original User: 164549

Thanks for your response, but we seem to be in a "catch-22" situation.

1) we create C++ COM extensions for ArcGIS Desktop, and deploy them with InstallShield; just like we always have. (Where's the C++ SDK??)

2) our customers do not have Visual Studio.

3) the ESRIRegAsm.exe utility does not install in the typical installation, apparently the .NET SDK is required, which further requires Visual Studio 2008.

How do Business Partners deploy our products at 9.4?

Custom extensions

Anonymous User — Mon, 26 Oct 2009 13:32:19 GMT

Original User: 164549

whoops!! just realized the ESRIRegAsm.exe is not under the c:\Program Files\ArcGIS, but is under c:\Program Files\Common Files\ArcGIS.

This brings up additional questions:

1) During ArcGIS install, is any type of Registry scanning done to ensure already installed custom components are put through this new "ESRI-special" registration?

2) If not, then ESRI expects every vendor to distribute special installations or custom scripting just to run the ESRIRegAsm.exe utility for 9.4 customers?

3) Is the ESRIRegAsm.exe utility re-distributable to ensure our products install correctly on any version of ArcGIS Desktop?

4) Very curious to the ESRI thoughts behind the impact of this change on Business Partners and all third-party vendors.

5) Also, (maybe wrong forum) where is the C++ SDK?

Custom extensions

Anonymous User — Mon, 26 Oct 2009 14:52:32 GMT

Original User: 164549

One more item just discovered: C++ extensions register fine with the ESRIRegAsm.exe utility; however, VB6 extensions report that they register, but there is no evidence of the extension or tools under the Customize menu. If a VB6 DLL is added manually via the Add From File, the tool bars and commands show up, but the extension is still not present.

What can be done about VB6 extensions?

Custom extensions

RalfGottschalk — Mon, 26 Oct 2009 16:04:04 GMT

Unfortunately VB6 is no longer support at 9.4 and you will not be able to get your VB6 customizations installed.

See this blog post for details on how to migrate away from VB6 at 9.4.

1. No, it is ESRI's policy that you must build your application for the release that you want to deploy to. In the past you did not need to do this, but unfortunately we do not provide support this type of workflow.

2. Yes, it has always been ESRI's policy that you would need to do this.

3. Yes, the SDK should include deployment samples and instructions soon.

4. The policy hasn't changed, however, changes to the system now require you to redeploy your application.

5. The C++ SDK is not available at Beta 1. It should be ready soon.

Thanks,

Ralf

really NO registration of VB6 developed dll's?

Anonymous User — Fri, 30 Oct 2009 10:19:22 GMT

Original User: natalie.pieper

Dear ESRI Team,

Existing VB6 Extensions will not longer be supported?!

We develop on ArcGIS Desktop since V8.1 and still have a lot of tools and older products on VB6.

In former documentation and all 9.4 announcements, ESRI told us that there will be no more SDK for VB6. So far, so good... that's understandable and OK.

So it was clear for us that it's strongly recommanded to migrate those of our extensions to VB.NET, that are in maintenance and that are developed on further. That's OK, we do that step by step.

But what about all the small extensions and tools, that work fine until now? In former documentation you told us, that we are "strongly encouraged to mígrate to .NET", not that we are "forced" to to that.
Of course, we will do that step by step for every product that will be developed further. But all at one time, just to be available on ArcGIS 9.4?

We have a large number of older extensions and tools that work fine. No one needs changes in that tools - and no one wants to pay for migrating them to .NET.

Is it really policy of ESRI that NO existing VB6 extensions will be installable on ArcGIS 9.4?

I tried to register some vb6 dll's by ESRIRegasm. exe, but this didn't work, as user 164549 described. Not even with parameter /c . Does this really only works for C++???

Custom extensions

RalfGottschalk — Mon, 02 Nov 2009 14:55:13 GMT

Hi Natalie,

You are correct. VB6 is not supported at all at 9.4. Microsoft does not sell or support VB6 anymore, which means we can�??t fix any bugs or issues with VB6. We will not be supporting the installation or usage any VB6 extensions or applications. There have been a few announcements on ESRI�??s plans to move away from VB6. We have this documented in both the Deprecation Plans and the UC Q& A.

I�??m not sure what your extensions are doing, but if they are fairly small, you might want to try to look into using Add-ins with Visual Studio Express, if cost of Visual Studio is an issue. I know this does not cover the cost of the labor it takes to migrate the code but it might be a good intermediate step.

Parameter �??/c�?� is actually a documentation error, this parameter does not exist in the tool. NIM050463 has been logged to remove this parameter from the documentation.

Can 9.4 extensions work in 9.3 and 9.2 ?

Anonymous User — Tue, 03 Nov 2009 08:58:33 GMT

Original User: erik_nyberg

We have extensions that now works in 9.2, 9.3 and 9.3.1 (same installer).
What we do is to compile our dll-s on 9.2 and then it works in all the versions. In 9.4 however it looks like you have changed the ESRI.ArcGIS.ADF assembly so you now have to add ESRI.ArcGIS.ADF.Local in order for them to work in 9.4.

Is there a way to make our extensions to work in all the versions (9.2,9.3 and 9.4) through a single dll or do we have to create a new dll for 9.4?

VB6

RichardWatson — Tue, 03 Nov 2009 17:28:31 GMT

It is surreal that VB6 extensions or applications will no longer work in 9.4. I thought that ESRI used COM and VB6 was COM. Isn't that a binary contract?

What makes C++ work but not VB?

This position is not consistent with that shared with us at the Developer Summit conference. Yes, we know that VB6 is end-of-life. Yes, we know that we have to rewrite the software. The difference here is that you have created a hard wall. This is really not an acceptable position.

Getting VB6 to register

Anonymous User — Wed, 04 Nov 2009 13:14:29 GMT

Original User: rlwatson

It appears to me that when you run the ESRIRegAsm tool that it produces a file in the following directory:

C:\Program Files\Common Files\ArcGIS\Desktop9.4\Configuration\CATID

The name of the file is something like {GUID}_name.ecfg. The file itself is really a zip file which contains a file named config.xml. It appears that ArcMap is using this file to determine component categories versus that which is in the registry.

I did the following:

1) Used the VB6 sample which has a tool bar, extension, and zoom in and out commands and built the DLL and reg file needed on a 9.3.1 system
2) Tested the sample on 9.3.1; no problems
3) Tested the sample on 9.4 using ESRIRegAsm; it does not work
4) Went to the CATID directory, extracted the config.xml, manually repaired the XML, and put it back in the zip
5) Tested the sample, no problems

ESRI, why don't you provide a trivial tool which does this?

Custom extensions

Anonymous User — Wed, 04 Nov 2009 17:07:11 GMT

Original User: vanesch

Although ESRI no longer provides technical support for VB6 development, you can still register VB6 component libraries with ArcGIS 9.4. The ESRIRegAsm utility supports aâ??currently undocumentedâ??command line option (/l) to generate the clsid to categoryID mappings. One or more pairs may be listed.

esriRegAsm.exe /l <clsid><catid>[<clsid><catid>â?¦]

The example below registers project1.dll and produces a configuration file (.ecfg) containing two mappings: a command in the ArcMap commands component category, and an extension in the ArcMap extension component category:

c:\Program Files\Common Files\ArcGIS\bin>esriregasm c:\example\project1.dll /v 9.4 /p desktop /l {64C75217-013A-4739-9666-C8DFE10796C1}{B56A7C45-83D4-11D2-A2E9-080009B6F22B}{2d257f20-7dc5-4421-950c-2ffd661de1e9}{B56A7C42-83D4-11D2-A2E9-080009B6F22B}

You can obtain the category GUIDs using the ESRI provided category manager (categories.exe in the bin folder).

Note that you can execute esriRegAsm from your setup program, or you can continue to use self registration and have the setup copy the pre-generated configuration files to the appropriate well known folder.

Also note that ESRI no longer installs Microsoftâ??s VB6 runtime DLLs, and several VB6 runtime DLLs have been removed by Microsoft for security reasons.

This blows

BillSmith — Wed, 04 Nov 2009 22:10:18 GMT

gottralf wrote:
.....
1. No, it is ESRI's policy that you must build your application for the release that you want to deploy to. In the past you did not need to do this, but unfortunately we do not provide support this type of workflow.
....

This really makes it hard for ESRI business partners to play nice with ESRI products. Our software package is at least as big as ArcMap and has had an extension to communicate between the two for years to do 3D extraction. Now we are supposed to build different versions depending on what version of Arc the end user is running. I can tell you now that this will not happen. We will have to decide whether to tell our users to stick with pre-9.4 or force them to upgrade. Neither is an attractive option.

Custom extensions

Anonymous User — Thu, 05 Nov 2009 15:20:44 GMT

Original User: natalie.pieper

@ vanesch, gottralf: could you please talk to each other and tell us what is the truth? Sorry, perhaps I do not understand it right, but I think your both information are inconsistent with another?

gottralf wrote: "We will not be supporting the installation or usage any VB6 extensions or applications."

vanesch wrote: "Although ESRI no longer provides technical support for VB6 development, you can still register VB6 component libraries with ArcGIS 9.4. The ESRIRegAsm utility supports a�??currently undocumented�??command line option (/l) to generate the clsid to categoryID mappings."

I tested your sample with that command line option (/l) immediately with a vb6 dll, but I only got the message "Registration failed" and do not know why.

Before I spend more time in trying, please tell me:

Is it possible to registrate vb6 extensions with esriregasm.exe or is it not?

Regards
Natalie

Custom extensions

RalfGottschalk — Fri, 06 Nov 2009 15:43:49 GMT

@erik_nyberg:
The supported workflow would be to create a new dll for 9.4.

@ rlwatson:
We do not provide a tool to register a VB6 component because we do not support the use of VB6 at 9.4. If you figure out a way to do this there is nothing stopping you from registering your VB6 extensions with 9.4. However, we will not provide Technical Support or log any bugs for any problems that you encounter with this workflow.

@nemesisity
I understand that this is not an ideal option for developers, however, we have always not supported this kind of workflow. Things do change from release to release and it would not be possible for us to officially support a component that spans multiple versions. This does not mean that it cannot be done, but we cannot guarantee that it will work, and we will not provide support or log/fix bugs for issues encountered with this workflow.

@natalie.pieper
Vanesch and I are essentially saying the same thing. We are both saying that ESRI will not provide support for VB6 at 9.4. Registering a VB6 dll may be possible for you to do in certain scenarios, but we will not document, provide technical support, or guarantee that this will work all the time. If you have figured out a way for it to work then you can do so at your own risk.

I hope this helps and clears up some of the confusion. I understand that this may be frustrating to you, but our support policy has not changed. (Aside from deprecating support for VB6)

ESRIRegAsm

Anonymous User — Mon, 16 Nov 2009 17:32:37 GMT

Original User: rlwatson

ESRIRegAsm does not seem like a good tool for registering assemblies during installation.

The behavior seems to be that it creates a process and returns immediately.

It would seem more reasonable that the utility would block until the registration is complete and return an exit code indicating whether or not the registration was successful.

Try to run this tool on a couple of hundred DLLs and see what happens. It is not pretty!

Custom extensions

SteveVan_Esch — Thu, 19 Nov 2009 14:59:26 GMT

Can you post exactly how you are using the utility.

Thanks,
Steve

ESRIRegAsm

Anonymous User — Thu, 19 Nov 2009 19:48:50 GMT

Original User: rlwatson

I considered calling it on a large number of assemblies as part of the installer process. In order to simulate that I simply wrote DOS script which uses a for loop that iterates over all the assemblies in a directory and calls ESRIRegAsm on each of them. What I saw was that it created a massive number of processes which quickly consumed the system. Apologies, if I have all of this wrong but I cannot see how the utility can be used in this context.

I think that the tool could be improved by:

1) Making it synchronous when run in silent mode
2) Changing it to return an exit code which indicates whether or not it was successful

Custom extensions

AndryJoos — Tue, 15 Dec 2009 13:49:49 GMT

It appears to me that when you run the ESRIRegAsm tool that it produces a file in the following directory:

C:\Program Files\Common Files\ArcGIS\Desktop9.4\Configuration\CATID

The name of the file is something like {GUID}_name.ecfg. The file itself is really a zip file which contains a file named config.xml. It appears that ArcMap is using this file to determine component categories versus that which is in the registry.

We have developed a small function that can write these files in our custom registration mechanism. Now I have a few questions, that I'm sure someone at ESRI can answer:
* Any special requirements for the XML, the filename of the XML (needs to be config.xml?) Where's the XSD? Is it somewhere available?
* The {GUID}_name.ecfg doesn't seem to be enforced. Any requirements to this? Can I name the file 'test.ecfg' and it works aswell?

From what I observe by now, neither 100% proper XML nor the filename format is enforced. I would like to hear how ESRI does handle this. I wouldn't want to rewrite the mechanism again and again for every new version, so some kind of specifications for the /CATID/ directory and it's contents would be highly appreciated.

Thanks & Greetings from Switzerland,
Andry

Custom extensions

Anonymous User — Wed, 06 Jan 2010 21:55:29 GMT

Original User: vanesch

When launching ESRIRegAsm on a large number of assemblies--say from the command line--instances of the utility do not run synchronously (the second starts before the first finishes, etc.)

Like Microsoft�??s RegSvr32.exe, ESRIRegAsm is a standard Windows application and will not display a console window, and will not block the calling process when launched (only console applications block in such situations). ESRIRegAsm will run synchronously if called from a bat file, and most installers (including Microsoft Installer) offer an option to wait for a utility launched during the install. In most cases, it makes more sense to generate the configuration files ahead of time, and then simply copy these files to the appropriate destination folder as part of the setup (rather than running ESRIRegAsm at all on the target machine). The ESRIRegAsm utility will return 0 on success.