Today I had to face this problem, with a module getting a 404 error while making a call to a controller in a module, that worked well on my development environment but not on an instance on Azure. If I called to the module method (that only had the HttpPost verb enabled) directly through the browser, what I noticed is that the 404 errors were "different" depending on the environment: one returned by IIS, not managed, a blue-white-red screen -this is where my module didn't work-, and one returned by ASP.net, managed, the typical 404 ASP.net message.

I was using the latest DNN 6.2 release, using the same 4.0 pipeline mode in the pool, the same file contents (including web.config and bin folders, etc.) so my first thought was that some assembly dependency was missing on the Azure instance. I installed MVC 2 runtime on Azure to test for a solution, without success. Installed MVC 3, with the same results.


To simplify the problem I built the "HelloWorldService" described on this Scott S. post (http://www.dotnetnuke.com/Resources/Blogs/EntryId/3327/Getting-Started-with-DotNetNuke-Services-Framework.aspx). On Dev environment I saw the "HelloWorld!" message, on Azure didn't, the same 404 IIS not managed message. Seems that by some reason the router was not being registered.

My surprise was that after installing the same "HelloWorldService" on other identical deployment on Azure, it worked. The only difference was the OS Family="1" (this is Windows Server 2008) and OS Family="2" (this is Windows Server 2008 R2). On the second one worked well.

After redeploying the device using OS Family="2", the problem dissapeared. I still think that is a dependency problem that is installed on 2008 R2 but not on 2008, not sure which one is.

I will create the issue on Gemini for further investigation.

---

David Rodriguez
DNN Cloud Team Lead Engineer | Microsoft Azure MVP | Microsoft Azure Insider / Advisor

please make sure you have the following 2 lines in your web.config
< add assembly="System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">< /add>
< add assembly="System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">< /add>
[Moderator edit: added blanks afer < for making lines visible.]

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US

Han,

Thank you for this web.config change - after I modified the web.config on our test platform as you suggested it all fired into life.

I had had it all working on a purely clean 6.2.3 DNN Install on my local computer - but as you pointed out - it works automatically out of the box using WebMatrix and IIS 7.5 Express on a .net 4.0 pipeline. However on our productions servers (also with DNN 6.2.x running IIS7 and .net 4.0 integrated pipelines) it always returned 404. Now it behaves as expected.

Scott
2ic