<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Using custom dlls in multiple arcmap applications in ArcObjects SDK Questions</title>
    <link>https://community.esri.com/t5/arcobjects-sdk-questions/using-custom-dlls-in-multiple-arcmap-applications/m-p/208573#M5430</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Original User: Steve Clark&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 17 Feb 2011 17:55:50 GMT</pubDate>
    <dc:creator>Anonymous User</dc:creator>
    <dc:date>2011-02-17T17:55:50Z</dc:date>
    <item>
      <title>Using custom dlls in multiple arcmap applications</title>
      <link>https://community.esri.com/t5/arcobjects-sdk-questions/using-custom-dlls-in-multiple-arcmap-applications/m-p/208573#M5430</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Original User: Steve Clark&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 17 Feb 2011 17:55:50 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcobjects-sdk-questions/using-custom-dlls-in-multiple-arcmap-applications/m-p/208573#M5430</guid>
      <dc:creator>Anonymous User</dc:creator>
      <dc:date>2011-02-17T17:55:50Z</dc:date>
    </item>
    <item>
      <title>Re: Using custom dlls in multiple arcmap applications</title>
      <link>https://community.esri.com/t5/arcobjects-sdk-questions/using-custom-dlls-in-multiple-arcmap-applications/m-p/208574#M5431</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;BLOCKQUOTE class="jive-quote"&gt;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.&lt;/BLOCKQUOTE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Steve, if I am undertstanding your requirements correctly...&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;FWIW, I have a couple of deployed ArcGIS COM applications that reference several other assemblies that reside on a network shared drive.&amp;nbsp; 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.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;These assemblies are typical middle/end layers in a larger n-Tier architecture.&amp;nbsp; So, for example the presentation tier is representative of the COM assemblies that install on the users machine and run as ArcGIS extensions/toolbars.&amp;nbsp; These assemblies are the presentation portion within the architecture, so typical windows forms and UserControls are what they consist of.&amp;nbsp; the Business and DataAccess layers are more traditional conceptualized portions of a data management application.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Anyway -- hope this helps.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 22 Feb 2011 14:01:29 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcobjects-sdk-questions/using-custom-dlls-in-multiple-arcmap-applications/m-p/208574#M5431</guid>
      <dc:creator>JamesCrandall</dc:creator>
      <dc:date>2011-02-22T14:01:29Z</dc:date>
    </item>
  </channel>
</rss>

