locked
Development Environment setup RRS feed

  • Question

  • I want to do some customization of WHS for my own use.  From looking at the WHS SDK it looks like it is just really documentation about the API and the classes used.

    So if I understand this correctly in order to write code for this the C# express needs to be installed on the WHS box and the coding is then done on this box as opposed to my standard development PC.

    Can C# 2008 express be used or does it have to be 2005.   Currently I still do all my develoment in VS 2003 and have been planning on skipping 2005 and going directly to 2008.

    Anyone care to describe your setup for writing code for WHS.

    Thanks...
    Friday, January 25, 2008 7:42 PM

Answers

  • There are two .dlls referenced in the SDK documentation. You may copy them to a location that is accessible from your development PC. Testing of any add-ins requires a full installation of Windows Home Server at this time; that could be done using a virtual machine until you're reasonably sure you won't mess up a real machine. Smile
    Friday, January 25, 2008 10:30 PM
    Moderator
  • As Ken says, you can use your local development PC if you don't want to develop directly on the server.

     

    Copy Microsoft.HomeServer.SDK.Interop.v1.dll and HomeServerExt.dll from WHS to your local PC and add them as references for your project.

     

    Don't worry about creating an MSI package until you're ready to release your add-in; you can copy the output .dll directly to the WHS Program Files folder on the server and restart the console.

     

    See Brendan's "faster referencing" tips here as well: http://www.brendangrant.com/WHS/WHSDevTips.htm

    Saturday, January 26, 2008 12:51 AM
    Moderator

All replies

  • There are two .dlls referenced in the SDK documentation. You may copy them to a location that is accessible from your development PC. Testing of any add-ins requires a full installation of Windows Home Server at this time; that could be done using a virtual machine until you're reasonably sure you won't mess up a real machine. Smile
    Friday, January 25, 2008 10:30 PM
    Moderator
  • As Ken says, you can use your local development PC if you don't want to develop directly on the server.

     

    Copy Microsoft.HomeServer.SDK.Interop.v1.dll and HomeServerExt.dll from WHS to your local PC and add them as references for your project.

     

    Don't worry about creating an MSI package until you're ready to release your add-in; you can copy the output .dll directly to the WHS Program Files folder on the server and restart the console.

     

    See Brendan's "faster referencing" tips here as well: http://www.brendangrant.com/WHS/WHSDevTips.htm

    Saturday, January 26, 2008 12:51 AM
    Moderator
  • As Ken and Sam pointed out: you can develop in your local development environment.


    Copy any WHS libraries referenced locally. Using Brandan's WhsTestLoader.exe you will be able to debug the addins internals. After copying your addin to the WHS directory you can use Visual Studio remote debugging to debug the real thing. Ken also mentioned installing a virtual WHS machine. I succesfully use Microsoft Virtual PC 2007 (do not activate WHS) for debuging and testing.

     

     

     

    Saturday, January 26, 2008 5:09 PM
    Moderator
  • I also recommend remote debugging on top of a VM.  I use VMware but Virtual PC is fine.  There are a lot of advantages, not the last of which is managing 120 day trial.  You'll never have to reinstall WHS if using VMWare.  Just restore a previous image.

     

    Ryan

     

     

     

     

     

    Saturday, January 26, 2008 7:17 PM
  • Umm, Ryan, I don't know for sure about VMWare, but doesn't it synchronize the guest OS clock with the host OS clock? If it does, your 120 day eval copy will go belly up after 120 days, even in a VM.
    Sunday, January 27, 2008 5:35 AM
    Moderator
  • With VMwave Lab Manager vm's you have control of the clock independently of the guest PC.  Extremely useful for developers working on this kind of trial protection code.

     

    Not sure about plain-jane free VMware; haven't used that in a while.  But I would think it would work the same, assuming you were using the latest version.

     

    EDIT: I forgot to add, if plain-jane VMware doesn't have this, then disregard what I said, and be sure not to activate.  Lab Manager is probably out of the price range of most DIYers.

     

    Ryan

    Sunday, January 27, 2008 2:13 PM