join_the_puzzle_crowd_400_clr_10889Since 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:

set SITECORE=C:\inetpub\wwwroot\Sitecore8\
set PROJECT=C:\Projects\sitecorepowershell\

rmdir "%SITECORE%Data\serialization /Q
mklink /J %SITECORE%Data\serialization %PROJECT%Data\serialization

rmdir "%SITECORE%Website\sitecore modules\PowerShell" /Q
mklink /J "%SITECORE%Website\sitecore modules\PowerShell" "%PROJECT%sitecore modules\PowerShell"

rmdir "%SITECORE%Website\sitecore modules\Shell\PowerShell" /Q
mklink /J "%SITECORE%Website\sitecore modules\Shell\PowerShell" "%PROJECT%sitecore modules\Shell\PowerShell"

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.

Deserialize_SPE_items

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.

VS_SPE_References

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:

IF %USERDOMAIN%==WIN123 xcopy C:\Projects\sitecorepowershell\bin\Debug\Cognifide.PowerShell*.* C:\inetpub\wwwroot\Sitecore8\Website\bin\*.* /s /e /c /y

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:

master:system/Modules/PowerShell/Script Library/Platform/Development/PowerShell Extensions Maintenance/Serialize Change

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.

SPE_Development_ItemChangesPersistence

 

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.

I’m really excited to see the 3.0 version of Sitecore PowerShell Extensions released. There have been more effort, love and sweat poured into this version by the whole team than I would ever expect. This blog has been written to assert the smoothest upgrade experience possible. While we’re always striving for the smoothest upgrade possible – this version introduces some changes that require you to perform a manual step or two. While those could be automated to a degree, making those manual was a conscious choice as I didn’t want to break e.g. your Insite instance that stores some of its files in the “Console” sub-folder of the Website folder.

Before upgrading your instance from Sitecore PowerShell Extensions 2.x to 3.0 please make sure you have your scripts backed up as the upgrade process might cause some of your scripts to be removed. This is especially true if you used the integration script libraries and you are upgrading from SPE 2.7 or earlier. If you’re upgrading from version 2.8 and your script live in your own modules You should be safe although it’s always smart to back up.

The steps you need to take prior or after installing the new version of the PowerShell Extensions:

You MUST delete the following folder from your sitecore Website folders:

  • \sitecore\shell\Applications\PowerShell\

IMPACT: If you will not delete that folder or the contents of that folder the PowerShell Extensions applications might no longer work or produce unexpected results

You SHOULD delete the content of the following folder:

  • \Console\Services\

IMPACT: Should you not remove the folder – the PowerShell services  might be available from both the old URL and the new URL available at: “\sitecore modules\PowerShell\Services\”

You CAN delete the following folders:

  • \Console\Assets\
  • \Console\Scripts\
  • \Console\Styles\

IMPACT: Those folders now exist under “\sitecore modules\PowerShell\” but their existence in the previous location does not have any impact other than taking space on the server,

That is pretty much it. I hope to blog about the new features shortly as there is plenty of them and the whole PowerShell Extensions team is really excited to make those available for you.

This has been on my plate for a while and to be honest I’m not sure what took me so long as it literally took around 4 hours from start to completion which I consider a testament to how easy it is to create additional integrations with PowerShell akin to the Gutter integration or the login/logout integration Michael West has recently introduced in the platform.

creating_a_better_process_800_clr_7366

What this integration allows you to do is to eliminate the need for code deployment when you’re in need for a quick action here and there for when a user executes a workflow command.

You might find this article helpful by a Cognifide colleague of mine. I especially like this image which illustrates nicely where actions fit in a Sitecore workflow.

 

They are effectively little bits of code that get executed automatically when a user triggers a command.

Read the rest of this article »

It’s been a while since my last summary on April 2012 but finally getting to update the Reference page with the latest community summary for Sitecore PowerShell Extensions.

book_open_light_shine_out_800_clr_9090

Following are the updates I will be pushing onto the reference page I’m trying to keep up to date and failing miserably most of the time. Read the rest of this article »

Sitecore PowerShell Extensions 3.0 Modules proposal

brown_cardboard_box_light_800_clr_4510

A large problem with Sitecore PowerShell Extensions up to version 3.0 was the lack of proper separation of solutions provided on top of it from the core of the module. The problem is that all integrations look for scripts in the main Script Library but they look for them solely in their single libraries. The specification outlined in this blog aims at solving this issue. Read the rest of this article »

Sitecore PowerShell Extensions Persistent Sessions

coach_time_out_400_clr_4749 If you’re reading this, chances are you’ve probably read about the ways of putting scripts in the Content Editor ribbon or Context Menu. Those are some simple and quick ways of extending the Sitecore UI to do quick actions accessible for your users without them having to even know about the existence of PowerShell in your system. Up until now however we’ve not been very vocal about the fact that those does not really have to be quick one-off actions but they can indeed form a broader solution to your problem through the use of persistent, named sessions. In fact Sitecore PowerShell Extensions (SPE) allow you to manage sessions and decide that it should stay in memory after the script have executed. In fact SPE does quite a bit of session maintenance itself that you might want to be aware of.

What do I really need to know about script sessions?

ScriptSession is an object that encapsulates a PowerShell Runspace. Whenever you decide to run a script 2 things will happen:

  • a ScriptSession is requested from the SessionManager (which either creates a new session or recovers an existing named session)
  • after which it’s being used to execute your script in either the current thread or a new Sitecore Job is being instantiated and the Script session is passed to it for execution.

This is decided internally based on what you’re using a Session for unless you’re instantiating it directly (like described in this post) in which case you’re responsible for disposing it.

After the script is executed and the Job has ended the session is discarded unless your script has a Persistent Session ID which I will show you how to define in just a moment.

Great so there are sessions… but what are they good for?

Read the rest of this article »

Creating reports is probably a task that every developer dread. I for once always felt like listening to Tennessee Ernie Ford’s “16 Tons” every time when I was supposed to do it for yet another project audit – especially this part resonated with me:

I was born one mornin’ when the sun didn’t shine
I picked up my shovel and I walked to the mine
I loaded sixteen tons of number nine coal
And the straw boss said “Well, a-bless my soul”

While the Advanced System Reporter gets you a long way, I’ve found that there were still many scenarios where I would have to write the reports by hand. Madness… Fast forward to Sitecore PowerShell Extensions (or SPE for short) it actually this doesn’t have to be like that and creating reports can be both quick and fun – provided you’re going to use  Winking smile the module.

figure_presenting_report Read the rest of this article »

Working with Sitecore items in PowerShell Extensions

Reading some of the blogs from the Sitecore community I find it pretty apparent that we didn’t do a great job advocating the optimizations that PowerShell Extensions have introduced for working with Sitecore items. This blog attempts to rectify this problem to a degree.

group_construction_workers_400_clr_8597

How do I retrieve my Sitecore items the PowerShell way?

The most natural way to retrieve Sitecore items is with use of Get-Item and Get-ChildItem commandlets. That is because those 2 commandlets add a PowerShell wrapping around them that allows the functionalities that I’m going to describe in the next section of this blog after I’ll tell you all about retrieving items.

If you have retrieved your item directly using the Sitecore API you can still add the nice wrapper when you pipe them through the Wrap-Item commandlet as well. Some of those enhancements work in the older versions of PowerShell Extensions but I would encourage you to upgrade to the latest version (2.7 at the time this blog was written) to leverage the full potential of the environment.

Read the rest of this article »

Sitecore PowerShell Extensions Remoting

hand_controlling_puppet_figure_400_clr_14285I’ve been meaning to write this article for quite a while since the functionality to remote into the Sitecore environment exists in the module at least for at least a couple of versions now and the recent email from one of the Sitecore PowerShell Extensions users convinced me this cannot wait any longer.

When would I remote into my Sitecore instance?

You would probably need this as part of your Continuous Integration or installation scripts. If you need to manipulate Sitecore data from your deployment script remoting is the right solution for you.

How is that special?

We have a a number of web services that could somewhat achieve this functionality for even longer but I didn’t consider those sufficient since a real remoting functionality cannot be limited to just passing text results from the scripts passed but rather should enable the script writers to achieve true interactions between scripts running locally and the scripts that are being executed on the server.

To enable remoting on your Sitecore instance you don’t really have to do anything the web services are already deployed when you install Sitecore PowerShell Extensions. On your local machine all you need to do is include the commandlets in the script that you can find at the following path in your sitecore instance:

master:/system/Modules/PowerShell/Script Library/Functions/Remoting

When you execute the script You will get 4 new commandlets at your disposal:

Read the rest of this article »

Posted in Best Practices, Continuous Deployment, PowerShell, Sitecore, Software Development, Web applications
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 4.00 out of 5)
Loading...Loading...
| 1 Comment »

ZippingSitecoreLogsI’ve decided to 1-up the game from my previous post and zip something that isn’t really a real file but rather a blob in a Sitecore database. The script below is based heavily on the last post but instead of just zipping content of a flat folder traverses the Sitecore item tree and zips all files beneath the current folder.

If you have downloaded the 2.1 version of the Sitecore PowerShell Console from the Sitecore Marketplace you will actually have the script deployed on your system already.

Here’s how it looks like for your user in the Content Editor:

ZipAndDownloadContextMenu

The script that performs the operation looks as follows: Read the rest of this article »