905774_en-US

liliconcom

Addin Auto Update choices codified in addin.def

What inspired this wish list request? With JMP19 on the scene, I noticed an auto update feature for addins where JMP will look for udpates to files from an 'install folder'. The implementation was a bit "clunky" and ends up breaking a bunch of infrastructure we already had built.

 

 

What is the improvement you would like to see? Rather than living in the Views > Addins settings, these choices should be codified in the addin.def file all addins need. It will make it easier for those with existing infrastructures to manage as well as easier to implement part of JMPs cool features iteratively.

 

 

Why is this idea important? I want to take this feature to the next level. It's a super great idea, but its current implementation can easily cause issues for others. In my current infrastructure, updates are checked for against a master list to know when new versions are released. JMP's feature could deprecate the need for some of this, but it needs more finesse in how it's laid out. Some examples:

1. Addin installed from correct location, all is well... later on user can't access location and needs the update. I pass along the jmpaddin file to them so they can keep on going. They drag it into JMP ... now it's possible the install source is now the downloads folder and they wouldn't get notified of updates because of that change ... hard coding the correct source into the def file would allow this to work regardless.

2. Testing addins. Similar to #1 if you have a folder where your tests are located, installing a test file would change your install location to the test location and they wouldnt get notified when a new prod release happens. And depending on how files are named they may or may not be notified of new test versions ... because test versions are often 'handed' off, they include teh version in the filename... so an exact filename match isn't possible for the update checks.

In both of these examples, there are aspects of what JMP has done that could be useful, but the deployment team needs more control in how their addins shall be marked for update. There are probably more example, but I think this is enough to get the ball rolling for the update 'stuff' to be part of the addin.def file with one or more variables there.

 

Thanks!

 

 

Automation and ScriptingRe: Addin Auto Update choices codified in addin.def

Thanks @nathan-clark for highlighting the issues.

How is the speed of the new approach compared to "updates are checked for against a master list " [like in  Add-In Manager by @Justin_Chilton ] ?

Re: Addin Auto Update choices codified in addin.def

I haven't done any speed tests yet, @hogi. Mostly I've just been annoyed because it's been creating issues with my other deployments. I suspect speed would be faster overall since it appears JMP just checks for a new modification of a filename vs my comparison against actual build release dates. Speed will also be determined based on the 'source' folder being referenced by JMP.

Re: Addin Auto Update choices codified in addin.def - Status changed to: Acknowledged

Thank you for taking the time to share this request! This is great feedback. 

Re: Addin Auto Update choices codified in addin.def

@nathan-clark Can you point to documentation of this feature and the current implementation?  I don't understand what that implementation entails and I'm failing to search out anything about it. Are you saying that JMP is looking in the folder the user originally opened the .jmpaddin file from? And then what is it that it looks for there? any .jmpaddin files with different filenames but the same addin id in addin def?  or something about the addin version in addindef? or same filename but some change to the content?

Re: Addin Auto Update choices codified in addin.def

@hardner I am not sure there is any documentation. The information I have has come from my own testing/observation and a support thread with JMP support when I noticed JMP 19 asking me questions about checking for updates with some of my addins.

And yes, if you go to View > Addins you should be able to see some of the items i've described ... you should see an "Install Source" section as well asn an "Update" drop down list ... if the dropdown is set to "check for updates..." JMP will monitor the install folder listed, and it's not easy to or possible to change - yet.

How JMP monitors, I am not sure of. I am guessing either a same name .jmpaddin with a newer modified date? But I could be wrong ... My main ask is around controlling some of the pieces.

1. I aldready have auto update infrastructure so I don't want JMP to monitor anything and I want that set by the addin itself, no user choice
2. If I do want JMP to monitor, I want to control how JMP monitors for updates -- like force monitor a PROD folder which would allow the user to upload test .jmpaddin files w/o affecting monitoring PROD

Being able to codify this through the addin.def makes the most sense to me... and if a user truly wants to override the View>Addins is still available. But the current implementation, whatever the background rules are, breaks aspects of the infrastructure I aldready built and use for deployment of my addn suite.

Does that help?

Re: Addin Auto Update choices codified in addin.def

Auto-enabling the Update by default (via a setting in the AddIn) for company AdDIns will be a GameChanger !

So risky that A user forgets to activate Update function - and thereby suffers from being stuck with an old version.

A setting in the AddIn is much better than a setting in the local preferences. How to guarantee that 100 out of 100 users activate the feature in the local preferences.

 

Re: Addin Auto Update choices codified in addin.def

From our experience:
- a file with the same name is monitored
- update is triggered when the file is new (even if the version is not changed)
- changing other files in the folder doesn't affect the mechanism

benefit comapred to UpdateCheck@AddInManager: 

-multiple AddIns can be updated synchronously
- silent mode (although I don't dare - nice to know which AddIn gets updated)

Re: Addin Auto Update choices codified in addin.def

Conversely, I want 0 people to use the autoupdate feature ... until I have 100% control on the other aspects of autoupdating  

Re: Addin Auto Update choices codified in addin.def

Thanks @nathan-clark and @hogi.  I did make my own support request for details about this.  I'm in complete agreement in wanting control over options around this behavior.

Re: Addin Auto Update choices codified in addin.def

so, if @nathan-clark wants control back - disallowing to manually select the option, then a "force settings" will be helpful.

For my case, some selection for the default setting will be sufficient.

When AddIns are installed from Sharepoint, synchronized to local OneDrive,  every user will have their own Install path.
When installed from a network drive, it might be beneficial to force the "auto-update" to stick to a default path.

Re: Addin Auto Update choices codified in addin.def

Agreed! This is part of why I want it codifiable via the addin.def.

The biggest thing I am not a fan of is the install source changing... likee your sharepoint @hogi , if the install a beta version that source may be altered to the beta location... so they woudnl't be notified if a new PROD was created.

Little things like that potentially break existing infrastructure/pathways Thankfully I don't htink the 'lift' is super hard to support muptiple avenues.

Re: Addin Auto Update choices codified in addin.def

If you downloaded the file from the Sharepoint and then opened it from your "Downloads" the auto-update will do nothing on the assumption it's making that the install location? The customer I was working with was, I believe, hoping this would allow specifying a remote location to check for an update (their corporate server or sharepoint or whatever) - regardless of how the user had opened the file, this official location would have been specified, such as in addin.def as the place to seek updates.  And there would not be errors if that location was inaccessible.

Re: Addin Auto Update choices codified in addin.def

@hardner you can sync your Sharpoint so the folder can show up in your file explorer as though it's local. Within a sharepoint location there is often a "Sync" button which brings it down as a local synced folder accessible as any otehr folder on yoru drive.

If they do download the file directly, you are correct that can also 'break' the intended pathway.

I can't say 100% this is common company to company, but at least that's how ours works ... there may also be a 'create onedrive shortcut' button also. Does someething similar, but I try not to use this button (soap box for a different day).

Re: Addin Auto Update choices codified in addin.def

Understood.  I use Sync but also belong to sharepoints that don't allow me to Sync.  My first thought would be to download something like this just so that I "have" the file.  Regardless, mainly was noting this logic only works usefully if users open the .jmpaddin directly from the official location where updates will appear and it's not clear to me you can enforce that they do that as vs. download, email the file around, or whatever.  

Re: Addin Auto Update choices codified in addin.def

Yup, that makes sense. I think what JMP is trying for makes a lot of sense and can streamline lots of headaches ... My biggest drive for change was their implementation breaks mine But with the right controls I may be able to deprecate some of my infrastructure to rely on JMPs implementation!

Re: Addin Auto Update choices codified in addin.def

how about: AddinLoad.jsl?

- overwrite Installation fie to Company Standard
- if Test-Dir: show a warning that a test version is installed - suggest the user to install the official release from the official source
- if InstallationDir=Download -> disable update

We just have to find out where the information is saved  - and then read, reacht and change it.

Re: Addin Auto Update choices codified in addin.def

addinload files can be finicky depending on how you utilize them and the order JMP installs things. i built my stuff based on libraries that are included when I need them ... but i've used addinload in the past. My system is rock solid otherwise - until JMP gave options back to the user  

Bottom line for me, I'll use JMPs stuff if it's better than mine, but I odn't want to be forced into JMPs stuff.

Re: Addin Auto Update choices codified in addin.def

ah, here it is:

Open(
	"$USER_APPDATA_ALL/addinRegistryV2.xml",
	XML Settings(
		Stack( 0 ),
		Row( "/AddinReg/Addins/Addin/@id" ),
		Col(
			"/AddinReg/Addins/Addin/@id",
			Column Name( "Addin.id" ),
			Fill( "Use Once" ),
			Type( "Character" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@timeStamp",
			Column Name( "Addin.timeStamp" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@installSource",
			Column Name( "Addin.installSource" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@installSourceTimeStamp",
			Column Name( "Addin.installSourceTimeStamp" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@autoUpdate",
			Column Name( "Addin.autoUpdate" ),
			Fill( "Use Once" ),
			Type( "Numeric" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		),
		Col(
			"/AddinReg/Addins/Addin/@updatePrompt",
			Column Name( "Addin.updatePrompt" ),
			Fill( "Use Once" ),
			Type( "Character" ),
			Format( {"Best", Use thousands separator( 0 ), 15} ),
			Modeling Type( "Continuous" )
		)
	),
	XML Wizard( 0 )
);

Just remove the autoUpdate tag and your colleagues have to rely on your rock solid implementation.

Maybe install an UpdateCheck AddIn which checks the settings, adjusts them and complains if the settings are wrong.

Re: Addin Auto Update choices codified in addin.def

Oh, interesting @hogi! That definitely seems like a workaround i should play with JMP support also gave me some JSL thatt I could use to turn off the setting when updates happen, that I need to play with also.

Names Default To Here( 1 );
/* Installing Add-In:
Open( Add-In to open,
    <CHECK for="" updates="">, // "always" will check for updates at startup and while jmp is running
    <UPDATE prompt="">) // whether or not the add-in will silently update or prompt first */
Open(
    \\NetworkLocation\addins\test.jmpaddin,
    Check For Updates( "never" ),
    Update Prompt( 0 )
);
</UPDATE></CHECK>

Re: Addin Auto Update choices codified in addin.def

ah, wonderful!

Ideal to set up a batch-script to update the update:
run all the AddIn Installers and adjust the settings.