插件自動更新選項在 addin.def 中定義。是什麼促使我提出這個願望清單請求呢？ JMP19 發布後，我注意到它新增了一個插件自動更新功能，JMP 會檢查「安裝資料夾」中的檔案更新。但這個功能的實現方式有點“笨拙”，最終導致我們之前建造的一些基礎架構出現問題。
您希望看到哪些改進？這些選項不應分散在「檢視」>「外掛程式」設定中，而應直接寫入所有外掛程式都需要的 addin.def 檔案中。這將使現有基礎架構的管理更加便捷，也便於逐步實現 JMP 的部分強大功能。
為什麼這個想法很重要？我想把這個功能提升到一個新的水平。這的確是個很棒的想法，但目前的實現方式很容易為其他人帶來問題。在我現有的架構中，我們會對照一個主列表來檢查更新，以便了解何時發布了新版本。 JMP 的這個功能或許可以減少一些這方面的工作，但它的佈局還需要更精細的設計。例如：
1. 插件已從正確位置安裝，一切正常…但之後使用者無法存取該位置，需要更新。我將 jmpaddin 檔案提供給他們，以便他們繼續使用。他們將該檔案拖入 JMP……現在，安裝來源可能變成了下載資料夾，導致他們無法收到更新通知……如果將正確的安裝來源硬編碼到 def 檔案中，則可以避免這種情況。
2. 測試插件。與第 1 點類似，如果您有一個專門存放測試文件的資料夾，安裝測試文件會將安裝位置更改為測試位置，這樣一來，當正式版發布新版本時，測試外掛程式就不會收到通知。此外，根據檔案名稱的命名方式，測試外掛程式是否收到新版本通知也未必會收到…因為測試版本通常會“移交”，檔案名稱中包含版本號…所以更新檢查無法實現完全匹配的檔案名稱。
在這兩個例子中，JMP 的一些做法確實有其價值，但部署團隊需要對插件的更新標記方式有更大的控制權。可能還有其他例子，但我認為這些足以推動將更新相關的「機制」納入 addin.def 文件，並在其中添加一個或多個變數。
謝謝！
自動化和腳本編寫回覆：Addin.def 中已編碼的 Addin 自動更新選項感謝@nathan-clark強調這些問題。
與“根據主列表檢查更新”相比，新方法的速度如何？ [例如@Justin_Chilton 的 Add-In Manager 中的]
回覆：Addin.def 中已編碼的 Addin 自動更新選項@hogi ，我還沒有做過任何速度測試。主要是因為它給我的其他部署帶來了問題，我感到很惱火。我懷疑整體速度應該會更快，因為 JMP 似乎只檢查檔案名稱的新修改，而不是我與實際版本發布日期的比較。速度也將根據 JMP 引用的「來源」資料夾來決定。
回覆：addin.def 中已編碼外掛程式自動更新選項 - 狀態已變更為：已確認感謝您抽出時間提出這個請求！這是非常寶貴的回饋。
回覆：addin.def 中定義的插件自動更新選項@nathan-clark你能提供這個功能及其目前實現方式的文件嗎？我不明白這個實現方式具體包含哪些內容，也找不到任何相關資訊。你是說 JMP 會在使用者最初打開 .jmpaddin 檔案的資料夾裡找嗎？那它具體會找什麼呢？是尋找檔案名稱不同但 addindef 中插件 ID 相同的 .jmpaddin 檔案嗎？還是找 addindef 中插件版本號相關的內容？還是尋找檔案名稱相同但內容不同的檔案？
回覆：addin.def 中定義的插件自動更新選項@hardner我不確定是否有相關文件。我掌握的資訊來自我自己的測試/觀察，以及我與 JMP 技術支援的交流。當時我注意到 JMP 19 會詢問我一些插件的更新檢查問題。
是的，如果您轉到“查看”>“加載項”，您應該能夠看到我描述的一些項目……您應該會看到一個“安裝來源”部分以及一個“更新”下拉列表……如果下拉列表設置為“檢查更新……”，JMP 將監視列出的安裝資料夾，而且目前還不容易或不可能更改。
我不確定 JMP 是如何監控的。我猜想可能是同一個文件名為 .jmpaddin 的文件，只是修改日期更新？但我可能猜錯了……我的主要問題是控制其中的一些組件。
我已經有了自動更新的基礎架構，所以我不希望 JMP 監控任何內容，我希望這個設定由插件本身完成，而不是由使用者手動選擇。
2. 如果我確實希望 JMP 進行監控，我希望能夠控制 JMP 如何監控更新——例如強制監控 PROD 文件夾，這樣用戶就可以上傳測試用的 .jmpaddin 文件，而不會影響對 PROD 的監控。
對我來說，透過 addin.def 檔案來定義這些設定是最合理的…而且如果使用者確實想要覆蓋預設設置，仍然可以使用「視圖」>「插件」選項。但是，無論其底層規則是什麼，目前的實作方式都會破壞我已經建置並用於部署外掛程式套件的基礎架構的某些方面。
這樣有幫助嗎？
回覆：addin.def 中定義的插件自動更新選項預設自動啟用公司 AddIn 的更新功能（透過 AddIn 中的設定）將帶來翻天覆地的變更！
風險極大，用戶可能會忘記啟動更新功能，從而被迫使用舊版本。
在插件中進行設定比在本地首選項中進行設定要好得多。如何確保所有 100 位使用者都在本機首選項中啟用該功能？
回覆：addin.def 中定義的插件自動更新選項根據我們的經驗：
監控同名文件
- 當文件為新文件時（即使版本號未更改），也會觸發更新。
更改資料夾中的其他檔案不會影響該機制。
與UpdateCheck@AddInManager 相比的優點：
-多個外掛程式可以同步更新
- 靜默模式（雖然我不敢這麼做——但我知道哪個插件更新了還是挺好的）
回覆：addin.def 中定義的插件自動更新選項相反，我希望沒有人使用自動更新功能…直到我對自動更新的其他方面擁有100%的控制權為止 
回覆：addin.def 中定義的插件自動更新選項感謝@nathan-clark和@hogi 。我已經提交了支援請求，詢問有關此問題的詳細資訊。我完全同意應該能夠控制與此行為相關的選項。
回覆：addin.def 中定義的插件自動更新選項所以，如果@nathan-clark想要重新獲得控制權——不允許手動選擇該選項，那麼「強制設定」功能將會很有幫助。
對我來說，對預設設定進行一些選擇就足夠了。
當從 SharePoint 安裝加載項並同步到本機 OneDrive 時，每個使用者都會有自己的安裝路徑。
從網路磁碟機安裝時，強制「自動更新」使用預設路徑可能會很有幫助。
回覆：addin.def 中定義的插件自動更新選項同意！這也是我希望它可以透過 addin.def 檔案進行編碼的原因之一。
我最不喜歡的一點是安裝來源會改變…例如你的 SharePoint @hogi ，如果他們安裝的是測試版，那麼安裝來源可能會被更改為測試版的位置…這樣，如果創建了新的生產環境，他們就不會收到通知。
諸如此類的小事可能會破壞現有的基礎設施/路徑 好在，我認為要支撐多條道路的「升降機」並不難。
回覆：addin.def 中定義的插件自動更新選項如果您從 SharePoint 下載文件，然後從「下載」資料夾中開啟它，自動更新將不會執行任何操作，因為它假定該文件已安裝到本機。我當時合作的客戶希望此功能允許指定一個遠端位置來檢查更新（例如他們的公司伺服器、SharePoint 或其他位置）。無論使用者如何開啟文件，都會指定一個官方位置，例如在 addin.def 文件中指定為查找更新的位置。如果該位置無法訪問，也不會出現錯誤。
回覆：addin.def 中定義的插件自動更新選項@hardner你可以同步你的 SharePoint 資料夾，這樣它就會像本機資料夾一樣顯示在你的檔案總管中。在 SharePoint 位置中通常會有一個「同步」按鈕，點擊後它會變成一個本機同步資料夾，可以像存取你硬碟上的任何其他資料夾一樣存取。
如果他們直接下載文件，你說的沒錯，這也會「破壞」預期的路徑。
我不能百分之百確定所有公司都是這樣，但至少我們公司是這樣的…可能還有一個「建立 OneDrive 捷徑」的按鈕。功能類似，但我盡量不用這個按鈕（以後有機會再細說）。
回覆：addin.def 中定義的插件自動更新選項明白了。我使用同步功能，但我也加入了一些不允許我同步的 SharePoint 群組。我首先想到的是下載類似這樣的文件，這樣我就「擁有」這個文件了。不過，我主要是想指出，這種邏輯只有在用戶直接從官方更新位置打開 .jmpaddin 文件時才有效，而且我不確定如何強制他們這樣做，而不是下載、通過電子郵件發送文件或其他方式。
回覆：addin.def 中定義的插件自動更新選項沒錯，這很有道理。我覺得 JMP 的想法很有意義，可以簡化很多麻煩事……我最想做出改變的原因是他們的實現方式破壞了我的系統 但有了合適的控制措施，我或許可以棄用一些基礎設施，轉而依賴 JMP 的實現方式！
回覆：addin.def 中定義的插件自動更新選項AddinLoad.jsl怎麼樣？
- 將安裝檔案覆蓋為公司標準
- 如果 Test-Dir 為真：顯示警告，提示已安裝測試版本 - 建議使用者從官方來源安裝正式版
- 如果 InstallationDir=Download -> 停用更新
我們只需要找到資訊保存的位置，然後讀取、存取和更改它。
回覆：addin.def 中定義的插件自動更新選項addinload 檔案可能會比較挑剔，這取決於你如何使用它們以及 JMP 安裝檔案的順序。我的程式是基於按需加載的庫構建的……但我以前也用過 addinload。我的系統其他方面都非常穩定——直到 JMP 把選項還給用戶為止 
對我來說，最重要的是，如果 JMP 的東西比我的好，我會使用，但我不想被迫使用 JMP 的東西。
回覆：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.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>
回覆：addin.def 中定義的插件自動更新選項啊，太好了！
最好設定一個批次腳本來更新：
運行所有插件安裝程式並調整設定。
