I'll do my best to ask my question. I develop a number of COM-based libraries for use within custom arcmap dlls (using ArcGIS 9.3.1 SP2, .NET 2008 C#). These would include a custom arcobjects "helper" library. The issue is how best to deploy and manage these common dlls. The safest way seems to have the setup program create a folder for each application and have it include all of the supporting dlls needed for that application. This has been successful for years but I wonder if this is the best practice for COM-based libraries? On a deployment PC, there would be multiple copies of the custom "helper" library (for example), some with different versions but so far, the same GUID and strong-named. Is it possible (or even advisable) to use a single deployment of common dll? If I can be pointed to an article or white paper or something that talks about this, that would be great too. Thanks.

1 Answer 1


If your .NET shared library contains any types registered with COM, then yes, a single deployment location is the way to go. After all, a single class GUID can only point to a single codebase location when registered in the system registry.

This will not work if you have multiple versions of the same COM component, though. In this case, you might consider registration-free COM deployment.

When developing your shared library in .NET, it is best to avoid having any COM-registered types in it. If you do not need to consume them from COM, you can keep them in pure .NET. Deployment in the GAC works well in such scenarios.

  • +1 Good answer. I'd be interested in hearing a good practice that assures arcobjects extensions get uninstalled when arcgis is uninstalled. I've had problems uninstalling extensions after 9.3.1 is uninstalled. gis.stackexchange.com/questions/1510/… Feb 17, 2011 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.