Beginning with 0.59w, SimPE will allow PLugins to hook into the update check. That means you can use the mechanisms provided by SimPE to notify users of new versions of you Plugins.

All you have to do, is to imnplement the SimPe.Updates.IUpdatablePlugin in your Plugin Factory. That is the class within your Plugin that inherits from AbstractWrapperFactory.



All Factories, that implement the Interface, will get hooked into the update check. SimPe will query an online file for the latest version available for the given plugins, and if a newer one was found, SimPE will show the Update Dialog.

This online file is manually written at the moment, which means, you have to send me your Plugin key, version and screenname each time you provide an updated version.

What's the "Plugin key"?

A unique string, that identifies your Plugin and never changes.

SimPe will use it to find the correct Plugin Version information in it's database.

Okay, so something like "http://simlogical.com/PJSE/" would do.  Next question: when is 0.59w ready to download ;) ?

Just a few minutes... ;)

No that wouldn't do.  It would be REALLY confusing if we ever had to change the location of the webpage we'd always be getting into arguments "but I assumed you were talkinh about the website" "no I was talking about the unique key".   Hmm maybe something more like "PJSEPluginsKey" would be more descriptive

Quaxi,

It seemed reasonable to me to implement this in PJSE as follows:

        public SimPe.Updates.UpdateInfo GetUpdateInformation()
        {
            System.Diagnostics.FileVersionInfo v = System.Diagnostics.FileVersionInfo.GetVersionInfo(this.GetType().Assembly.Location);
            long build = ((long)v.FilePrivatePart & 0xFFFF)
                + (((long)v.FileBuildPart & 0xFFFF) << 16)
                + (((long)v.FileMinorPart & 0xFFFF) << 32)
                + (((long)v.FileMajorPart & 0xFFFF) << 48);
            return new SimPe.Updates.UpdateInfo(build, v.ProductName, v.FileDescription);
        }

Given that everything is coming from the Assembly VersionInfo, couldn't SimPE do this internally for any  AbstractWrapperFactory that also implemented IUpdatablePlugin?  (i.e. you have an instance of the AbstractWrapperFactory, so GetType(), etc.)  Or am I missing some subtlety?

(I'm using ProductName as the unique ID for the plugin as should be fairly reliable.  So long as it's set sensibly in the AssemblyInfo.cs; same applies to the Private and Build version fields - I'm assuming they're * and *.)

SimPE could, but some developers may not want to use the .dll Version as the plugin Version. Like a recompile due to an interface change should not qualify as a new Version.
Plus you might want to use anotehr display name for the plugin than the one that was used to name the dll (because the .dll could simply be the PJSE Loader Library, while the real Plugins are stored in another .dll).

So this way gives you more flexibility. I could create a default Constuctor for the object, that sets the values from the assembly info if that would help.

(Oops, hit "close" when I was writing this the first time!!)

With the current proposal, I understood a new version would only be advised to users when a developer advised you of the update, so this isn't a problem.  Even if there was some automated scheme in place, it would still be up to the developer to "push" the new version out.

Or sneakily have another AbstractWrapper that only implements the hook! :)  The ProductName field looks like a good candidate for the key (ideally, I'd have used the unqualified assembly name but I couldn't find it).  The "File Description" from the AssemblyInfo is what Windows uses on the "Version" tab of properties, which is why I felt it should be something suitable as a display name.

Or have AbstractWrapperFactory implement IUpdatablePlugin and allow implementers of WrapperFactories to override GetUpdateInformation() if they don't want the defaults from AssemblyInfo?  Even though I have three WrapperFactories, one per plugin.dll, this isn't a problem for me as I'd only register pjse.coder.plugin as a key.  (Maybe AbstractWrapperFactory could provide the method but not declare itself as an implementer of the interface.  Then the developer picks which extension of AbstractWrapperFactory they want to use by declaring it to implement the interface and they get the method for free or override it if they like?)