Go Daddy Shared Web Hosting Challenges
Wednesday, December 10th 2008 - Here were my requirements for a web hosting company:
- Support for the Microsoft .NET 3.5 framework (LINQ to SQL, etc).
- SQL Server 2005 Database support.
- AJAX and Silverlight 2.0 support.
Go Daddy met these requirements but when I emailed their support and asked “what happens when my SQL Server database exceeds your stated maximum size of 200 MB?” they said “you can’t buy more disk space” and “you can’t upgrade to the next level of hosting packages”. You essentially have to pay for a virtual hosted environment which is basically my very own Windows 2003 Server that I am responsible for updating, configuring, etc. It’s not cheap!
I signed up for the deluxe hosting plan and I opted to use IIS7 as my web server. I also had the choice to use IIS6.
Changing Default Document Roots
I wanted my primary DNS domain (splitware.com) to point to the ‘splitware.com’ sub folder and my ‘live.splitware.com’ sub domain to point to the ‘live’ sub folder. Not too much to ask is it? Yeah right! Here is what I had to go through to make that happen:
- Change your primary domain to a non-existent domain. I changed mine to ‘root.splitware.com’. When I signed up with Go Daddy I used ‘splitware.com’ as my primary DNS domain. Perhaps if I had signed up using a non-existent domain in the first place this wouldn’t have been as painful. This change takes up to 48 hours for the DNS changes to take effect.
- I was then able to add the “real” ‘splitware.com’ domain and point its document root to the ‘splitware.com’ sub folder.
- I could also then add the ‘live.splitware.com’ sub domain under the ‘splitware.com’ domain and point its document root to the ‘live’ sub folder.
- I setup 2 virtual directories in IIS. Both of which were checked as “Set Application Root”.
- live – points to the ‘live’ sub folder.
- splitware.com – points to the ‘splitware.com’ sub folder.
Medium Trust Environment
In my web.config file I added the following markup so that I could ensure my web site works under Go Daddy’s medium trust environment:
<system.web>
<trust level="Medium"></trust>
</system.web>
Of course it didn’t. The site references a Splitware shared utilities assembly that I had to update to make it work in a medium trust environment. Here are some of the changes I had to make:
- Mark the assembly to allow partially trusted callers by adding the ‘AllowPartiallyTrustedCallers’ attribute to the assembyinfo.cs file.
[assembly: System.Security.AllowPartiallyTrustedCallers]
- I actually used reflection to pull the file version of the assembly in code which is a “no-no” in a medium trust environment.
- The shared assembly allows consumption of RSS 2.0 feeds. I read that web requests can only be made to the same domain in a medium trust environment but I haven’t had a chance to test that 100% yet.
WCF Service Settings Changes
Here are the changes I made to my web.config to get things working:
- First to enable the .svc extension add:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<baseAddressPrefixFilters>
<add prefix="http://live.splitware.com"></add>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
</system.serviceModel>
- To make sure the IIS uses the correct HTTP base address endpoint add:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<baseAddressPrefixFilters>
<add prefix="http://live.splitware.com"></add>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
</system.serviceModel>
- To allow larger datasets to be trasmitted via the WCF service add (YMMV):
<system.serviceModel>
<services>
<service behaviorConfiguration="SlideshowBehavior" name="Slideshow">
<endpoint address="" binding="basicHttpBinding" contract="Slideshow"
bindingConfiguration="BasicHttpBinding_Slideshow"></endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"></endpoint>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_Slideshow" closeTimeout="00:01:00" openTimeout="00:01:00"
receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard" maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647" messageEncoding="Text" textEncoding="utf-8"
transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="4096" maxNameTableCharCount="2147483647"></readerQuotas>
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""></transport>
<message clientCredentialType="UserName" algorithmSuite="Default"></message>
</security>
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
Database Upload
I downloaded and installed the Microsoft SQL Server Database Publishing Wizard to upload my database to Go Daddy. It has some cryptic settings but after a bit of trial and error I got things working. Here are some links that helped me:
- Microsoft SQL Server Database Publishing Wizard 1.1
- Go Daddy DPW Help
I had some issues trying to run the DPW on my Vista Ultimate 64-bit PC since I only have SQL Server 2005 Express installed. I had to download the Microsoft SQL Server 2005 Management Objects Collection which is located here:
- SQL Server 2005 Management Objects Collection 32-bit
- SQL Server 2005 Management Objects Collection 64-bit
Microsoft Sandcastle
Thursday, April 12th 2007 - Sandcastle is Microsoft's documentation compiler for managed class libraries.
They claim to use it for the .NET framework documentation (
MSDN) The product is still in BETA but I have used it on several occasions.
These are just some of the things I learned that helped me out along the way
when I was using it for the first time. Please note that I was using the
March 2007 CTP version.
The easiest way to get all the required components for Sandcastle (HTML Help Workshop and the Microsoft Help 2.0 SDK) is to install the
Visual Studio 2005 SDK 4.0 (February 2007).
The VSSDK does install an older version of Sandcastle so make sure you install the March 2007 CTP after installing the VSSDK.
I used the default installation folder when I installed the March 2007 CTP which is
'c:\Program Files\Sandcastle'. The installer sets the DXROOT environment variable to the
appropriate location so the older version of Sandcastle installed with the VSSDK is harmless.
This version of Sandcastle has no user interface. There are certainly some 3rd party developed front ends that you can find on the internet but I haven't tried any of them.
I used the DOS batch file approach. There is a sample batch file included with the Sandcastle install. It's a good place to start. Here are a few things that I had to change that I
didn't see documented.
- To change the contact information in the footer of all help pages (which defaults to Microsoft) edit the
'c:\Program Files\Sandcastle\Presentation\vs2005\Content\shared_content.xml' file with your favorite
XML or text editor. At the bottom of the XML file there are 2 "Microsoft" references you will need to change.
- If you are including more than one assembly in you documentation you will need to also change the sandcastle.config file located in the
'c:\Program Files\Sandcastle\Presentation\vs2005\Configuration' folder. By default Sandcastle looks for a single 'comments.xml'
file for your code documentation. Visual Studio 2005 typically generates a code documentation file for each assembly with the same name as
the assembly but with a .xml file extension (if you have that option enabled).
Search for 'comments.xml' in the sandcastle.config file and change it to use a wildcard like 'is*.xml'
(since I work for IntelliScience Corporation, all our assemblies are
prefixed with 'IS' and hence all the code documentation files that Visual Studio 2005 generates follow the is*.xml naming convention).
- To document your namespaces you must create a new XML file with the following structure:
<doc>
<members>
<member name="R:Project">
<summary>Your project summary goes here.</summary>
</member><member name="N:Your.Namespace.Goes.Here">
<summary>Your namespace summary goes here.</summary>
</member>
</members>
</doc>
Note: Make sure you name the namespace XML file appropriately so that Sandcastle can find it with the wildcard you specified in the sandcastle.config file.
Assembly Strong Name and Authenticode Signing
Tuesday, April 10th 2007 - I was always under the impression that strong name signing an assembly made it tamper proof.
Apparently it is impossible to make an assembly 100% tamper proof but strong name and Authenticode signing your assembly makes it near impossible to spoof.
Microsoft has authored an excellent
knowledgebase article on security in the Microsoft .NET 2.0 framework.
It is certainly worth reading. First things first though. You at least need a strong name key file or code signing certificate to sign the assembly so let's create one.
- One way to create a strong name key file is to use the sn.exe
utility that comes with Visual Studio 2005. By default it's in the
'%Program Files%\Microsoft Visual Studio 8\SDK\v2.0\Bin' folder. For example:
sn -k keypair.snk
This will generate a new RSACryptoServiceProvider key of the default size (a 1024-bit key is generated by default if you
have the Microsoft enhanced cryptographic provider installed; otherwise, a 512-bit key is generated) and write it to the
specified file. Both the public and private key are written to the file.
One way to create a code signing certificate is to use Microsoft's Certificate Services that is included with Microsoft's
Windows 2003 Server operating system.
I used a standalone certificate authority to generate a code signing certificate to sign my assemblies. Here are the steps I took:
- Navigate to the certificate services website using Internet Explorer
using a URL like
'http://win2k3srv/certsrv/' or 'http:///www.mydomain.com/certsrv'.
- Click the 'Request a certificate' link.
- Click the 'advanced certificate request' link.
- Click the 'Create and submit a request to this CA' link.
- Fill in all the fields in the 'Identifying Information' section. An example value for the name field is 'HHBJr Software' or 'IntelliScience Corporation Publisher'.
- Under the 'Type of Certificate Needed' section, select 'Code Signing Certificate'.
- Under the 'Key Options' section, leave all the defaults and select the 'Mark keys as exportable' check box.
- Under the 'Additional Options' section, leave all the defaults.
- Click the 'Submit' button.
Now, depending on how your certificate server is setup, you may have to have an administrator manually issue your certificate.
This can be done by using the 'Certificate Authority' utility in the 'Administrative Tools' program group on the Windows 2003 Server running certificate services.
Your certificate server may also be configured to automatically issue certificates when they are requested.
Once the certificate has been approved you will need to navigate back to the certificate services website using the same URL you requested your certificate from and
perform the following steps:
- Click the 'View the status of a pending certificate request' link.
- Click the 'Code Signing Certificate (Tuesday April 10th 2007 3:41:45 PM)' link.
- Click the 'Install this certificate' link to install the new certificate into your local computer's personal user's certificate store.
Now that the certificate is on your local machine you need to export it to use it for signing by performing the following steps:
(Note: These steps pertain to Windows XP SP2)
- Open the Microsoft Management Console by clicking the Windows 'Start' button, select the 'Run' menu option,
type 'mmc' and click 'OK'.
- Select the File, Add/Remove Snap-in menu option.
- Click the 'Add' button.
- Double click the Certificates entry, select the 'My user account' option, click the 'Finish' button, click the 'Close' button, and click the 'OK' button.
- Select the 'Certificates - Current User\Personal\Certificates' node, right click the new code signing certificate and select the 'All Tasks\Export...' menu option.
- Click the 'Next' button, select the 'Yes, export the private key' option, click the 'Next' button,
select the 'Personal Information Exchange - PKCS #12 (*.PFX)' option, click the 'Enable strong protection' check box,
click the 'Next' button, enter a password, confirm the password, select an export file name,
click the 'Next' button, and finally click the 'Finish' button.
Now your code signing certificate is ready to be used for signing.
- To strong name sign an assembly using Visual Studio 2005, open the Visual Studio 2005 solution explorer and
right click on the project file for the assembly you would like to sign and select 'Properties'.
Now select the 'Signing' tab and click the 'Sign the assembly' check box. Now select the key file (*.snk; *.pfx) you just created.
Note: If you select a .pfx file you will typically be prompted to enter the password you used during the certificate export process.
- To Authenticode sign an assembly, use the signtool.exe
utility that comes with Visual Studio 2005. By default it's in the
'%Program Files%\Microsoft Visual Studio 8\SDK\v2.0\Bin' folder.
This is certainly a must for applications that require elevated privileges to run properly on Windows Vista (however, this is apparently frowned upon by Microsoft).
The UAC prompt on Windows Vista for Authenticode signed assemblies is much more comforting then the default.
Also note that if you Authenticode sign your assemblies with a code signing certificate that you generated from a non-public certificate authority
(like VeriSign or Thawte), you will need to install your certificate authority's root certificate in the 'Trusted Root Certification Authorities' certificate
store on your local machine. To do this, navigate back to the certificate services website using the same URL where you requested
and downloaded your certificate from and perform the following simple steps:
- Click the 'Download a CA certificate, certificate chain, or CRL' link.
- Click the 'install this CA certificate chain' link.
Here is an example of a post build step for any assembly (assuming you substitute the pfx file name and password appropriately):
if "$(ConfigurationName)"=="Release" "c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\signtool.exe" sign /f $(ProjectDir)codesigningcert.pfx /p password $(ProjectDir)obj\$(ConfigurationName)\$(TargetName)$(TargetExt)