In case you're wondering why you might want to do this, I often create backups of code that I'm working on.  I deliberately exclude the "packages" folder from the backup so I keep the backup file size as small as possible.  For what it's worth, I typically exclude the "bin" and "obj" folders too.  Anyway, if I need to refer to one of my backups, I wanted a way to easily re-build the packages folder.  As the packages.config file IS included in my backups, I can easily re-install the relevant packages via the following Powershell script executed from the Nuget Package Manager Console.  For example:

PM> .\Install-Packages.ps1

Where "Install-Packages.ps1" contains the following code and is in the same folder as my Visual Studio solution (.sln) file:

$projects = Get-Project -All

foreach($proj in $projects)
{
 $projName = $proj.Name
 Write-Host "Processing project $projName..."

 $path = Join-Path (Split-Path $proj.FileName) packages.config

 if(Test-Path $path)
 {
  Write-Host "Processing $path..."

  $xml = [xml]$packages = Get-Content $path
  foreach($package in $packages.packages.package)
  {
   $id = $package.id
   Write-Host "Installing package $id..."      
       Install-Package -Id $id -Version $package.version
  }
 }
}

A possible improvement would be to wrap the above code in a Powershell function and include that unction in my Nuget profile as discussed in Setting up a NuGet Powershell Profile.

The first vistor to your site after one of these events will encounter a poor user experience (slow response) whilst a new IIS app pool is initialised.  Note, this IIS behaviour is "inherited" by Azure so read on if you're hosting your site on Azure and care about a consistant user experience.

To prevent this behaviour you can't just go into the IIS manager and make the necessary amendments to the default configuration when your site is hosted on Azure.  Any configuration changes you make in a remote desktop session to your Azure instance(s) will get lost when the Azure fabric controller recycles your instances.

The solution is to make the necessary IIS configuration changes via an Azure statup script as follows:

1) Startup script - add a startup script (batch file) to your web role project.  I like to store mine in \Startup\Startup.cmd.

REM *** Prevent the IIS app pools from shutting down due to being idle.
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

REM *** Prevent IIS app pool recycles from recycling on the default schedule of 1740 minutes (29 hours).
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.recycling.periodicRestart.time:00:00:00

*** GOTCHA 1 of 2 - Make sure your startup script is ANSI (not UTF-8) encoded.  I've found good ol' "Visual Notepad" is the best way to achieve this task.  However, I believe Visual Studio has an equivilent File...Save As option also.
*** GOTCHA 2 of 2 - Make sure you select "Copy Always" as the "Copy to Output Directory" option in the properties for your startup script file. 

2) ServiceDefinition.csdef - merge the "Startup" element highlighted below into your ServiceDefinition.csdef.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyWindowsAzureProject" xmlns="https://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="MyWebRole" vmsize="Small">
 ...
    <Startup>
      <Task commandLine="Startup\Startup.cmd" executionContext="elevated" />
    </Startup>
  </WebRole>
</ServiceDefinition>

Startup scripts run from "f:\approot" on your Azure instances so bear that in mind if you're using relative folder references.  Personally, I like to make any path referencing as explicit as possible.

Startup scripts are the recommended way to make any pre-requisite installations and/or configuration changes that might be needed by your application.  Mastering startup scripts is essential to performing more complex deployments to Azure.  Whilst it might take a little more effort that the "old way", I'm confident that you'll appreciate the many benefits of the Platform As A Service (PaaS) approach employed by Azure so the additional, incremental effort, is well worth it.

Note, the following comments are only appropriate to a DEVELOPMENT environment.  PRODUCTION environments should follow deployment documentation on Technet.

Firstly, some assumptions:

• You really need at least 4Gb of RAM (preferrably more).  Even the official documentation acknowledges this.
• I prefer to keep my development environments as close as possible to production and for that reason I develop on Server 2008 R2.
• I'm building a development machine for full SharePoint Server 2010 not the free SharePoint Foundation 2010.
• I'd prefer a "complete" install rather than "stand-alone" install for a variety of reasons including I want full SQL not SQL Express.

FAQs.

1) Physical or virtual?

Virtual is more flexible if you have enough RAM (ie 6Gb minimum for single VM approach).  Personally, due to the limitation of 4Gb of my laptop I've gone with physical using a .VHD native boot approach as disccussed in this post.  However, there are reasons why this work-around isn't desirable is discussed in this post.

2) If I choose virtual, 1, 2 or 3 servers?

3 is great if you've got enough RAM as you can keep AD, SQL and SharePoint all on seperate physical tiers just as I know you would in a production deployment.  However, you'll need 8Gb RAM to get a 3 server approach running well.  Many developers prefer to go with a single VM so they don't have to boot multiple VMs.  2 VMs is a possible comprimise (ie AD & SQL on same box).

3) I heard I can do a complete installation on a single server using non-domain accounts?

 It's possible and documented at this post.  However, there are reasons why this work-around isn't desirable some of which are discussed in this post.

My Installation Checklist

1) Install 2008 R2. If you go physical, resolve any driver issues as you normally would..

2) Add "Active Directory Domain Services" role.
 - Run dcpromo.exe, new forest, 2008 R2 functional level.
 - Install DNS.

3) SQL 2008 R2
 - Database Engine Services
 - Full-Text Search
 - Managent Tools (Basic & Complete)
 - Use the same service account, system.
 - FILESTREAM - enable for both Transact-SQL & file I/O

 4) SharePoint Server 2010
 - PrerequisiteInstaller.exe then setup.exe.
 - Choose to run the configuration wizard.
     - Create a new server farm.
     - Create a domain user and use it for the db access account.
     - Central admin onto a known port eg 9999.
 - Central admin farm config wizard
     - Use the existing managed account.

5) Office 2010
 - Don't need Access & Publisher

6) SharePoint Designer 2010

7) Visual Studio 2010
 - Custom install, uncheck:
     - VB. C++. f#
     - Graphics library
     - Dotfuscator
     - SQL Express

Good luck!

 Unfortunately, I couldn’t leave it up as I don’t want it to start accruing charges.  However, I included a screen capture of it running below!

 I set it up under the “free” Introductory Special that is available to the general public.  The most limited "free" resource under the intro offer is the 25 hours.  Note, The intro offer available to MSDN subscribers is much more generous.

 Key findings from my investigation:

·         I needed to provide my credit card even for the “free” intro.

·         I needed to delete the app to prevent it using up my hours.  Stopping it isn’t good enough.  Fortunately, you can keep the URL when you delete the app as long as you don’t delete the service.

·         The db will start accruing charges if you leave it there beyond 3 months provided by the intro.  You can’t stop a db but you can drop it or the entire server.

·         Generating a SQL Azure compatible script to create a typical app db was easy (Tasks->Generate Scripts).  However, you do need the SQL R2 version of SQL Management Studio.

·         Here’s an example ASP.NET web.config db connection string:

 <add name="MyDB" connectionString="Server=tcp:your_server.database.windows.net;Database=your_db;User ID=your_user@your_server;Password=your_password;Trusted_Connection=False;Encrypt=True;" />

https://live.visitmix.com/Videos

For those unfamiliar with MIX10, it’s a “conference for web designers and developers building the world's most innovative web sites”.

I’m planning to incorporate watching some of these videos into my ongoing training plan.

The session on Orchard is particularly of interest, “the Orchard project is focused on delivering a .NET-based CMS application that will allow users to rapidly create content-driven Websites, and an extensibility framework that will allow developers and customizers to provide additional functionality through extensions and themes”

The issue appears to be due to SharePoint interfering with the JavaScript that is necessary to process an ASP.NET post-back.  Anyway, adding an OnClientClick attribute as illustrated in the following example resolved the issue for me.  I hope this helps you to overcome this issue if you happen to encounter it also!

<asp:Button ID="btnMybutton" runat="server" OnClick="btnMybutton_OnClick" Text="Button" OnClientClick="_spFormOnSubmitCalled = false;" />

The skip forward & back buttons didn't work!

At first I feared the issue was an intended "by design" change.  After all, I'm sure the commercial TV networks don't like us skipping over their ads.  Fortunately, it seems it's a compatibility issue between Win7 RC and my IR receiver (in case, Zalman HD160, IRTrans).

The solution:

Map the IR codes to the keyboard equivalents for the skip buttons via the following changes in %ProgramFiles%\IRTrans\remotes\apps.cfg.

[APP]MEDIACENTER

NEXT [KEY]\CTRLF
PREV [KEY]\CTRLB

Having your OS isolated to a .vhd file has a number of advantages including but not limited to:
- easier to backup,
- multi-boot scenarios that are more isolated from each other,
- ability to trial new builds on your physical hardware without trashing your existing installation.

Whilst there's a variety of ways that boot from .vhd can be achieved, here's the steps I've used.  Note, I deliberately tried to avoid the installation GUI by doing part of the install via the WinPE command line.  It's possible to automate the remainer of the installation process via an unattend.xml file.  However, that's a potential topic for a future blog post.

1) Install the Windows AIK.

Windows® Automated Installation Kit (AIK) for Windows® 7 RC
https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=60a07e71-0acb-453a-8035-d30ead27ef72

2) Create bootable WinPE media (DVD or USB key) and include imagex.exe from the AIK on it.

Windows PE Walkthroughs
https://technet.microsoft.com/en-us/library/dd799278(WS.10).aspx

3) (optional) Include the install.wim from your desired Windows installation media on your WinPE media.  Alternatively, I suppose you can always refer to the original installatiom media instead.

4) Boot off your WinPE media then run the following DISKPART commands (possible to script this via DISKPART /s)

select disk 0
clean
create partition primary size=100
format quick fs=ntfs label=System
assign letter=s
active
create partition primary
format quick fs=ntfs label=Data
assign letter=d
create vdisk file=d:\win7rc.vhd type=fixed maximum=10240
attach vdisk
select disk 1
create partition primary
format quick fs=ntfs label=OS
assign letter=c
exit

5) Extract the Windows image to your .vhd and copy the necessary boot file to your system partition.

imagex /apply w7rc_x86.wim 5 c:
bcdboot c:\windows /s s:

*** START OF UPDATE 7-Aug-2009 ***

You *might* need the following also.  I don't recall doing this when I originally posted this however I needed this in a recent attempt. 

bcdedit /store drive:\boot\bcd /set {guid} device vhd=[locate]\win7rc.vhd

bcdedit /store drive:\boot\bcd /set {guid} osdevice vhd=[locate]\win7rc.vhd

Where drive: is the system partition.

*** END OF UPDATE 7-Aug-2009 *** 

exit 

Your system will reboot and proceed with installation.  For those that are keen to automate the remainder of the installation, here's a link to the relevant info:

Step-by-Step: Basic Windows Deployment for IT Professionals
https://technet.microsoft.com/en-us/library/dd349348(WS.10).aspx

After many hours of frustration, I located this great blog post that helped me to overcome the issue: 
https://blogs.msdn.com/sqlserverfaq/archive/2009/01/30/part-1-sql-server-2005-patch-fails-to-install-with-an-error-unable-to-install-windows-installer-msp-file.aspx

In my case, the missing .msi's were from SQL Developer edition.  The missing .msp's were from SQL SP2 & KB948109.

Here's the download location for SQL KB948109:
https://download.microsoft.com/download/7/c/7/7c7e394d-ddbf-4f2a-9e86-cf054e04931d/SQLServer2005-KB948109-x86-ENU.exe

Windows SharePoint Services 3.0 SP1 Developer Evaluation VPC Image
https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1beeac6f-2ea1-4769-9948-74a74bd604fa