Shell package configuration best practices

Discussions related to SoftPro Select user interface development.

Moderator: Phil Barton

turp1twin
Posts: 13
Joined: Tue Aug 20, 2019 4:32 pm

Shell package configuration best practices

Post by turp1twin » Wed Aug 28, 2019 5:25 pm

Hey SoftPro peeps,

So reading through the SDK help file and this support forum, I am having a hard time getting a "best practices" view of handling configuration for a shell package (dll). Perhaps part of the problem is I am a long time JVM developer but new to .Net (well, I haven't done any .Net development in a long, long time). I noticed that the shell template project that comes with the SDK creates an app.config file which upon building gets turned into a "dll-name.dll.config" file. That being said, it doesn't appear to be used or loaded by the ConfigurationManager in .Net. I have certain config settings that I need to set, and currently, I have had to set them in the select.exe.config file. Is this standard practice? If so, do most people update this file in the shell package installer? Perhaps I have missed a section in the SDK help file, or a post in this forum, but any pointers, sample code/projects, information, would be greatly appreciated.. Cheers!

Jeff

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Wed Aug 28, 2019 5:52 pm

You have not missed anything in the SDK. DLLs usually don't have config files of their own in .NET. See C# DLL config file in .NET.

If you need a place to stash editable information, you are free the use the special folders lookup features. See Environment.GetFolderPath(..). There are folders dedicated to application data (Select) and user data (current logged in user).
Bob Richards, Software Developer, SoftPro

turp1twin
Posts: 13
Joined: Tue Aug 20, 2019 4:32 pm

Re: Shell package configuration best practices

Post by turp1twin » Wed Aug 28, 2019 6:20 pm

Thanks! I will follow the link you sent me. As for the select.exe.config file there are some settings I need to put in here, specifically, I had to work around a json libray conflict by adding this to the "runtime" section:

<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="11.0.0.0-11.0.2.0" newVersion="11.0.0.0" />
<codeBase version="11.0.0.0" href="Newtonsoft.Json-11.0.2.dll"/>
</dependentAssembly>
<dependentAssembly>

It seems to me that it would make most sense to update this file in the shell package installer? Any advice around this? Cheers!

Jeff

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Wed Aug 28, 2019 9:41 pm

Our package has been tested with the DLL versions that are shipped. I cannot tell you there will be no ill effects to Select or other 3rd party packages with a dependency on the prior version.

That being said, what was the change between the two packages that effects you?
Bob Richards, Software Developer, SoftPro

turp1twin
Posts: 13
Joined: Tue Aug 20, 2019 4:32 pm

Re: Shell package configuration best practices

Post by turp1twin » Thu Aug 29, 2019 11:02 am

So I am running SPS Client 4.3.15.1 and it appears to ship with version 10.0.2 of the Newtonsoft.Json library. The third-party Auth0 .Net library I am using relies on Newtonsoft.Json version 11.0.1 or greater... The only way I could get things to work was to use the following DependentAssembly block in the select.exe.config file:

<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="11.0.0.0-11.0.2.0" newVersion="11.0.0.0" />
<codeBase version="11.0.0.0" href="Newtonsoft.Json-11.0.2.dll"/>
</dependentAssembly>

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Thu Aug 29, 2019 11:52 am

Thanks.
Bob Richards, Software Developer, SoftPro

turp1twin
Posts: 13
Joined: Tue Aug 20, 2019 4:32 pm

Re: Shell package configuration best practices

Post by turp1twin » Thu Aug 29, 2019 12:10 pm

So based on that, would you say it would be ok to update the select.exe.config file in my shell package installer? Or is there a "best practices" way of getting this config into that file. On a side note, the SDK help file references a sample "ZipCodePackage.zip" which was not included in my SDK download. Is it possible to get that sample, and any other samples that are not included in the SDK? Again, I am using Sdk 4.3.60210.48 (4.3.15.1). Cheers!

Jeff

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Thu Aug 29, 2019 1:54 pm

Our response regarding making changes to the installed SoftPro software:

If you modify the select.exe.config file, you assume all risk associated with it. We cannot assure you that the application will behave in a predictable manner since we did not test with that particular configuration. As such, there is no established best practice for this.
Bob Richards, Software Developer, SoftPro

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Thu Aug 29, 2019 1:56 pm

Also, any software examples that are not with the SDK have been removed due to the fact they are out of date. We do not have updated versions. Sorry.
Bob Richards, Software Developer, SoftPro

BobRichards
Posts: 1007
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Shell package configuration best practices

Post by BobRichards » Fri Aug 30, 2019 10:35 am

I spoke to one of the developers and he handles the the problem this way. This technique does not require any modification to Select.
  • Add the target DLL to your project and change the Build Action so the file is loaded into your assembly.
  • Subscribe to the AppDomain.AssemblyResolve event. Here, you examine the fully qualified name .NET is looking for and If it matches your target DLL, get the DLL from the application resources as a Stream and pass it to AssemblyLoadContext.LoadFromStream() to load the DLL.
Helpful web links: At this point, you're on your own. This is an advanced technique and I am unable to provide more information.
Bob Richards, Software Developer, SoftPro

Post Reply