locked
Best Practices / Tutorials (Service on WHS) RRS feed

  • Question

  •  

    I have been successfully following the MSDN SDK tutorials and started to prototype my add-in… however; the SDK feels incomplete and I am wondering how to best proceed as I need to have some sort of service exposed on the WHS that other machines can connect and communicate with… I am wondering is there some sort of Best Practices or tutorials… any suggestions?

    I take it any code in the HomeServerTabExtender will only run when the Windows Home Server Console is open, hence I need some sort of service – or any alternatives?

    (The service will be one-directional – basically client machines will be forwarding log files)
    I worry about if one would be able to use the MSI installation (Settings ->Add-in) to install a Windows type service?? And I am also wondering about the firewall rules etc.

    Thanks in advance for any ideas or suggestions

    Sunday, February 3, 2008 6:44 AM
    Moderator

Answers

  • You're correct that you create the folder based on a GUID, and you'll need to hardcode that GUID to refer to it later. I use a string value stored in the assembly's properties.resources, passed as:

     

    Code Snippet

    new Guid(Properties.Resources.appGUID)

     

     

    whenever I need it.

     

    If you're going with the log drop-off method, you'll probably have client-side code that can check for the presense of a folder and create it if necessary. Maybe use \\server\public\<something>. Your console code can refer to it by that path too.

     

    As for the install portion, I'm not sure. Haven't played with what the Console install process allows. Can you programmatically create the database using Jet on the server, rather than copy an empty MDB?

    Monday, February 4, 2008 3:38 AM
    Moderator

All replies

  • Welcome to the WHS SDK, Reflector is now your new best friend: http://www.aisto.com/roeder/dotnet/. You can glean a lot from the Microsoft Add-In DLLs that isn't in the SDK (like how to enable the Apply button in the Settings dialog).

     

    Yes, if you need something running in the background, a service is the answer (that's how WHS anti-virus and UPnP server software works, for example).

     

    For your project specifically, do the clients need a service to connect to or can they just drop log files into a shared folder? Depending on what you want to do, a background process launched by TabExtender could process the logs, save them in some manageable format, and delete them when it's done.

    Sunday, February 3, 2008 8:36 AM
    Moderator
  • Reflector is a very good idea!

     

    Regarding the service, my primary concern is if one would be able to install the service using the *MSI package thru the Windows Home Server console or must one first remote desktop / terminal service into the WHS and install a service like that?

    This service could provide a simple TCP Listener service to which clients could connect and send in near real time about a 50 character string. – I do worry about asynchronous requests i.e. having 4 clients all try to connect at the same time… with the same information….whooops

    You mentioned the clients could simply write directly to a shared directory under say “Public\Aggregator” and I guess have each client simply drop (UNC) flat files into it prefixed with say machine name and date.
    Then the Windows Home Server console when that console tab is activated it could show a progress bar while the data is collected and during reconciliation - then store the finished logs in say Access DB format.

    I like this idea the most, this would be less intrusive Smile


    One more thing, what about security? Will my add-in have access to the file system for file IO operations and where should i store my add-ins configuration data i.e. user specific-settings.

     

    Thanks again,

    Alex

    Sunday, February 3, 2008 6:33 PM
    Moderator
  • The WHS console runs as Administrator, so accessing the file system isn't an issue.

     

    Have a look at Application Folders in the WHS SDK - they appear to be what MS is recommending for a storage area for Add-Ins (I'm serializing a bunch of XML files to my Application Folder, for example). You can use AppSettings as well.

     

    Sunday, February 3, 2008 6:43 PM
    Moderator
  • Oh, and installing a service: I haven't tried it, but my supposition is that it would just work, as long as your MSI doesn't have to prompt for user input (WHS installs the MSI silently).

     

    Sunday, February 3, 2008 7:07 PM
    Moderator
  • Thank you very much… I feel like I am heading the right way Wink

    I am looking at the WHS Application Folder, I would love to have a simple Application Settings XML file and use WHS Application Folder to save and load from upon tab-load but again the SDK was incredible short and disappointing.

    My limited understanding right now is that by using application folders WHS would create a physical folder:

    Under d:\folders\{GUID}

    Right?? – (scratches head)

    But with this I am a little puzzled as I would like to  expose a Monitor directory, say \\public\monitor to which the clients can dump the log files and then have my add-in gather these, process the information and I would like to store them in an Access DB *.mdb file (using JET). That would mean the my MSI installer would need to put a schema defined empty access database MDB file somewhere to which later my add-in can do simple inserts, selects and deletes.  Based on prototyping I expect this empty database file to be about 1 MB in size, would it be a good idea to store this file also in the Application Folder? If so how would I know the fully qualified path to my application folder during installation, unless of course I hardcode a GUID and store it in say the Application.Config ?

     

    Monday, February 4, 2008 1:59 AM
    Moderator
  • You're correct that you create the folder based on a GUID, and you'll need to hardcode that GUID to refer to it later. I use a string value stored in the assembly's properties.resources, passed as:

     

    Code Snippet

    new Guid(Properties.Resources.appGUID)

     

     

    whenever I need it.

     

    If you're going with the log drop-off method, you'll probably have client-side code that can check for the presense of a folder and create it if necessary. Maybe use \\server\public\<something>. Your console code can refer to it by that path too.

     

    As for the install portion, I'm not sure. Haven't played with what the Console install process allows. Can you programmatically create the database using Jet on the server, rather than copy an empty MDB?

    Monday, February 4, 2008 3:38 AM
    Moderator
  • Alexander, I would advise against putting a database (.mdb or otherwise) in an application folder. Right now, it's got a good chance of being subject to the file corruption issue detailed in KB946676, and in any case, as you describe your application your service is likely to be holding that file open most/all of the time, which has some implications for Drive Extender. (Remember that application folders take part in the Drive Extender process, including duplication of you wish to enable it.) Also, do you really need a drop folder? I think you said in a previous post that the messages would be relatively small; perhaps you could use a web service to deal with the log shipping instead?
    Monday, February 4, 2008 4:24 PM
    Moderator
  • Hi Sam,

     

    Thanks again for your reply.  (And thanks to Ken for your reply as well.)

    I am now successfully using the WHS (SDK) Application folders; ultimately I created a serializable Settings class and some serializer deserializer objects and as suggested I am storing some of the initial values as assembly resources

     

    I knew that I could not use ADO.net to create an Access Database, hence I thought I must somehow bundle a empty MDB with the tables already defined – what was I thinking???  Anyhow I discovered that using ADOX (ADO Ext. 6.0 COM) I am able to dynamically create an Access MDB file… which I am storing (for now) in the Application folder on the d:\ drive….

     

    That said, all seems well – I need to clean up my code by refractoring with the goal to keep it clean and avoid duplicated code… one thing I realized early on is that in WHS one’s application really has two ways a user might interact; that is one can navigate to the Console Tab or alternatively one could be on any other tab say Computer & Backups and open Settings and navigate to ones Setting extender…

     

    Regarding the Windows Service, I wrote some test code and it was able to control the service state from the Settings extender but I think at first I will try to get the shared folder drop working…

    Thanks again,

    Tuesday, February 5, 2008 3:19 AM
    Moderator