locked
Packaging a Java application for WHS RRS feed

  • Question

  • Hi, I write a server based tool for music management. It monitors a directory of music files and organises them. It's written in Java, and exposes a Web based user interface via an embedded HTTP server. It runs on Windows and Linux.

    Currently the Windows build is just a setup.exe that installs the app to the computer, with a bundled JRE if there isn't already one installed.

    I would like to produce a build for WHS, as it seems it would be useful for people who store music on their WHS.

    What are my options for creating this build? Ideally, I'd like this to be an Add-In. All the docs I read talk about Visual Studio, which I'd like to avoid.

    Wednesday, June 23, 2010 12:56 PM

Answers

  • Hi Dan,

    The WHS Add-In model (and by this I mean deployment of software to WHS) is based on a silent MSI package with a specific property set. Ken's pointed you at the SDK, which explains the requirements for the MSI package.

    As long as your app isn't using ports 80, 443, or 4125 you should be OK to deploy your embedded HTTP server.

    I think you've got two options:

    1. Wrap your setup.exe in an MSI package, and run setup.exe as a command from the MSI. As long as the MSI returns a success code, WHS will be happy and will show your software as an installed Add-In.

    If your installer requires user intervention (to choose settings etc.) then you're going to run into issues - WHS expects the MSI to be silent. You also won't get any WHS integration beyond the user being able to install and uninstall your app through the WHS Console rather than using RDP.

    There's a free wizard-driven MSI creator that may help: http://blog.tentaclesoftware.com/archive/2010/06/09/91.aspx

    2. Write a management/settings interface using .NET that displays as a tab in the WHS Console, and package the rest of your app as above. Obviously, this is quite a bit of work, but you'll be providing WHS users with the best experience possible.

    You can use Visual Studio Express to do this as well, so you don't need to pay for the IDE. I've got a tutorial up that explains the process using only free tools: http://blog.tentaclesoftware.com/archive/2008/12/05/quothello-worldquot-windows-home-server-add-in-part-1.aspx


    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Thursday, June 24, 2010 6:51 AM
    Moderator
  • The Windows Home Server SDK documentation is available here:

    http://msdn.microsoft.com/en-us/library/cc952481.aspx

    and includes deployment information.


    I'm not on the WHS team, I just post a lot. :)
    Wednesday, June 23, 2010 5:25 PM
    Moderator

All replies

  • The Windows Home Server SDK documentation is available here:

    http://msdn.microsoft.com/en-us/library/cc952481.aspx

    and includes deployment information.


    I'm not on the WHS team, I just post a lot. :)
    Wednesday, June 23, 2010 5:25 PM
    Moderator
  • If you'd want it as an addin, you're certainly going to have to use Visual Studio. It requires the .Net framework
    Wednesday, June 23, 2010 10:43 PM
  • Hi Dan,

    The WHS Add-In model (and by this I mean deployment of software to WHS) is based on a silent MSI package with a specific property set. Ken's pointed you at the SDK, which explains the requirements for the MSI package.

    As long as your app isn't using ports 80, 443, or 4125 you should be OK to deploy your embedded HTTP server.

    I think you've got two options:

    1. Wrap your setup.exe in an MSI package, and run setup.exe as a command from the MSI. As long as the MSI returns a success code, WHS will be happy and will show your software as an installed Add-In.

    If your installer requires user intervention (to choose settings etc.) then you're going to run into issues - WHS expects the MSI to be silent. You also won't get any WHS integration beyond the user being able to install and uninstall your app through the WHS Console rather than using RDP.

    There's a free wizard-driven MSI creator that may help: http://blog.tentaclesoftware.com/archive/2010/06/09/91.aspx

    2. Write a management/settings interface using .NET that displays as a tab in the WHS Console, and package the rest of your app as above. Obviously, this is quite a bit of work, but you'll be providing WHS users with the best experience possible.

    You can use Visual Studio Express to do this as well, so you don't need to pay for the IDE. I've got a tutorial up that explains the process using only free tools: http://blog.tentaclesoftware.com/archive/2008/12/05/quothello-worldquot-windows-home-server-add-in-part-1.aspx


    Tentacle Blog: http://www.tentaclesoftware.com/blog/
    WHS Disk Management: http://www.tentaclesoftware.com/WHSDiskManagement/
    Thursday, June 24, 2010 6:51 AM
    Moderator
  • Extremely helpful, Sam. Thanks very much.

    I guess I will need to find a way to spin up Visual Studio in a VM as part of my automated build. I'm a Linux person normally, you see.

    I'm actually a BizSpark member so I have access to the full versions of Visual Studio if needs be.

    I would like to go for option (2) - maybe it's as simple as a tab and an embedded HTML control showing the Web UI...

    Thursday, June 24, 2010 9:37 AM
  • Dan, bear in mind that the console is intended for the server administrator only, and isn't intended for daily use. By design, there should be no tasks that need to be performed on your server that aren't automated, possibly with overall configuration controlled through the add-in. I don't know anything about your product, really (is this you?), but I would imagine that you would have a settings pane for control of overall system settings, and (maybe, maybe not) a tab in the main area for status. If there's a lot of interaction with your tool, especially if it's interaction by multiple users, the console will not be the right place for it.

    Have you installed Windows Home Server anywhere to experiment with it? Have you taken a look at the Vail (Windows Home Server V2) beta yet? You might want to target Vail rather than V1...


    I'm not on the WHS team, I just post a lot. :)
    Thursday, June 24, 2010 1:01 PM
    Moderator
  • Insightful points Ken. And yes, that is me! I didn't want to post a link before in case it were considered advertising.

    The current use case is around people who store music on a server at home and then want to organise the music via bliss, on the server. Generally these are home, none business users and there is just one of them per household. My starting guess and where I would start from would be that the use of the UI is always performed by an administrator style user, because the type of people who own the music and a WHS are typically the "IT heroes of their own household". For that reason, having the UI in the console would not be so bad.

    However, maybe if it's just as easy to open a port on the WHS to allow access to the web UI I should go with that. It would serve both use cases.

    Thanks for the pointer to Vail. As part of Bizspark I have an MSDN licence, so have already downloaded the latest released WHS. I should definitely ensure compatibility with Vail too.

    Thursday, June 24, 2010 3:33 PM
  • Vail's extensibility model is very different from the V1 model; that's why I suggested targeting Vail rather than V1. Vail will probably be released in a few months so if you develop for V1 you'll be targeting a declining user base.

    As for how users will interact with your tools, I still think the console will only be where they'll set configuration options and (infrequently) check status. If they really need to do something, probably a web interface is best overall.


    I'm not on the WHS team, I just post a lot. :)
    Thursday, June 24, 2010 4:42 PM
    Moderator
  • On 6/24/2010 10:33 AM, Dan Gravell wrote:

    Insightful points Ken. And yes, that is me! I didn't want to post a link before in case it were considered advertising.

    The current use case is around people who store music on a server at home and then want to organise the music via bliss, on the server. Generally these are home, none business users and there is just one of them per household. My starting guess and where I would start from would be that the use of the UI is always performed by an administrator style user, because the type of people who own the music and a WHS are typically the "IT heroes of their own household". For that reason, having the UI in the console would not be so bad.

    However, maybe if it's just as easy to open a port on the WHS to allow access to the web UI I should go with that. It would serve both use cases.

    Thanks for the pointer to Vail. As part of Bizspark I have an MSDN licence, so have already downloaded the latest released WHS. I should definitely ensure compatibility with Vail too.

    If I may suggest this:

    Create your installer as mentioned before (where the MSI installs the java server and sends WHS the success code) and create a tab for managing the server in the console.  Set the port for people to access the server to something like 8080 and direct them in the instructions to use that port (or maybe create a client shortcut that will point there).  That way, they use the console for managing the behind-the-scenes stuff (like what they would configure if they clicked on "Preferences"), and then use their webbrowser to actually work with the server and their music.

    Hope this helps, and have a great day:)
    Patrick.


    Smile... Someone out there cares deeply for you.
    Have you updated today?
    http://update.microsoft.com


    Smile.. Someone out there cares deeply for you.
    Thursday, June 24, 2010 7:46 PM