Using custom dlls in multiple arcmap applications

Anonymous User

Original User: Steve Clark

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.

path_distance_problem2.jpg

path_distance_problem.jpg

JamesCrandall

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.

Steve, if I am undertstanding your requirements correctly...

FWIW, I have a couple of deployed ArcGIS COM applications that reference several other assemblies that reside on a network shared drive.  Honestly, I am uncertain if this is an "advisable" approach, but as long as my users have access to those shared drives on the network, I have had zero issues with multiple users/installs accessing the objects that get created and destroyed in these assemblies.

These assemblies are typical middle/end layers in a larger n-Tier architecture.  So, for example the presentation tier is representative of the COM assemblies that install on the users machine and run as ArcGIS extensions/toolbars.  These assemblies are the presentation portion within the architecture, so typical windows forms and UserControls are what they consist of.  the Business and DataAccess layers are more traditional conceptualized portions of a data management application.

Anyway -- hope this helps.