home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Plugins
MPEM Development Info & Testversion
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="chefkoch" data-source="post: 1011872" data-attributes="member: 10438"><p>I did not wanted to stop any enthusiasm and also don't what is the right or the wrong way. I've also already raised the NuGet idea here once and did not wanted to nag.</p><p> </p><p>First Thanks for <a href="https://forum.team-mediaportal.com/members/offbyone.73415/" target="_blank">offbyone</a> many items of your list of limitiatons, I probably would have missed.</p><p> </p><p>Even if in general it might be possible, WiX seems to be a bit overload to to me. It's not the fastest way of installing files, because it tracks files very detailed.</p><p> </p><p>There will be references deep inside the system to every extension that you have ever installed once, even if these refs are not critical and don't actually matter. If Windows Installer removes exactly the files that are installed, every file needs to have it's own component, unique GUID and explicitly defined in the wix script, iirc. Doing this manually is a no go for skinners. Harvesting the source directories by Heat brings in another component, which the extension author has to know about.</p><p> </p><p>Because MP2 was mentioned and feedback requested: In MP2 most extensions will be installed by simple copy commands. There should not be an installation UI required for, I assume 80% of all plugins, otherwise the plugins are not following the MP2 Best Practices, to</p><ul> <li data-xf-list-type="ul">provide usable defaults and prevent the requirement of any configuration before using a feature / plugin</li> <li data-xf-list-type="ul">if some setup is required ask on first usage</li> <li data-xf-list-type="ul">plugin files have to in <strong>one</strong> plugin folder, including default skin files and all external binaries and references</li> <li data-xf-list-type="ul">Skins are "plugins", so all files for this skin are within this plugin folder not</li> </ul><p>These and other things bring it down to simple copy commands for MP2 extensions.</p><p>I have no idea anymore what additional tasks are required for MP1 Addons these days. Some of them might be even required for MP2 i.e. installing a service like MPExtended, but such "extensions" are so complex that these should not be deployed by "MP extension packages" only and instead kept in their MSI installer, which then maybe wrapped by a "MP extension package".</p><p> </p><p> </p><p>Maybe the wix-approach can work, but it's worth imo also to take a look at the NuGet approach, especially because there are so much components already build, which fit exactly or basically our needs:</p><ul> <li data-xf-list-type="ul">NuSpec > defining package structure</li> <li data-xf-list-type="ul">NuGet.Core > versioning algorithm, dependency management, package metadata, ...</li> <li data-xf-list-type="ul">NuGet.exe > commandline tool for installing, uninstalling, updating, reinstalling, ....</li> <li data-xf-list-type="ul">NuGet.Server > WebComponent for hosting packages and providing a feed that can be reused by "clients" (external installer, GUI plugin, Gallery, ....)</li> <li data-xf-list-type="ul">NuGetGallery (OrchardGallery) > (ASP.net based?) WebSite component presenting available packages nicely in your browser</li> <li data-xf-list-type="ul">NuGetPackageExplorer > Utility for building and uploading packages</li> </ul><p>A few of these things might not fit our needs perfectly i.e. the NuGetGallery which package pages "do not look good" (<a href="https://forum.team-mediaportal.com/members/dadeo.27204/" target="_blank">Dadeo</a>) <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p>I also explained some of these things and provided links in the conversation I started with you and Dadeo within <u>May</u> (got no reply) and a few days ago within the MP2 forums. See the link that has been posted by <a href="https://forum.team-mediaportal.com/members/tourettes.10858/" target="_blank">tourettes</a>.</p><p> </p><p>Maybe ti's worth to create some proof of concepts. take 2 or 3 plugin/skin examples from MP1 and MP2 and create these via WiX. Same could be done for the NuGet thing.</p><p>I seriously believe at this point it is not worth asking plugin devs and skinners what is the <u>definite</u> right way to go, as the majority doesn't know what it means and how which things, tasks and steps are required in the end to create an extension package when working regularly with it.</p></blockquote><p></p>
[QUOTE="chefkoch, post: 1011872, member: 10438"] I did not wanted to stop any enthusiasm and also don't what is the right or the wrong way. I've also already raised the NuGet idea here once and did not wanted to nag. First Thanks for [URL='https://forum.team-mediaportal.com/members/offbyone.73415/']offbyone[/URL] many items of your list of limitiatons, I probably would have missed. Even if in general it might be possible, WiX seems to be a bit overload to to me. It's not the fastest way of installing files, because it tracks files very detailed. There will be references deep inside the system to every extension that you have ever installed once, even if these refs are not critical and don't actually matter. If Windows Installer removes exactly the files that are installed, every file needs to have it's own component, unique GUID and explicitly defined in the wix script, iirc. Doing this manually is a no go for skinners. Harvesting the source directories by Heat brings in another component, which the extension author has to know about. Because MP2 was mentioned and feedback requested: In MP2 most extensions will be installed by simple copy commands. There should not be an installation UI required for, I assume 80% of all plugins, otherwise the plugins are not following the MP2 Best Practices, to [LIST] [*]provide usable defaults and prevent the requirement of any configuration before using a feature / plugin [*]if some setup is required ask on first usage [*]plugin files have to in [B]one[/B] plugin folder, including default skin files and all external binaries and references [*]Skins are "plugins", so all files for this skin are within this plugin folder not [/LIST] These and other things bring it down to simple copy commands for MP2 extensions. I have no idea anymore what additional tasks are required for MP1 Addons these days. Some of them might be even required for MP2 i.e. installing a service like MPExtended, but such "extensions" are so complex that these should not be deployed by "MP extension packages" only and instead kept in their MSI installer, which then maybe wrapped by a "MP extension package". Maybe the wix-approach can work, but it's worth imo also to take a look at the NuGet approach, especially because there are so much components already build, which fit exactly or basically our needs: [LIST] [*]NuSpec > defining package structure [*]NuGet.Core > versioning algorithm, dependency management, package metadata, ... [*]NuGet.exe > commandline tool for installing, uninstalling, updating, reinstalling, .... [*]NuGet.Server > WebComponent for hosting packages and providing a feed that can be reused by "clients" (external installer, GUI plugin, Gallery, ....) [*]NuGetGallery (OrchardGallery) > (ASP.net based?) WebSite component presenting available packages nicely in your browser [*]NuGetPackageExplorer > Utility for building and uploading packages [/LIST] A few of these things might not fit our needs perfectly i.e. the NuGetGallery which package pages "do not look good" ([URL='https://forum.team-mediaportal.com/members/dadeo.27204/']Dadeo[/URL]) ;) I also explained some of these things and provided links in the conversation I started with you and Dadeo within [U]May[/U] (got no reply) and a few days ago within the MP2 forums. See the link that has been posted by [URL='https://forum.team-mediaportal.com/members/tourettes.10858/']tourettes[/URL]. Maybe ti's worth to create some proof of concepts. take 2 or 3 plugin/skin examples from MP1 and MP2 and create these via WiX. Same could be done for the NuGet thing. I seriously believe at this point it is not worth asking plugin devs and skinners what is the [U]definite[/U] right way to go, as the majority doesn't know what it means and how which things, tasks and steps are required in the end to create an extension package when working regularly with it. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
MPEM Development Info & Testversion
Contact us
RSS
Top
Bottom