アドインの自動更新の選択肢は addin.def にコード化されていますこのウィッシュリストへのリクエストのきっかけは何だったのでしょうか？ JMP19のリリース時に、JMPが「インストールフォルダ」からファイルの更新を探すアドインの自動更新機能があることに気付きました。しかし、実装が少々「不格好」で、既に構築していたインフラの多くを壊してしまうことになりました。
どのような改善を期待しますか？これらの設定は、「ビュー」>「アドイン」設定ではなく、すべてのアドインに必要なaddin.defファイルにコード化されるべきです。これにより、既存のインフラストラクチャを管理しやすくなり、JMPの優れた機能の一部を段階的に実装しやすくなります。
なぜこのアイデアが重要なのでしょうか？この機能を次のレベルに引き上げたいと考えています。非常に素晴らしいアイデアですが、現在の実装では他のユーザーに問題を引き起こす可能性があります。現在のインフラストラクチャでは、新しいバージョンがリリースされたかどうかを確認するために、マスターリストと照合しています。JMPの機能によってこうした作業の一部が軽減される可能性はありますが、その実装方法にはさらなる工夫が必要です。例えば、以下のような点が挙げられます。
1. アドインは正しい場所からインストールされ、すべて正常に動作します…しかし、後になってユーザーがその場所にアクセスできなくなり、アップデートが必要になりました。jmpaddinファイルをユーザーに渡して、作業を続行できるようにします。ユーザーはそれをJMPにドラッグします…インストール元がダウンロードフォルダに変更され、その変更によってアップデートの通知が届かなくなる可能性があります…正しいソースをdefファイルにハードコーディングすれば、この問題は回避できます。
2. アドインのテスト。1.と同様に、テスト用のフォルダがある場合、テストファイルをインストールするとインストール場所がテスト用の場所に変更され、新しい製品版リリースが行われても通知が届きません。また、ファイル名によっては、新しいテストバージョンが通知されるかどうかも異なります。テストバージョンは多くの場合「引き継がれる」ため、ファイル名にバージョン番号が含まれているため、更新チェックでファイル名の正確な一致が確認できないためです。
どちらの例も、JMP の実装には役立つ側面がありますが、導入チームはアドインの更新対象としてマークする方法をより細かく制御する必要があります。他にも例はあるかもしれませんが、更新関連の「要素」を addin.def ファイルに追加し、そこに 1 つ以上の変数を含めるという流れをスムーズにするには、これで十分だと思います。
ありがとう！
自動化とスクリプトRe: アドイン自動更新の選択肢がaddin.defにコード化されました問題を指摘してくれた@nathan-clarkに感謝します。
「更新はマスター リストに対してチェックされる」 [ ジャスティン・チルトンによるアドイン マネージャーのように ]と比べて、新しいアプローチの速度はどのくらいですか?
Re: アドイン自動更新の選択肢がaddin.defにコード化されました@hogi さん、まだ速度テストはしていません。他の環境で問題が発生しているので、ちょっとイライラしているだけです。JMPはファイル名の新たな変更をチェックするだけなので、実際のビルドリリース日と比較すると、全体的に速度は速くなるのではないかと思います。また、速度はJMPが参照する「ソース」フォルダによっても決まります。
Re: Addin の自動更新の選択肢が addin.def にコード化されました - ステータスが「確認済み」に変更されましたこのリクエストを共有していただきありがとうございます。素晴らしいフィードバックです。
Re: アドイン自動更新の選択肢がaddin.defにコード化されました@nathan-clarkこの機能と現在の実装に関するドキュメントを教えていただけますか？その実装が何を意味するのか理解できず、検索しても何も見つかりません。JMPはユーザーが.jmpaddinファイルを開いた元のフォルダを参照しているということですか？では、そこで何を検索するのでしょうか？ファイル名は異なるものの、アドイン定義のアドインIDが同じ.jmpaddinファイルを検索するのでしょうか？それとも、アドイン定義のアドインバージョンに関する何かでしょうか？それとも、ファイル名は同じだが内容が一部変更されているのでしょうか？
Re: アドイン自動更新の選択肢がaddin.defにコード化されました@ハードナードキュメントがあるかどうかは分かりません。私が持っている情報は、私自身のテストと観察、そしてJMPサポートのサポートスレッドでJMP 19でアドインの更新確認に関する質問があったことに気づいたときに得たものです。
はい、「表示」>「アドイン」に移動すると、私が説明した項目のいくつかが表示されます...「インストール ソース」セクションと「更新」ドロップダウン リストが表示されます...ドロップダウンが「更新を確認...」に設定されている場合、JMP はリストされているインストール フォルダーを監視しますが、まだ簡単に変更することはできません。
JMPがどのように監視しているのか、よく分かりません。同じ名前の.jmpaddinで更新日が新しいファイルでしょうか？でも、もしかしたら間違っているかもしれません… 主に知りたいのは、いくつかの部分を制御することです。
1. すでに自動更新インフラストラクチャを導入しているので、JMPに監視させたくありません。監視はアドイン自体で設定し、ユーザーが選択できないようにしたいです。
2. JMPで監視したい場合は、JMPが更新を監視する方法を制御したい。たとえば、PRODフォルダを強制的に監視し、ユーザーがPRODの監視に影響を与えずにテスト用の.jmpaddinファイルをアップロードできるようにする。
これを addin.def でコード化できるのが最も理にかなっていると思います…ユーザーが本当にオーバーライドしたい場合は、View>Addins も引き続き利用可能です。しかし、現在の実装では、背景ルールが何であれ、私が既に構築し、アドインスイートの展開に使用しているインフラストラクチャの一部が損なわれています。
それは役に立ちますか?
Re: アドイン自動更新の選択肢がaddin.defにコード化されました会社のアドインに対して、デフォルトで更新を自動有効化する (アドインの設定を使用) と、状況が大きく変わります。
非常に危険なため、ユーザーが更新機能を有効にすることを忘れ、古いバージョンのままになってしまう可能性があります。
アドインでの設定は、ローカル環境設定での設定よりもはるかに優れています。ローカル環境設定で100人中100人のユーザーが機能を有効にすることを保証するにはどうすればよいでしょうか。
Re: アドイン自動更新の選択肢がaddin.defにコード化されました私たちの経験から：
- 同じ名前のファイルが監視されます
- ファイルが新しい場合（バージョンが変更されていない場合でも）更新がトリガーされます
- フォルダ内の他のファイルを変更してもメカニズムには影響しません
UpdateCheck@AddInManager と比較した利点:
-複数のアドインを同期的に更新できます
- サイレント モード (ただし、私は敢えてしません。どのアドインが更新されるかがわかるのは便利です)
Re: アドイン自動更新の選択肢がaddin.defにコード化されました逆に言えば、自動更新の他の側面を 100% 制御できるようになるまでは、自動更新機能を使用する人を 0 人にしたいと思っています 
Re: アドイン自動更新の選択肢がaddin.defにコード化されました@nathan-clark さんと@hogi さん、ありがとうございます。この件について詳細を知りたいというサポートリクエストを自分で作成しました。この動作に関するオプションを制御できるようにしたいという点には完全に同意します。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたしたがって、 @nathan-clark が制御を取り戻したい場合、つまりオプションを手動で選択できないようにしたい場合は、「強制設定」が役立ちます。
私の場合は、デフォルト設定でいくつか選択するだけで十分です。
アドインが Sharepoint からインストールされ、ローカルの OneDrive に同期されると、すべてのユーザーに独自のインストール パスが与えられます。
ネットワーク ドライブからインストールする場合は、「自動更新」を強制的にデフォルト パスに固定すると便利な場合があります。
Re: アドイン自動更新の選択肢がaddin.defにコード化されました同意です！これが、addin.def でコード化できるようにしたい理由の一部です。
私が気に入らない最大のことは、インストール ソースが変更されることです... Sharepoint @hogiのように、ベータ バージョンをインストールすると、そのソースがベータの場所に変更される可能性があります... そのため、新しい PROD が作成されても通知されません。
そういった小さなことでも、既存のインフラや通路を壊してしまう可能性があります ありがたいことに、複数の道をサポートする「リフト」はそれほど難しいとは思いません。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたSharepointからファイルをダウンロードし、「ダウンロード」から開いた場合、自動更新はインストール場所を指定しているという前提で何もしないのでしょうか？私が担当していた顧客は、この機能によってリモートの場所（社内サーバー、Sharepointなど）を指定して更新を確認できるようになることを期待していたと思います。ユーザーがファイルをどのように開いたかに関係なく、この公式の場所は、例えばaddin.defなどで更新場所として指定されているはずです。そして、その場所にアクセスできない場合でもエラーは発生しません。
Re: アドイン自動更新の選択肢がaddin.defにコード化されました@hardner さん、SharePoint を同期すれば、ファイルエクスプローラーでフォルダがローカルにあるかのように表示されます。SharePoint の場所には通常「同期」ボタンがあり、これをクリックするとローカルの同期フォルダとして表示され、ドライブ上の他のフォルダと同じようにアクセスできます。
確かに、ファイルを直接ダウンロードすると、意図した経路が「壊れる」可能性もあります。
どの会社でも100%共通だとは言い切れませんが、少なくともうちの会社ではそうなっています…「OneDriveのショートカットを作成」ボタンもあるかもしれません。似たような機能がありますが、私はこのボタンは使わないようにしています（別の機会に詳しく話します）。
Re: アドイン自動更新の選択肢がaddin.defにコード化されました了解しました。Syncは使っていますが、同期できないSharePointも利用しています。まず考えたのは、ファイルを「入手」するために、このようなものをダウンロードすることです。とはいえ、このロジックは、ユーザーが更新が表示される公式の場所から直接.jmpaddinを開く場合にのみ有効に機能する点です。ダウンロードやメール送信などではなく、公式の場所から直接開くように強制できるかどうかは私にはよく分かりません。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたええ、確かにそうですね。JMPの目指すところは理にかなっていて、多くの悩みを解消できると思います。私が変更を決めた最大の理由は、JMPの実装が私の環境を壊してしまうからです でも、適切な管理があれば、インフラの一部を廃止してJMPの実装に頼れるようになるかもしれませんね！
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたAddinLoad.jsl はどうでしょうか?
- インストールファイルを会社標準に上書きする
- Test-Dirの場合: テストバージョンがインストールされているという警告を表示 - ユーザーに公式ソースから公式リリースをインストールするよう提案する
- InstallationDir=Download の場合 -> 更新を無効にする
情報がどこに保存されているかを見つけて、それを読み、アクセスし、変更するだけです。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたaddinloadファイルは、使い方やJMPのインストール順序によっては扱いにくいことがあります。私は必要な時にインクルードされるライブラリをベースにシステムを構築していますが…以前addinloadを使ったことがあります。それ以外は私のシステムは安定していましたが、JMPがユーザーにオプションを返した時はそうでした。
結局のところ、私の場合、JMP の製品が自分の製品よりも優れている場合はそれを使いますが、JMP の製品を強制的に使用させたくはありません。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたああ、ここにあります:
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 )
);
autoUpdate タグを削除するだけで、同僚は堅牢な実装に頼ることになります。
設定をチェックし、調整し、設定が間違っている場合に警告する UpdateCheck AddIn をインストールしてください。
Re: アドイン自動更新の選択肢がaddin.defにコード化されましたああ、 @hogiさん、興味深いですね！確かに、試してみる価値のある回避策ですね JMPサポートから、アップデート時に設定をオフにできるJSLも提供してもらったので、これも試してみる必要があります。
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.defにコード化されましたああ、素晴らしい！
アップデートを更新するためのバッチ スクリプトを設定するのが理想的です。
すべてのアドインインストーラーを実行し、設定を調整します。
