Since we’ve seen some interest from developers wanting to join the Sitecore PowerShell Extensions team, I thought it might be worth documenting how my development environment is put together to allow for easier on-boarding of new members (Yes, we’re hiring! No, we can’t pay you ;) ). Maybe you just want to compile it yourself to make sure we’re not up to no good, or just plain see inside and play with it…

First of all you need to have Sitecore installed somewhere (obviously). For the purpose of examples I’ll assume your instance is located at C:\inetpub\wwwroot\Sitecore8\ and has the 3 standard folders Data, Databases and Website in them as it normally has. For that very same reason I’ll also assume that your Sitecore PowerShell Extensions project folder is located at C:\Projects\SitecorePowerShell\

1) Seed your Sitecore instance

First step that I always perform when I setup a new environment is to seed the Sitecore instance with the items required which is best done by installing the latest release of PowerShell Extensions.

2) Set up Sitecore SPE folders to use the latest files you’re working on

Since we’re likely to modify the assets like JavaScript, styles or XML Controls I want those to be automatically synchronized with changes I do in C:\Projects\SitecorePowerShell\ for this purpose I set up junction points in my Sitecore instance folder to point at my repository folder. To do this I delete the folders that were created by the install package and perform the Junction creation. Assuming the folders as they were specified before you can write a short batch file that would look like this:

3) Update your Sitecore instance to latest items

Once you I have my folders set up I look into the repository and look what’s changed since the last release and do the manual “Revert tree” on the content branches that have changed since the last release.

I Agree – this should be automated, but it happens so infrequently to me that I’ve not had much motivation to do that yet.

4) You will need Sitecore libraries

To build the project I’m putting the Sitecore Libraries in the /Libraries sub folder of the project folder. I have them structured like this

\Libraries\SC70

\Libraries\SC71

\Libraries\SC72

\Libraries\SC75

\Libraries\SC8

And depending on which version of Sitecore I’m working with I update the reference paths in Visual Studio to point to the relevant folder.

You’re probably going to need only the latest version of SC7x and SC8 as the code might not compile with older versions. It will run, but might not compile due to lacks in the older versions of Sitecore APIs.

5) Post Build step

Additionally I have a build action that copies the freshly compiled binary into the bin folder of my Sitecore instance:

The IF that checks the machine name is there only so that it doesn’t cause problems for other contributors as I only want this to happen on my machine. You might add a line for your machine if you want this happening automatically for you.

6) Develop!

Now you’re ready to start developing PowerShell Extensions. You can Build your solution and your Sitecore Instance should immediately pick up all tha changes. All you need to do to debug is attach to the relevant w3wp.exe process.

7) Contribute back

To serialize the changes you’ve introduced to the Sitecore content we’re using the following script:

running this script should serialize all your changes that are in the branches that we track. If you’ve added any items that would not be handled by this script (like a new integration point) you should modify this script to include those, and serialize it as well.

In the case of modifying the above script you should also modify the Prepare Console Distribution script in the same Script Library so that such items will make it into the next release package.

8) Be mindful of supported versions of Sitecore

Please be mindful that there are 2 branches that are actively developed at this time – Sitecore 8 is on the master branch while Sitecore 7 development is happening in the sitecore7 branch. What I usually do is develop on one branch and cherry-pick commits after switching to the other one.