A good while back, I commented about SVN Hosting through SVNRepository.com.  Well, I am still using SVN Repository but I came across another option, Assembla, last week and it deserves some attention.

Though many SVN repositories provide an accompanying Trac instance, that’s about all they do.  Frankly, that’s because that’s all they need to do. Assembla is the exception.  It takes hosting one step further.

Assembla is a complete software development tools package offering workspaces to thousands of teams for FREE.  The screenshot below gives you an idea of what is provided.  There’s everything from a SVN, Git or Mercurial repository to a project-specific Wiki and Chatroom.  If you look around, you will even find a Time Tracking application.

You may add team members to your Workspace with different privileges as well as establish security settings for non-member access.

Creating a space is low friction…just visit the home page, click "Create a new space" and follow the instructions.  The free account includes all of the core functionality and is limited to 200MB of storage.  If the free account doesn’t meet your needs, Assembla does also provide commercial and branded options which include further functionality and support in exchange for cash money.  You can find out more about Assembla plans on their tour page.

I recommend creating a free account and clicking through the tools as Assembla may be a good option for you. 

I am currently on the bench at work waiting for my next assignment to start up in a few days.  Rather than sit around, read blogs and listen to podcasts, I’m keeping myself busy by putting together the beginnings of a code library to be shared across our development team.  Yesterday I started the foundation.  I defined the framework, file system layout and basic namespace conventions.  I also created two class libraries and associated test projects to get the ball rolling.  I’m pleased with the way the common library is turning out.

Today, I refactored a bit and then focused on documentation.  Specifically, I generated help file documentation via the XMLSummary comments. I searched around and played with various utilities and ultimately decided on Sandcastle and Sandcastle Help File Builder.

Sandcastle - Documentation Compiler for Managed Class Libraries, created by Microsoft, produces accurate, MSDN style, comprehensive documentation by reflecting over the source assemblies and optionally integrating XML Documentation Comments. Sandcastle works with or without authored comments and supports .NET Framework 1.1, 2.0, 3.0 and 3.5.  Sandcastle is, however, a command line based tool which has no GUI front-end.  That’s where Sandcastle Help File Builder (SCHB) comes in.  SCHB provides a user interface (as well as command line based tools) to facilitate the building of help files in an automated fashion. Both applications may be found on Codeplex.

Sandcastle (really Sandcastle Help File Builder wrapped around Sandcastle) is easy to install and navigate and I was able to quickly integrate into the common libraries’ best practices.  Now when additional code (new library, class, method, etc) is appended to our common code repository, team members simply need to follow the overall folder structure, code library templates/namespaces and update the Help File Builder project which is now in place. 

Below are the instructions on how to extend the existing Help File Builder project.  These instructions will be share with my team members though they can easily be altered to create a help file from the ground up:

1. Download and install Sandcastle and Sandcastle Help File Builder from Codeplex.

2. Apply XML comments to your code base. 
3. Navigate to the Build Tab of your project’s properties and do the following:
   • Check XML documentation file
   • Set file name to bin\[mode]\assembly name.xml where [mode] is debug or release. Example: bin\release\MyCompany.Common.Serialization.xml
4. Compile your assemblies in release mode.   Note: I’m opting to only generate documentation per the assemblies/xml generated in release mode although it doesn’t have to be this way.
5. Run Sandcastle Help File Builder. The existing Sandcastle Help File Builder project can be found in the following location: MyCompany\Common\MyCompany.Common.shfb
6. Add your compiled assembly to the SCHB project:
   • Click Add > Browse to the libraries’ bin\Release > Select dll
   • After the assembly is added, the dll and xml files will be listed in the ‘Assemblies to Document’ list box. 
7. Document the assembly’s namespace by clicking on the ‘Namespaces’ button and editing the summary.
8. The MyCompany.Common.shfb project is already configured so there’s no need to change any of the project properties. For future reference, all non-default values are highlighted in bold font within the property list. This information is most obvious if you toggle the project properties to display Alphabetically rather than Categorized.

   Here’s a list of the settings which have been updated:

   • Help Title=MyCompany.Common Class Library
   • HtmlHelpName=MyCompany.Common
   • KeepLogFile=False
   • OutputPath=./
   • PresentationStyle=vs2005
   • SdkLinkType=Index
9. Generate the help file by clicking the Generate button in the toolbar.
10. View the help file by double-clicking the MyCompany/common/MyCompany.Common.chm or by opening the file via the SCHB Documentation/View help file menu option.

Again, I found the tools easy to use though I did encounter one gotcha. My file path included a folder named ".NET 3.5".  I found that Help File Builder didn’t like the naming convention.  Apparently the preceding "." caused the issue.  Once I renamed the folder to "NET 3.5" everything worked like a charm.

References:

• http://bloggingabout.net/blogs/jschreuder/archive/2007/03/20/using-sandcastle-is-increasingly-mature.aspx

For the first time in years, I needed to distribute my application to the end user’s machine via an online download.  To do this effectively and professionally, I, of course, needed an install package.  Over the year, I have used both Wise and InstallShield but they both cost money and I don’t recall them being all that easy to manage.  This was, however, years ago.  More recently I have, like many developers, used Windows Installer to generate MSIs for very simple (read: file copy) deployments. There’s nothing flexible or particularly pleasing about MSIs, but one can typically get them created with a few button clicks.  For the installation of internal applications, MSIs are more than tolerable, in my opinion.  Other than those options, I was quite ignorant on the subject of installers so I briefly evaluated three free candidates:

• Windows Installer XML (WiX) Toolset is a Microsoft open source project used to create the Office 2007 installer. WiX includes some advanced capabilities, but it has a steep learning curve even though the scripting language is XML-based.
• NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for Internet distribution. It has a rich feature list, a good set of online samples and a good community following.
• Inno Setup is another free, open source installer for Windows programs. First introduced in 1997, Inno Setup today rivals and even surpasses many commercial installers in feature set and stability.

Decision

After a quick review of each product, I opted to run with Inno Setup primarily because it had the ugliest website, all of their product award links are broken and it isn’t known by any acronym…yet.  Joking aside, I chose Jordan Russell’s Inno Setup because it met all of my requirements almost effortlessly.  Here’s the rundown of what I needed:

• Check for the .NET Framework and install if not found
• Check if Remote Registry is running and start if stopped.
• Check is UAC is enabled and provide user dialogue.
• Open website(s).
• Create quick launch, desktop, start icons.
• Read, update registry.
• Ask custom questions and manage response.
• Launch applications.
• Install silently.
• Create associated uninstaller.
• Show/acknowledge terms of service.
• Display readme.
• Customizable/skinnable display.  
• Etc

Additionally, Inno Setup it is such an easy tool to use and test and it has been around for a long while and has a great feature list:

• Support for all versions of Windows in use today: Vista, XP, 2008, 2003, 2000, Me, 98, 95, and NT 4.0. (No service packs are required.)
• Extensive support for installation of 64-bit applications on the 64-bit editions of Windows. Both the x64 and Itanium architectures are supported. (On the Itanium architecture, Service Pack 1 or later is required on Windows Server 2003 to install in 64-bit mode.)
• Supports creation of a single EXE to install your program for easy online distribution. Disk spanning is also supported.
• Standard Windows 2000/XP-style wizard interface.
• Customizable setup types, e.g. Full, Minimal, Custom.
• Complete uninstall capabilities.
• Installation of files:
  Includes integrated support for "deflate", bzip2, and 7-Zip LZMA file compression. The installer has the ability to compare file version info, replace in-use files, use shared file counting, register DLL/OCX’s and type libraries, and install fonts.
• Creation of shortcuts anywhere, including in the Start Menu and on the desktop.
• Creation of registry and .INI entries.
• Integrated Pascal scripting engine.
• Support for multilingual installs.
• Support for passworded and encrypted installs.
• Silent install and uninstall.
• Full source code is available (Borland Delphi 2.0-5.0).

Oh, and have I mentioned that it is free? 

Getting Started

The basic installer includes the Inno Setup Compiler, documentation and numerous samples.  If you want to get started quickly just download Inno Setup and review the sample scripts.  You’ll be creating your own installers in no time.  Alternatively, you could download/install the QuickStart Pack, but I honestly do not think it is necessary.

As I mentioned, a review/compilation of the samples can provide a quick, easy introduction into the impressive tool. All the examples are worth a look, but I feel it is necessary to give a few special mention:

• Example1.iss, Example2.iss and Example3.iss provide a great foundation as they demonstrate how to access the registry, add a desktop icon, include a readme file, etc, etc, etc.  
• If you are planning to do anything non-standard, play around with the CodeExample1.iss sample.  It essentially builds a basic setup, captures every installer event, includes custom functions, and demonstrates how to extract/expand files, display dialogues and issue before and after installer actions. 
• Finally, if you want to build custom pages, check out CodeDlg.iss which demonstrates how to build installer pages with custom questions and user input options.

My suggestion is to review the samples from within the Compiler.  The Compiler doesn’t have intellisense or anything, but it will obviously validate your script and call out where invalid syntax exists.  The Compiler also allows you to immediately "run" your installer script (by clicking on the green arrow button) or compile the script (by clicking on the fourth button from the left.) What the heck is that anyway?  The Compile IDE is a fancy notepad with options and actions.  It’s simple and I dig it.

Speaking of simple, here’s an example script.  You would have to build on its foundation if you wanted to do anything fancy, like read from the registry, but these few lines practically do it all.  They copy three files into the Program Files sub directory, displays a read me file and add an icon to the Start Menu.  And all the standard installer pages (splash, location, completion, etc) comes along for free — free meaning no effort and no code.

[Setup]
AppName=My Program
AppVerName=My Program version 1.5
DefaultDirName={pf}\My Program
DefaultGroupName=My Program
UninstallDisplayIcon={app}\MyProg.exe
Compression=lzma
SolidCompression=yes
OutputDir=userdocs:Inno Setup Examples Output

[Files]
Source: "MyProg.exe"; DestDir: "{app}"
Source: "MyProg.chm"; DestDir: "{app}"
Source: "Readme.txt"; DestDir: "{app}"; Flags: isreadme

[Icons]
Name: "{group}\My Program"; Filename: "{app}\MyProg.exe"

Extra Help

Finding the right syntax wasn’t always a breeze as everything isn’t covered in the samples.  With that said, the best online reference I found was an Inno Setup Manual hosted at AgentSoft.com. I can’t say I know the connection between AgentSoft and Inno but I’m still very happy to have found the reference.  I also found various "real world" installer scripts, like this one, posted online which really helped facilitate my ramp up.

.NET Framework Install Script

In my requirements list, I called out the need to check for the .NET Framework and install if it wasn’t found.  This functionality is a snap using Inno Setup — just be sure to use the Client Profile version of the installer.

[Files]
Source: "Executables\dotnetfx35setup.exe"; DestDir: "{tmp}"; Flags: deleteafterinstall

[Run]
Filename: {tmp}\dotnetfx35setup.exe; Parameters: "/Q /NORESTART"; Check: Is35FrameworkInstalled; Flags: runhidden shellexec waituntilterminated; StatusMsg: "This may forever."

[Code]
function Is35FrameworkInstalled():Boolean;
begin
    Result := not RegKeyExists(HKEY_LOCAL_MACHINE, ‘SOFTWARE\Microsoft\Net Framework Setup\NDP\v3.5′);
end;

Summary

I’ll keep it short and sweet: Inno Setup is one slick piece of software that made the dreaded task of creating a custom installer one heck of a lot easier than it could have been.  I’ve added Inno Setup to my toolbox and I highly suggest you do too.

I am releasing/distributing a Windows application and service in a couple weeks.  Both application use the .NET 3.5 Framework and are wrapped up in a custom installer.  Rather than having my installer prompt the user to download the .NET 3.5 framework installer, I’m packaging it up with my setup program.  Very simply, I check to see if the framework is installed and then I silently expand and install .NET 3.5 if applicable.  Currently I am using the "online" version of the .NET 3.5 Framework installer which weighs in at 2.7 MB. The arguably unnecessary file* completely bloats my setup package but the total size is, in my opinion, within reason.

You may have noticed that .NET Framework installs have gotten unacceptably large since the 1.0 days:

• .NET Framework 1.0 Redist: 19.7MB
• .NET Framework 1.1 Redist: 23.1MB
• .NET Framework 2.0 Redist: 22.4MB
• .NET Framework 3.0 Redist: 50.3MB ( x86 )
• .NET Framework 3.0 Redist: 90.1MB ( x64 )
• .NET Framework 3.5 Redist: 197.0MB

With consideration for the distribution size of the .NET 3.* releases, I should be thankful for the "online" version, but I’m not.  The "online" version is still too big especially if you know the ultra-slim Microsoft .NET Framework 3.5 Client Profile (BETA) weighs in at a mere 217 KB by containing only a subset of features (Common Language Runtime, ClickOnce, Windows Forms, Windows Presentation Foundation and Windows Communication Foundation) found in the full installation of the .NET Framework.

To add to my turmoil, I already know that both of my applications can use the bootstrapper as confirmed by selecting the "Client-only Framework subset" option within my project properties followed by a rebuild without warnings.

But, alas, the Client Profile installer is still in BETA with no published final release date other than "this summer."  The fact that it is still in BETA isn’t a deal breaker, but the BETA version does put the end user in a less-than-optimal place when it comes to managing future .NET Framework installs.  Per the documentation:

The Microsoft .NET Framework 3.5 SP1 Client (BETA) cannot be upgraded to the full .NET Framework. Users will need to uninstall the .NET Framework 3.5 SP1 Client (BETA) before installing .NET Framework 3.5 SP1. This will be corrected with the final release of .NET Framework 3.5 SP1.

That last sentence haunts me….

Maybe I’m being overly sensitive but I don’t want my users having to uninstall .NET if they choose/need to upgrade the .NET framework.  After all, the primary reason I am packaging up the .NET installer in the first place is for the sake of user convenience (and I suspect the majority of user’s aren’t all the tech-savvy.) 

I am left weighing my options.  I can either stick with the sub par "Online" version of the installer and cause .NET Framework upgrade grief for my user’s going forward OR I can improve the install experience of my product by distributing the Client Profile installer thus causing possible future inconvenience.  Right now, I am leaning towards the former option, but I could be steered otherwise — especially if the final version of the Client Profile installer were released, let’s say, this afternoon. 

I’m torn. What would you do? 

* Side note: I would love to exclude the .NET installer and only download it to the client’s machine and install if needed, but I feel my current approach is reasonable for now. That being said, I’m sure I will be messing around with this alternative option soon.  I’m currently using Inno Setup which can seemly do anything so there’s hope.

References:

1. .NET Framework Size - Christopher Painter
2. .NET 3.5 Framework Distribution Size - Rick Strahl
3. Visual Studio 2008 and .NET Framework 3.5 Service Pack 1 Beta - Scott Guthrie