I have built an ArcGIS pro sdk configuration in order to slim down our application. Everything has been working great. We created an install script that alters a users registry to always look to our network drive for the latest .proConfiX file. So all users now have this in their registry with the path being our deploy location
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\ESRI\ArcGISPro\Settings" /v "ConfigurationFolder" /t REG_SZ /d "X:\PathTo\Configuration\Network\Location" /f
This has worked so that a user seamlessly and without any effort gets the latest configuration that we release. They have a shortcut on their Desktop that references which configuration we want them to load. This /config uses our network location from above
ArcGISPro.exe" /config:OURCONFIGURATION.proConfigX
When a new configX file is discovered (We did a new release), I am guessing that the process is to copy that configX file down to the local users computer and unpack it to %LOCALAPPDATA%\ESRI\ArcGISPro\AssemblyCache\{XXXXX}.
All of this seems to work great. Except lately some of our users are getting random startup crashes when they first try and open our application for the first time after the .proConfiX file has been updated. It seems the only way that I can get the application to open is to manually delete the unpacked file %LOCALAPPDATA%\ESRI\ArcGISPro\AssemblyCache\{XXXXX}
I think somehow when it looks to the configuration directory it is not clearing it out correctly or somehow it is becoming corrupt?
Has anyone seen any issues with this, and am I missing something in my configuration to ensure it clears out the assembly cache on the discovery of a new .proConfigX.
This seems to have something to do with the Executing Assembly and using Assembly.GetExecutingAssembly(). Is there a way around this? It seems like maybe the new version is unpacking to the assembly and the reference to GetExecutingAssembly is returning null somehow?
Still stuck on why this happens sometime and not others. So it appears that when a NEW/UPDATED version of the .proConfigX becomes available in the ConfigurationFolder, it unpacks that folder to the assembly cache. But it appears that sometimes it either doesn't unpack it fully or ontime or maybe it is locked out from making the update? The only way to then rectifiy the situation is to blow away the assembly cache item and restart the configuration. Not a big deal to do, but when dealing with many users it is a problem.
What I mean by this (fully or ontime or maybe it is locked), is that when I have seen this on a users machine, the only thing in their assembly cache are the .dlls associated with the configuration; the .config file, the .xml files, and the Content Folders are not present. They have not been unpacked. My application has 2 Content folders, and when these are missing, the program will crash as it cannot locate some of the settings located in the content folders or the .config file.
This only happens when a new version of the .proConfigX is available. It doesn't happen all the time, but it does happen. All of my users are working on computers well within the specs set forth by the ArcGIS Pro Minimum Requirements.
Any ideas?
IDEAL Assembly Cache
Crashing Assembly Cache after Config Update (Missing Everything)
Hi,
We found an issue with Configurations at 2.2 - In this scenario, while a Configuration is running if a 2nd instance of Pro is launched, the AssemblyCache gets deleted. This includes the files that the configuration requires.. After closing all the instances of Pro and the Configuration, if the same Configuration is relaunched, an Application crash was encountered (Assembly Cache does not get repopulated with the files the Configuration requires). We have now fixed this issue in 2.3, which is to be released soon.
This sounds very similar to the issue you are experiencing.
Thanks
Uma
Will I need to do something different in 2.3 on how the Registry ConfigurationFolder works? Will everything be same with that or do I need to set something else on a users machine on initial install so that it always points to the latest well know network folder everytime the config is launched from the shortcut.
Hi
Your workflow will not change. There are no additional keys required to get this fix. Please continue to use the keys you are using to designate well known network folders.
Thanks
Uma
Can we confirm that nothing change in the loading of a config path from the registry