Recommended way to have some config file (json) for all the addins to read .net sdk

1496
8
01-22-2023 10:33 PM
JohnP18
New Contributor II

I have a JSON file containing some settings like API URLs which will be used by multiple add-ins to call those APIs. 

Is there a ESRI recommended way to add and read a JSON having app configuration settings from all the add-ins?

Any ideas?

@Wolf @UmaHarano @GKmieliauskas 

Tags (1)
0 Kudos
8 Replies
JMalik
by
New Contributor II

ESRI recommends using the ArcGIS Pro SDK for .NET to create add-ins for ArcGIS Pro. Within the SDK, there are several options for storing and reading app configuration settings. One option is to use the Pro SDK's 'Project' class, which provides access to the project's properties and can be used to store and retrieve custom data, such as your JSON file containing API URLs. Another option is to use the 'System.IO' namespace to read and write JSON files directly.

You can also use the 'ProEnvironment' class to store the settings, this class allows you to store settings in the environment and get it from the environment.

It is worth noting that the choice of storage method will depend on the specific requirements of your add-ins and the data being stored.

0 Kudos
JohnP18
New Contributor II

Are there any code snippets for that as I couldn't find any in the samples? 

And I was thinking of using .NET IConfiguration way but couldn't think a way to achieve it. Basically where the JSON will be added in the project structure and then how to read those settings from all the add-ins since generally in every .NET app we have startup class which makes it easy to ready configuration which is  little bit different in any ArcGIS Pro's add-in project structure. 

@JMalik 

0 Kudos
JMalik
by
New Contributor II

There are no specific code snippets for using the IConfiguration class in an ArcGIS Pro add-in, as it is not a recommended approach by ESRI. However, you can use the IConfiguration class to read and parse a JSON configuration file in an ArcGIS Pro add-in, similar to how you would use it in a standard .NET application.

One way to achieve this is to store the JSON configuration file in a location that is accessible to all add-ins, such as a shared network location or a location within the ArcGIS Pro installation directory. Then, in the add-in's code, you can use the IConfiguration class to read and parse the JSON file.

Here's an example of how you can read and parse a JSON configuration file in an add-in using the IConfiguration class:

using Microsoft.Extensions.Configuration;

...

// Build the configuration object
var builder = new ConfigurationBuilder()
    .SetBasePath(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "config"))
    .AddJsonFile("settings.json", optional: true, reloadOnChange: true);

IConfiguration config = builder.Build();

// Access the settings from the configuration object
string apiUrl = config["ApiSettings:Url"];

In this example, the code assumes that the JSON configuration file is located in a "config" folder in the add-in's installation directory and is named "settings.json". The SetBasePath method is used to specify the path to the configuration file, and the AddJsonFile method is used to add the JSON file to the configuration object. Once the configuration object is built, you can use the config object to access the settings in the JSON file using the config["setting_name"] syntax.

You may also want to consider storing the configuration file in a location that is accessible to all add-ins, such as a shared network location or a location within the ArcGIS Pro installation directory, and use the appropriate programming language to read and parse the JSON file.

0 Kudos
JohnP18
New Contributor II

So JSON will not be added in the project structure? Will putting the JSON in the installation directory a good approach?  Shouldn't the JSON file in the project structure a better option? 

@JMalik 

0 Kudos
GKmieliauskas
Esri Regular Contributor

I use my own configuration interface and implement that interface to each add-in Module Class. For your case it would be something like that:

 

    public interface IMyConfiguration
    {
        string JsonSetting { get; set; }
    }

 

Main add-in sets JsonSetting property  from your prefered source. Others read that setting from main add-in like this:

 

        public string JsonSetting
        {
            get
            {
                    // get the configuration module:
                    var configModule = FrameworkApplication.FindModule("MainModule"); // Main module ID from daml
                    if (configModule is IMyConfiguration)

                    {
                        IMyConfiguration configInterface = configModule as IMyConfiguration;
                        return configInterface.JsonSetting;
                    }

                    return null;
                }
                catch (Exception ex)
                {
                    return null;
                }
            }
        }

 

0 Kudos
JohnP18
New Contributor II

My confusion is still where will be JSON file be stored in the project structure which will be for all the add-ins and how will we read the JSON from the project structure? And what is MainModule in your case? And what do you mean by main add-in where  JsonSettings is implemented?

@GKmieliauskas 

0 Kudos
GKmieliauskas
Esri Regular Contributor

As @JMalik said, JSON file store place depends on your workflow. You can store in project settings if your user wants to modify JSON file place or content. You can store in add-in config file. This way for advanced user. You can store JSON file as add-in's resource if you don't want to let change something and etc.

My application consists of some add-ins. One of them is responsible for project/application settings, license and etc. I am calling it as "main module". All other add-ins get application sensible information from "main module". "Main module" Json settings property would look like that:

public string JsonSetting
{
    get { 
        // your implementation
        return GetJsonString(); 
    }
}

 

0 Kudos
mody_buchbinder
Occasional Contributor III

I use system variables that all AddIns can read.

Environment.GetEnvironmentVariable("SomeVar")

It is easy to maintained by the system people, easy to change locally for debug and easy to give good error message in the code when it does not exists. 

0 Kudos