Corey Roth [MVP]

I had a great time at SharePoint Saturday Kansas City.  @MossLover and @SharePointKevin as well as many others did a great job organizing this event.  I met a bunch of great new people and I got to see some familiar faces again.  I had the privilege of speaking about Code Access Security again using Visual Studio 2010 and SharePoint 2010.  As promised, I am posting my slides and code samples from the talk.  You can find them at the bottom of this post.

I am pretty passionate about Enterprise Search and with MOSS 2007 I saw customers really struggle because wildcard search was not offered out of the box and most of the web parts in Microsoft.Office.Server.Search.WebParts are sealed.  Luckily, the most important one CoreResultsWebPart was in fact not sealed and I was able to hack together a wildcard search solution by inheriting it and using some hacky reflection.  Since SPC09, we’ve been hearing “the search web parts are no longer sealed”, this unfortunately is not true at all.  What they mean to say is that they have added a couple of override to CoreResultsWebPart that allow you to affect the query going in and the results going out.  This is a nice win, but there is still more desired.

It took me asking a lot of people at SPC09 to finally get a straight answer.  It was in the session, Customizing Search in SharePoint: Building Great Sites with Search, where I asked Harneet Sidhana at the microphone to get the story on why most web parts are still sealed.  The answer? The remaining web parts are currently still sealed by design.  The audience “booed”.  Seriously, they did.  I then asked to have the web parts unsealed and the audience applauded.

Let’s take a look at the web parts between MOSS 2007 and SP2010 Beta 2 and see what is sealed.

Looking at this list, I don’t really see anything that has changed from sealed to unsealed. Do you?  I will point out that CoreResultsWebPart has always been unsealed, but this is because PeopleCoreResultsWebPart inherits from it.  Did you notice that anything built since the Infrastructure Update of MOSS 2007 has been unsealed?

Now I admit, the main reason we wanted to inherit from these controls was to do wildcard search.  The Enterprise Search did a great job with the new keyword query improvements and this will be a non-issue now.  However, can they really say we will never want to extend their web parts?  Are they going to say that they have thought of every possible thing that the web part might possibly do and no one will ever extend it?  As a programmer, I don’t think I would ever have the guts to make a claim like that.  I know these web parts will require customization in the future.  Give us the ability to do it.

I know you might be thinking, “We just wanted to inherit from these web parts because we wanted wildcard search.  We have that now.”  This is true and I am very thankful.  This eliminates the need a lot, but more than likely we might need to make a change to something else though.  Want to customize people search?  What about best bets or the advanced search box?  Most web parts in SharePoint are unsealed, so why are the search web parts sealed?

The PeopleCoreResultsWebPart still being sealed is a huge deal.  For one, it doesn’t appear to support the new QueryManager class which means you can’t customize how it does queries or builds the results.  I need to confirm this though.  Take a look at the forums.  They speak for themselves.  Fifty results for the term wildcard in the Search forum.  I am passionate about this topic because I have seen the needs of my customers.  The fact that I might be stuck with another set of sealed web parts for another 3+ years is absolutely scary to me.

So what can we do?  Please post a reply in the forum or leave a comment on the blog.  We need to let them know our concerns while there is still time to make a change.  Please, unseal the web parts.  This post is cross posted to the SharePoint 2010 forums.

Let’s face it.  A lot of companies would rather you be unproductive and waste hours a day rather than spend a couple of hundred bucks on some more memory.  I don’t get it, but that’s the world so many of us are forced to live in.  You have to beg and plead, write justification, get approval from a handful of VPs only to get some guy at the help desk to tell you that you don’t need any additional hardware.  If that’s your case, I sympathize with you as I have been there plenty of times.  When people starting seeing the hardware recommendations for SharePoint 2010, many were in shock.  Most people were recommending 4 GB to 8 GB of memory just for the virtual machine itself.  They are significantly higher than what you could get away with in MOSS 2007.  After all with MOSS, I could get by with only 1 GB of memory allocated to a virtual machine.  It wasn’t ideal, but it did work ok.  If I had 2 GB of memory, things usually ran pretty smoothly.  Maybe you will disagree, but that was the case for me at least.  Keep in mind that we’re not talking about production here.  We’re talking about a development virtual machine.

Today, I will focus primarily on memory since this is where the bottleneck is going to be.  When it comes to developing, I have found that any modern CPU seems to do fine when it comes to performance.  A faster hard disk is always nice, but really, it’s always lack of memory that causes issues.  To date, I have set up three virtual machines on Beta 2: one with SharePoint Foundation, one with SharePoint Server 2010, and one with SharePoint Server 2010 with FAST Search installed.  The memory requirements I have seen on these has varied vastly (as you would expect).  For today’s post, I am considering a complete self-contained SharePoint 2010 environment on a virtual machine that includes Windows Server 2008 R2, Active Directory, and SQL Server 2008.  Let’s start by looking at a summary of my findings.

Now, I’ll say these numbers are completely unofficial.  You may have different results.  If you have results you would like to share, please leave a comment.  I quoted numbers for Visual Studio separately because you may not have Visual Studio running or you might be an admin or something.  Obviously, the memory requirements of Visual Studio vary vastly at times depending on what you are doing, but this is just a guideline.  These numbers will also vary depending on what services you have running in SharePoint.  In this case, I have every service I can see to start running.

As you can see installing FAST adds considerable demand to your memory requirements.  The reason I add the asterisk here is that I think it will probably consume more memory if I make it available.

So what you can take from this is if you just want a quick development environment and you don’t need the full SharePoint Server, you can use SharePoint Foundation to do some development work with relatively “low” memory requirements.  You can further use even less memory by using an external SQL Server.  On most of my installations, I have found SQL Server using 500 MB – 600 MB of memory.  By moving that off to another server, you can really trim down your memory requirements.  If you don’t need a domain controller on your server, you can shave a bit more off too (but don’t expect to gain a lot here).

Now, the last thing I will point out is this is what you can get by with.  It’s not necessarily ideal.  You may find that your hard drive is churning a lot as it is probably doing a lot of swapping.  You may find yourself waiting a lot just for the SharePoint site to spin up or to compile and deploy something.  It’s better than nothing though.  Again, these are just some of the numbers I was seeing on my installations.  If you have any numbers you would like to share, please leave a comment.

I’m not expert in PowerShell, but I thought I would share a few basics I picked up at Ignite and various other places along the way when it comes to getting started with PowerShell.  The easiest way to issue SharePoint commands with PowerShell is by running the SharePoint 2010 Management Shell located under Microsoft SharePoint 2010 Products in your Start Menu.  However, it is good to understand what this shortcut actually does.  PowerShell works by using the concepts of snapins.  A snapin is simply a DLL installed with gacutil and installutil that implements a particular interface.  This means you can write your own snapins to do whatever you want.  All of the SharePoint commands are found in Microsoft.SharePoint.PowerShell.dll.  So what this shortcut does, is it runs PowerShell with a script located at the path below.

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1

This script simply uses the Add-PSSnappin command to load the SharePoint commands.  If you started PowerShell by using some other link, you can also load the SharePoint comamnds by using this command.  Note that the name is always specified without .DLL.

Add-PSSnapin Microsoft.SharePoint.PowerShell

Working with PowerShell is in a lot of ways similar to working with a regular command prompt, it is just a lot more powerful.  All of your familiar DOS commands will work because they have been aliased to child items.  For example, Get-ChildItem is how you display the contents of the current folder in PowerShell, but you can also just type in dir to get the same results.

Knowing the name of the snappin lets us do a few things.  First, we can get a list of all of the commands contained in it by using the Get-Command command with the –PSSnapin parameter.  For example:

Get-Command –PSSnapin Microosft.SharePoint.PowerShell

Of course, there are 500+ SharePoint PowerShell commands returned so it makes that list difficult to deal with.  So you can use some old school command prompt tricks to make the list more manageable.  You can issue the command and hit the Pause key (lol).  You can, use the | more technique to view one page at a time.

Get-Command –PSSnapin Microosft.SharePoint.PowerShell | more

You can also redirect the output to a text file like this.

Get-Command –PSSnapin Microosft.SharePoint.PowerShell > commands.txt

Then you can just open the file in notepad or the editor of your choice.  If you want a more verbose description of how each command is used, you can use the Format-List command and pass it specific property names.  Notice the properties I specified (Name, Definition) I just got from the table above.

Get-Command –PSSnapin Microosft.SharePoint.PowerShell |  Format-List Name, Definition

This is great, but then you might want to know more about the specific syntax of a command.  For this you can use the Get-Help command.  Just execute it followed by the name of the command you want information on.  For example if I want to know about Get-SPWeb, I would issue.

Get-Help Get-SPWeb

It would return something that looks like this.

Once nice thing about PowerShell is that you can use tab to help you complete commands.  For example you can type “Install-SP” and then press tab and it will cycle through the available commands.  What is even better is that you can also use the tab key to add the parameters to the command.  This is useful for when you can’t remember the exact parameter name.

Another thing I really like about PowerShell is that many times if you leave off a parameter, instead of just giving you an error, it will prompt you for the value.  For example, if I want to create a new site collection, I use the New-SPSite command.  I don’t remember the parameters, but it starts prompting me for things like the URL and owner name.  And of course you can always use Ctrl+C to break out of the command if you change your mind.

There is a ton you can do with PowerShell and I won’t be able to cover it all in this one post.  The power is that it allows you to string together complex commands together to get things done.  If you want to build a script, you simply start by creating a .ps1 file.  You can build this in notepad.  There is also a PowerShell Integrated Scripting Environment (ISE) that will allow you to actually debug your scripts.  One thing to be aware of is that to execute scripts, it requires an execution policy to be set.  Chances are this is already set appropriately, but if its not, your script will not run.  The three possible settings are restricted, unrestricted (prompt to run), and bypass.  I think most people set this to bypass (although I am sure there are security considerations) with the following command.

Set-ExecutionPolicy bypass

There is so much to say about PowerShell.  I hope this post serves as a good starting point to start exploring what you can do with it.  I’ll be covering more advanced PowerShell topics in the future.

Visual Studio 2010 makes it really easy to add and deploy solutions when you are developing, but you may eventually want to deploy those solution packages elsewhere right?  We can still use stsadm, but that is effectively considered deprecated now in favor of PowerShell.  In the past to add a solution, we used an stsadm command like the one below.  In today’s example, we’ll be working with a package called SharePointProject2.wsp on my server named sp2010.

stsadm –o addsolution –name SharePointProject2.wsp

To get started with PowerShell, run the SharePoint 2010 Management Console located in your Microsoft SharePoint 2010 Products folder on your start menu.  This automatically loads the Microsoft.SharePoint.PowerShell snappin so that we can execute SharePoint commands.  To install a solution we use the Add-SPSolution command.  If you are using a Sandboxed solution you would use Add-SPUserSolution instead.  It takes just one parameter, –literalpath, which is the path to the solution file.  One thing that is different is that you must specify the full path to the file for some reason.  I haven’t been able to get it to take a path to the solution in the current folder even if I make use of .\ before the filename.  Here is an example.

Add-SPSolution c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp

In this case you don’t actually have to type –literalpath before the parameter.  This is what it looks like when executed.  You can see that it displays the id of the solution along with its deployment status.

Now we need to deploy the solution.  In the past, we used an stsadm command like the following.

stsadm –o deploysolution –name SharePointProject2.wsp –url http://moss-server –allowCasPolicies –immediate

We would also follow this up with a call to stsadm with the execadmsvcjobs operation.  To do the same operation in PowerShell, we use the Install-SPSolution command (again use Install-SPUserSolution for Sandboxed solutions).  You can use the Get-Help command (i.e.: Get-Help Install-SPSolution) to get more information on a command but it’s not always obvious what it is expecting as you can see below.  That is why I am writing the post today.

The first parameter you need is the –Identity parameter.  This is the name of the solution package (i.e.: MySolution.wsp).  Depending on if you are using the GAC or Code Access Security, you will specify either –GACDeployment or –CASPolicies.  You then need to specify a specific web application using the –WebApplication parameter or –AllWebApplications to deploy it to all web applications (assuming the manifest allows it).  If you need to force the deployment, you can still use the –Force command.  Here is what an install command might look like.

Install-SPSolution –Identity SharePointProject2.wsp –WebApplication http://sp2010 -GACDeployment

I’ll point out that executing this command actually does do the deployment operation.  You don’t have to fire off something to execute a job later like you did with stsadm.

You might want to update your solution, so we’ll talk about how to do that as well.  Here is what your stsadm command might have looked like in WSS3.  Which would also be followed up with an execadmsvcjobs operation.

stsadm –o upgradesolution –name SharePointProject2.wsp –filename SharePointProject2.wsp –immediate –allowCasPolicies

The upgrade solution syntax is similar to the others.  We just have to specify an identity and a literalpath with the Update-SPSolution command.  The identity is the name of the package on the server to upgrade and the literalpath is the full path to the new solution package on the file system.  Here is what that might look like.

Update-SPSolution –Identity SharePointProject2.wsp –LiteralPath c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp –GACDeployment

We’ve talked about everything else, so we’ll finish it up by talking about retraction and removal.  To retract a solution we use the Uninstall-SPSolution command.  By now you are probably noticing a pattern in the way things are named.  Install –> Deploys, Uninstall –> Retracts.  It also just uses the -Identity parameter and the –WebApplication parameter.  You can also use the –AllWebApplications parameter to retract it from all web applications. Many of these commands may prompt you with an “Are you sure?” type prompt.  You can skip this prompt by adding a –confirm parameter.  Here is what it looks like.

Uninstall-SPSolution –Identity SharePointProject2.wsp –WebApplication http://sp2010

Lastly, to remove the package from the solution store, we use the Remove-SPSolution command.  It just takes the name of the package.

Remove-SPSolution –Identity SharePointProject2.wsp

I hope this helps.  If you’re like me, it’s one thing to see the docs on something, but I like to see real examples.  There aren’t any examples in the Get-Help command yet.  This should cover all of the common commands that you probably used to used with stsadm in regards to solution deployment.  The nice thing is that you can script these things together very easily and create highly flexible PowerShell scripts.  Expect a few more posts soon on the basics of working with PowerShell and SharePoint 2010.

To learn more about using PowerShell with features, see Activating and Deactivating Features with PowerShell

If you have tried to build a quick console application using Visual Studio 2010 to work with SharePoint 2010, you might find that you run into the following error.

Unhandled Exception: System.IO.FileNotFoundException: The Web application at http://sp2010 could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application. 

Consider the following console application.

All this console application does is display the title of the root web of the site collection.  However, when I run it, I get the FileNotFound error. 

You first might think to check your path or something like that, but this is actually caused by a completely different issue.  As you know by now, SharePoint 2010 is a 64 bit application.  However, when you create a new Console Application, it does not default to x64, it defaults to x86 as shown below.

View your project properties, go to the Build tab and change the platform target to x64.  Run your console application again and everything should work as expected now.

This doesn’t just apply to Console applications, but could also apply to any other type of external application you might build.  Just make sure it is set to x64.  Technically Any CPU would work as well, but SharePoint only runs on x64 so you might as well just use that.