NOTE: We are still working on this manual, so its incomplete and the information presented here is the subject to change.
So, there is actually a simple workflow that you should follow to release a build in public. Please find below the steps to go through as well as snippets where appropriate to provide visualization for better understanding.
I would recommend you to use Web Platform Installer to install some of the components as it provides you easy way to find and install distributives
for the list of pre-requisites.
Prepare Build Environment
Your build environment must satisfy the following requirements in order to be able to build source code:
Microsoft Visual Studio 2010
- SQL Server Express 2008 R2 (available via Web PI)
MySQL Connector/Net (available via Web PI)
Web Deployment Tool 2.1 without bundled SQL support (available via Web PI)
ResellerClub API (aka OrderBox, available via …)
SimpleDNS API (available via …)
WebsitePanel bits of the previous version (all three components Server, Enterprise Server and Web Portal)
Prepare bits of the previous version
Previous version bits (as zipped packages) can be downloaded from the project’s site at Codeplex. Once you have downloaded it, extract all packages in folder “C:\build\prev” as on the screenshot below, so you will have the
following folders structure:
Sync the source code tree (main)
To sync the source code tree create a destination folder first, for instance C:\build\rc (the intent is to keep the original path as short as possible). See the screenshot below.
Run TortoiseHg from command-line or PowerShell console (hg) and type “hg clone https://hg01.codeplex.com/websitepanel .\” to get the latest version from the project’s source control into the current folder. Please find below
a snip that shows how it would look like if this command is executed in C:\build\rc:
Update Setup.dll Sources
Open “WebsitePanel.Installer.sln” solution in Visual Studio.
Locate “WebsitePanel.Setup” project.
In “EnterpriseServer10.cs”, “Server10.cs” and “Portal10.cs” update “Update” method to include previous version. Use comma to separate multiple versions.
Alter Build Configuration Settings
Next you need to adjust build configuration settings to be reflect the changes you have made to your build environment. Launch your favorite XML editor and open C:\build\rc\WebsitePanel\build.xml file to edit.
The following settings are very important to adjust in order to correctly build distributives:
Elements related to the build version number are extremely important as they govern output during the build process what version number assign to the build. Here is the snippet from my test build configuration:
The following elements are also very important and we must ensure these values are relevant and point to the right locations
Here is the snippet from my test build configuration:
Build source code
This is the very first step you should do to emit distributives and upgrade packages for all components. So, to do this you launch the console (cmd.exe) or PowerShell and navigate to the following folder “C:\build\rc\WebsitePanel” and execute
deploy-debug.bat file from that location to initiate the build process:
Once the build has been finished, review carefully the output log and warnings (especially if you do build for the first time) as you may catch many really nasty issues in the log file either related to the build environment configuration,
scripts or missing files that might break the build.
The output log file (msbuild.log) can be found in this very same directory (C:\build\rc\WebsitePanel in my case) where you issued the build command. As you might have noticed from the previous snippet it took me about ~22 mins to execute
the build, so plan it carefully in advance.
Build the Installer (aka Configuration Studio)
Launch Visual Studio on the build machine and open WebsitePanel.Installer.sln solution. Once the solution file has been loaded, in Solution Explorer navigate to Setup project and do right-click to popup a dialog then choose “Properties…”
On the project properties page adjust the output name of MSI file for both configurations (Debug and Release) as appropriate:
Finally, you can do right-click on Setup project and issue Build command to create MSI distributive for WebsitePanel Configuration Studio:
NOTE: There is a hidden dependency on the project’s configuration either Debug or Release during the build time. This dependency affects which configuration file for WebsitePanel.Installer project
(either App.Debug.config or App.Release.config) is being placed into the output folder that Setup project is referencing to when builds an MSI distributive. So, please keep it in mind when build MSI distributive for production use.
Verify distributives content
After the build has completed, it pays off to manually verify the content of the output (Web.config, DLLs and content files) and ensure that it looks like you expected it to be. For instance, if you added a new project to the solution (eq.
service provider, utility library or anything that stands apart from existing projects) the output library should appear in corresponding distributive. So, make sure you have not missed anything, otherwise you will have to do an extra build round-trip
to fix the issue.
Upload files to CodePlex
Upload distributive files to CodePlex release page:
WebsitePanel Installer x.x
WebsitePanel Portal x.x
WebsitePanel Portal x.x Update
WebsitePanel Enterprise Server x.x
WebsitePanel Enterprise Server x.x Update
WebsitePanel Server x.x
WebsitePanel Server x.x Update
WebsitePanel Standalone x.x
Prepare Product Feed (Staging)
Note: if you uploaded WSP distributive files to CodePlex you could use CodePlex download links in product releases feed in the form:
Alternatively, for further ability to get analytics for downloads you could URL shortening services like bit.ly to shorten CodePlex links and then use them in the feed.
Make a local copy of ProductReleasesFeed.xml.
Once complete, open up ProductReleasesFeed.xml in Visual Studio or your favorite XML editor to adjust it to have a notion of new version for an every component. So, here is sample snippet for “StandaloneSetup” component (please pay
extreme attention to the areas I highlighted):
Here is sample snippet for “Portal” component (please pay extreme attention to the areas I highlighted):
Here is sample snippet for “Enterprise Server” component (please pay extreme attention to the areas I highlighted):
Here is sample snippet for “Server” component (please pay extreme attention to the areas I highlighted):
Here is sample snippet for “Installer” component (please pay extreme attention to the areas I highlighted):
Once finished with updating records for new version, create a copy of ProductReleasesFeed.xml and give it name ProductReleasesFeed.Beta.xml. The name matters, so please ensure that you gave correct name to the copy of the original file. Here
is the snippet from my test environment:
Verify Build via Beta Endpoint
Before going into production we must ensure the new version of the product behaves as expected and fulfills both upgrade version and fresh install scenarios without any errors. To do this, we should upload ProductReleasesFeed.Beta.xml created in the previous
step to Data folder on the project’s FTP share. Here is the snippet of the upload I did for my test environment:
When the file upload has been finished, ensure your Configuration Studio points to
http://www.websitepanel.net/Services/InstallerService-Beta.asmx and launch the program. Here is the snippet from my test environment:
Switch from Beta to Staging/Production
- Upload distributives via FTP…
- Update corresponding XML file…
- Update connection string in your WebsitePanel Configuration Studio
- Check that you can run fresh setup scenario without any issues;
- Check that you can run upgrade previous version scenario without any issues;