Monday, April 4, 2016

How To Solve Website Errors: 503 Service Temporarily Unavailable While Using WordPress With A Windows Shared Hosting Accounts

OK. This is an error that will likely have you pulling your hair out (if you have hair :-)). Here is the scenario.

I have several website hosting accounts. One of those accounts is a Windows account that allows me to host multiple website (Deluxe Shared Hosting). I have MANY domains hosted on this account and the websites are a mixture of Asp.Net MVC, Asp.Net Webforms (yes...webforms still work :-)) and WordPress sites. I noticed an odd thing happening with the WordPress sites. From time to time, as I was working in the WordPress admin area, the sites would produce a 503 Service Unavailable error. Sometimes I would be editing a menu and click the Update button and would get the error. Sometimes I would make a change and try to visit the site and get the error. Sometimes I would make a theme edit and save and get the error. It happened at very random moments when some action was initiated on the server.

Initially, I thought it was the version of PHP being used for the shared hosting account, so I upgraded to version 5.4 (I was using 5.2). Nope! That did NOT solve the problem at all. OK. What next? I upgraded WordPress for one of the accounts and started hammering it. No resolution! I kept getting the intermittent 503 errors. OK. So now what? Next I started hammering my Asp.Net MVC websites to try to produce the error. Nope! Couldn't reproduce the 503 error on ANY of those sites. I did the same for the Webforms sites and could not reproduce the 503 error there either. So I realized the first fact about this error -

FACT #1 - The 503 Service Temporarily Unavailable error was ONLY happening on my Windows hosted accounts that had WordPress installed in their folders.


After realizing fact #1, I started to pay very close attention to what was happening when the error happened. I realized something. The error seemed to happen when some function had to be performed - ie. when something had to be saved. It didn't seem to happen on navigation only actions like going from page to page. However, I did notice that if the error happened when I was trying to perform an action in the admin panel, then I would also get the error on the website if I tried to bring that up at that moment. It was like the server was hanging on any server function other than serving pages and would get "stuck" for a few moments. It felt like the request for processing was happening too fast for the server to handle it so it would produce an error. Basically, the request for a function was coming in and being routed, but the underlying process could not move quickly enough to process it.

Since Google is my friend, I started researching the issue. I saw that many people had the 503 error on shared hosting accounts, but no one had a real solution - including the hosting companies! Now I'm no server expert, but this isn't rocket science either. How hard can it be for some of these hosting companies to examine their logs and come up with a solution? Based on what I read, it must be VERY hard for them to do that! Anywho.....I decided to keep researching.

I came across this from Microsoft -

That article gave me some great information. Since the Windows Deluxe shared hosting account allowed me to interact with IIS in a very limited way, I decided to see if I could tweak some settings in their to prevent, help, solve or stop the 503 errors from continuing to happen. By the way, my hosting account is using IIS 7.0. The IIS area provided by the website was very limited. However, it did allow me to switch from Integrated to Classic Pipeline mode. In integrated mode, all requests are handled in a unified pipeline. However, in classic mode, there are two pipelines. One is for native code applications and one is for managed code applications. You can look up the differences between native code and managed code, but essentially managed code needs a runtime to handle its execution. Native code executes on a particular processor and it takes it's instructions on how to run from the OS it is running on.

So, here is what I did. The IIS 7.0 pipeline was set to Integrated mode. I changed this to Classic. Then I recycled the App Pool. The combination of these two things stopped the 503 errors from happening. This should help you get your websites running if you are on a Windows shared hosting account with limited access to IIS. Do not forget to recycle the app pool.

I will keep you updated on how this "fix" holds. I have tested it quite a bit and haven't received a 503 error again....YET :-)!

If you are experiencing this issue on your shared Windows hosting account with WordPress, try this and let me know how it works for you.


Kila Morton

Monday, January 5, 2015

How To Solve A Failure [INSTALL_FAILED_OLDER_SDK] When Using Android Studio

There are some times when even though you KNOW what to do, you forget some small detail that causes you to waste time. When building Android projects, you know to add the minimum supported version to your manifest file. Well when using Android Studio to create Android projects, Gradle ignores your manifest file. This can make for a little bit of head-scratching as you are trying to figure out why your newly created project isn't running as you expected.

If you get the following error:


Look build.gradle file for your app and change the following :

defaultConfig {
        applicationId "com.example.test.myapplication1"
        minSdkVersion 15
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"

Notice the highlight. You are going to change minSdkVersion to a version that matches your target test device. Issue solved!


Wednesday, December 31, 2014

How To Solve The Gradle DSL method not found: 'runProguard()' Error In Android Studio

After upgrading Android Studio, I ran into the following error -

Gradle DSL method not found: 'runProguard()'

This issue prevented the project from building. The solution was simple.
Do a search and replace.

Press Ctrl-F or Edit/Find and enter the letters runProguard into the search area.
Once you have found runProguard, you will see that it is listed in this procedure:

    buildTypes {
        release {
            runProguard false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), ''

Change the area I have highlighted to the following:

    buildTypes {
        release {
      minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), ''

That is it! That will solve the issue for you.
Wasn't that simple?
Here is a link to more information about why this is necessary.


Tuesday, December 2, 2014

Telerik's Just Decompile Offline Installer - Install JustDecompile Using Offline Installers

When .Net Reflector stopped being free, I think little birdies fell out of their nests all across the world. It was a great, free resource that was extremely useful at breaking apart a dll and allowing you to examine the guts. Although it was great, I was unwilling to shell out money for a paid version. I came across Telerik's JustDecompile, which, in my humble opinion, was better and free. That was many moons ago.

Fast forward to now and I have been using JustDecompile for years. However, I recently needed to install it on a "secure" system and found that the system's antivirus software was blocking the download. After dutiful searching to find an offline installer without the bootstrap stuff in Telerik's official JustDecompile download, I came across these links- 

These links will allow you to download JustDecompile if you are behind a firewall, unable to download exe files (the top link) or are in a situation where your antivirus software is screaming bloody murder. If it doesn't work for you, let me know. As a matter of fact, if it DOES work for you, let me know. I just like to know things.....Smooches!

Please note - you WILL need to create a free Telerik account, but why shouldn't you? It is free after all! JustEnjoy (play on words intended)!

Kila Morton

Tuesday, April 15, 2014

SOLVING - Could not load file or assembly or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

This is quite possibly one of the most frustrating errors you can get after upgrading a Nuget package in an Asp.Net MVC project. If this is the first time you are getting it, you are likely wondering what is and where is the assembly's manifest. Well fear not mighty soldier developers because I have the information that will help you get running in no time. First an explanation.

When you update an existing Nuget package, that update often has side effects. What does that mean? Well the packages you need often depend on other packages and when you run the Nuget update, the package you need might pull in updates to the packages IT needs even though you didn't specify that you wanted those other packages updated. That was a  mouthful! The dependencies being updated are side effects that you may or may not have planned for. On the surface, this seems like it might be OK. As long as the update happens to the files you need and things still build, you are fine. However, this isn't always the case. I'm going to run through what happens when an update happens.

For this example, I'm going to say we are updating Package A.
  1. Package A depends on Packages K, L and M.
  2. You already have a version of Packages K, L and M installed on your machine.
  3. Package A needs to upgrade Packages K, L and M BEFORE it can install itself.
  4. Package M is needed by Package R so it can't be uninstalled unless Package R is uninstalled.
  5. The update  uninstalls Package R, Package M, Package L and Package K and then installs the newer versions of each package it relies on and the version of Package R that works with Package M. 
  6. After the new versions of the dependencies have all been installed, Package A installs the latest version of itself.
  7. The package.config file is updated to include the version information for the newly installed files.
  8. The dependentAssembly area in the web.config file is updated to include dependency information and establish the backward capability of the newly updated files.

That is a lot! It is no wonder then that subtle side effects (aka hidden problems) can arise during that process. It is involved! If everything runs smoothly, all of the references are updated accordingly and all is right with the world. However, nothing ever runs smoothly does it?

Sometimes, due to all of the installing and uninstalling that takes place, the web.config file does NOT get updated by the Nuget Package you are running! This is where we run into errors like -

Could not load file or assembly 'Whatever.File' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Basically what this error SHOULD say is, "The web.config and package.config files do not match what is in the References folder"! There you have it - I have just rewritten a Microsoft error into something that a developer can actually understand? Did hell freeze over? Anyway, THAT is the problem. Sometimes when these packages uninstall and reinstall dependent packages, they do NOT update the packages.cofig and web.config accordingly. If the web.config references a version of the package that no longer exists, you  are going to get the "Could not load file or assembly...blah...blah....blah" error! So how do we solve this issue? The solution is easy.

  1. First, identify the file that the system is complaining about. It should be easy to do since the error message will list the file. For example, in the error below, Microsoft.Owin.Security.OAuth is the culprit. Could not load file or assembly 'Microsoft.Owin.Security.OAuth' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
  2. Second, go the References folder in your project and look for the file specified. When you find it, right click on it and select Properties (Alt-Enter) and look at the Version. Make a note of it. This is the actual version that is installed on your system.
  3. Third, go to the packages.config file and find the file. Check to see that the version number for the file listed in the packages.config matches the version you have specified in your References folder. 
  4. Fourth, check the web.config dependentassembly area for the file. The bindingDirect  areas has an oldVersion and newVersion area. The oldVersion area should end with a version number that is EQUAL to the version number you have installed and the newVersion number should MATCH what you have installed. For example, if you have version 5.0 of System.Web.Mvc, then your dependentAssembly and associated bindingRedirect should look like the following - 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />


 After you are done, clean and rebuild your project!
 Smile :-). Either your project built successfully and you can see your stuff or you have to repeat the steps above for another file until they have all been corrected.

Notice the highlighted areas. The newVersion is what is installed on your system. The oldVersion represents all of the versions the newVersion should be able to handle. If this web.config information is out of sync with the version information in your packages file and in your project, then you will get an error.

Please note - sometimes you have to manually change MORE than just one file to get things running. I have one project in which I had to update 5 references from different packages. Each situation will be different. If you get another file error, correct that one and keep going until you get a clean build and can run your project.

If you want, you can run the Nuget Package Manager and update the one package that is giving you an issue. However, sometimes that is not the best approach if that package  has dependent relationships. You can end up in what I call "Package DLL Hell" - where one package updates another package and each update keeps causing other side effects! Hey - wasn't this what we were supposed to be SAVED from using Nuget? LOL.....anywho....following the steps above will get you going!


Kila Morton

Friday, March 21, 2014

Solving System.InvalidCastException was unhandled by user code Message=[A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast ......

Recently, while upgrading an Asp.Net MVC 4 project someone created to an Asp.Net MVC 5 project, I ran across a great error. The error was this:

It was also bright and red!

Server Error in '/' Application.

[A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. Type A originates from 'System.Web.WebPages.Razor, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. Type B originates from 'System.Web.WebPages.Razor, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\bc28c2e0\1b833c84\assembly\dl3\efd960b2\2bccde4f_7f44cf01\System.Web.WebPages.Razor.dll'.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidCastException: [A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. Type A originates from 'System.Web.WebPages.Razor, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. Type B originates from 'System.Web.WebPages.Razor, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\bc28c2e0\1b833c84\assembly\dl3\efd960b2\2bccde4f_7f44cf01\System.Web.WebPages.Razor.dll'.

This error made me VERY unhappy.
However, the solution was VERY simple.
I just needed to tell the application which version to use.
Here are the steps I took.

1. Open the web.config file.
2. Scroll until you find the <assemblybinding> tag under <runtime>.
3. Add in the following dependent assembly information for the dll that is causing you problems. In my case, it was as follows:


<assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="" newVersion=""/>


4. Rebuild your project!

That is it! You should now see the fantastic work you have created after you build and Ctrl-F5. For all of you people out there still making projects with MVC 4 - JUST STOP! Back away slowly! MVC 5 is your friend!

Kila Morton

Wednesday, February 26, 2014

Solving "The term 'mongod' is not recognized as the name of a cmdlet, function, script file, or operable program.

Recently, while attempting to install an instance of MongoDB on a Windows Azure VM, I got a nice error.

mongod : The term 'mongod' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

I was in the bin directory of MongoDB at the command prompt and trying to run the database with the following statement -
mongod  --dbpath c:\MongoData\ --logpath C:\MongoLogs\mongolog.db

Ha! I forgot the .\!
mongod  --dbpath c:\MongoData\ --logpath C:\MongoLogs\mongolog.db

should have been
.\mongod  --dbpath c:\MongoData\ --logpath C:\MongoLogs\mongolog.db

I'm adding this here just in case anyone else is spacing out on a Wednesday wondering what in the world is going on when they are trying to run their Mongo databases.