MPEM Development Info & Testversion (1 Viewer)

[chefkoch]

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 offbyone 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

• 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 one 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

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:

• 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

A few of these things might not fit our needs perfectly i.e. the NuGetGallery which package pages "do not look good" (Dadeo)
I also explained some of these things and provided links in the conversation I started with you and Dadeo within May (got no reply) and a few days ago within the MP2 forums. See the link that has been posted by tourettes.

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 definite 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.

 

[Edalex]

The first big question is the installer package type, Is everyone happy using MSI installers based on Wix

How will it be done for skins? Is wix package monolithic?
I still think that the best way for them is to download only changed files like we are doing with updating svn copy.

 

[Oxan]

While creating the MPExtended installers, Wix has driven me crazy. Once your installers become a bit more advanced than just dropping some files, the documentation is severly lacking and it's very hard to debug when something goes wrong.

I don't have an opinion on which way we're going, but I personally wouldn't want to do another project using Wix again.

 

[chefkoch]

How will it be done for skins? Is wix package monolithic?
I still think that the best way for them is to download only changed files like we are doing with updating svn copy.

Reading this again reminds me that we won't be able to catch all scenarios with one "simple approach". From a MP2-developers pov, I don't expect the need for incremental updates for MP2 skins, as the most of the UI is defined as flexible and "small" XAML (xml-files) instead of static jpg or png-graphics.
Maybe I am wrong, but we don't have the experience, yet since there is nobody interested in working on it.

If there might be the case at sometime that requires such incremental downloads, I am pretty sure we can implement this as a "plugin", which provides the service to download single files from svn /git repositories. The plugins/skins that make use of this internal service are registered with the required infos about the connection details to the online repo through the plugin.xml service.

I also expect that there won't be a solution as a single application that fits for MP1 and MP2, because the requirements are different.
Nevertheless, I strongly believe that the concept can be the same and so the majority of the code can be shared.
For getting more specific feedback, tests, suggestions, support and ensuring the result can be used and fits the needs, going bottom-up (core > apps > glamour) will be better then top-down.

 

[Edalex]

I am pretty sure we can implement this as a "plugin", which provides the service to download single files from svn /git repositories.

This is exactly what I did.
Plugin is up and running for me.

 

[chefkoch]

I am pretty sure we can implement this as a "plugin", which provides the service to download single files from svn /git repositories.

This is exactly what I did.
Plugin is up and running for me.

Question is: can other skins register themselves to your plugin? to prevent the need for shipping this plugin specially designed with every skin?

Even if some people do not like to hear this: But such limitations are a result of the MP1 architectural design. It's not required to implement such functionality into the core application just to make it available. Having it as a plugin the right thing. If it is not possible for other plugins to reference it or register themselves to this plugin, then there is something wrong (in general, not in your particular case , because it might not be possible to do such things in MP1, I don't know).

But in the beginning the very first basics should be covered: Downloading, installing and uninstalling of packages including their dependencies, a package specification and an online component that is able to serve the packages that have been uploaded. A tool that is able to build and upload packages.
If these things are well designed, well structured and reliable, it can be implemented and used in GUI plugins and WPF application and extended with other components, maybe things like the incremental svn/git updater or a logo manager. But package management core is the most important part, imo.

While creating the MPExtended installers, Wix has driven me crazy. Once your installers become a bit more advanced than just dropping some files, the documentation is severly lacking and it's very hard to debug when something goes wrong.

I don't have an opinion on which way we're going, but I personally wouldn't want to do another project using Wix again.

WiX itself is very powerful, I like it and imo it's the most reliable installation framework that is available without any costs. NSIS is can not be compared if you have more advance installation needs and requirements like reliability and logging, ...)

Nevertheless I agree to your points about documentation and debugging.

 

[Edalex]

Question is: can other skins register themselves to your plugin? to prevent the need for shipping this plugin specially designed with every skin?

Skin is "registering" to plugin if skin folder has simple text/xml file with current svn revision and repository link inside. So with my approach every skin could be supported. Just need to choose between making own code for dealing with repositories and using available git and svn libraries.

 

[chefkoch]

Question is: can other skins register themselves to your plugin? to prevent the need for shipping this plugin specially designed with every skin?

Skin is "registering" to plugin if skin folder has simple text/xml file with current svn revision and repository link inside. So with my approach every skin could be supported. Just need to choose between making own code for dealing with repositories and using available git and svn libraries.

Sounds like a pretty good solution to me, yet simple to maintain. Wondering why nobody from MP1 did take a look at integrating it as a default plugin.
There could be a simple MPEI package per skin that only ships a few basic files, especially this xml, and everything else is downloaded additionally through this plugin.

This solves somehow the incremental installer, but get discussing this here furthermore will bring us off from the actual topic: MPEM

 

[Edalex]

Sounds like a pretty good solution to me, yet simple to maintain. Wondering why nobody from MP1 did take a look at integrating it as a default plugin.
There could be a simple MPEI package per skin that only ships a few basic files, especially this xml, and everything else is downloaded additionally through this plugin.
This solves somehow the incremental installer, but get discussing this here furthermore will bring us off from the actual topic: MPEM

Thanks, further discussion could be continued here https://forum.team-mediaportal.com/threads/skinupdater-plugin-mockup.119393/
I raised this topic to demonstrate that skins and tv/radio logos managament should be done outside MPEM as I think

 

[sa_ddam213]

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 offbyone 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

• 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 one 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

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:

• 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

A few of these things might not fit our needs perfectly i.e. the NuGetGallery which package pages "do not look good" (Dadeo)
I also explained some of these things and provided links in the conversation I started with you and Dadeo within May (got no reply) and a few days ago within the MP2 forums. See the link that has been posted by tourettes.

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 definite 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.

Can we install nugget packages without needing to install nugget dependencies, Or will plugins that need the ability to install on other PC's like MPDisplay still need to be separate from MPEM and just have there own installers?

As for the difficulty of using the installer frameworks, That's what the MPEM creator is for. I getting confused as everyone seems to think they have to manage these installer frameworks themselves, The idea was to follow a simple wizard to create and publish plugins.

I think I am missing the whole concept of MPEM.

Perhaps someone can just make a decision and I can get started, I don't mind not using MPEM for my plugins as its installer may be to advanced for MPEM. And if we want a different package system for Skins I see no point of changing the current MPEI implementation for skins as these will always be installed on the MediaPortal box, so you won't need to worry about installing a program to run the installer.

As long as we can make nice graphic UIs for the Nuget packages and they can install services/files without UAC interfering then that will be great and we won't need the MPEM UpdaterService at all, The user can just use MPEP to install, and plugins that are not compatible with the new installer system can just make their own NSIS installers.

But on the Nuget side is out of my depth and I will need someone to help implement the wizard on the MPEM UI, as my early attemts never got passed windows UAC and I could not figure out how to install services with Nuget packages. If someone can point me to some example of how to do those things I can give my Nuget mockup another try.