The Mindful Coder

The first problem I hit when I installed WebOrb for .Net is that after what looked like a successful installation, the installer took me to what was supposed to be the management console for WebOrb. However, I got the following error instead:

—–

Server Error in Application “Default Web Site/WebOrb30”

Error Summary:

Http Error 500.23 – Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

I am working on Windows 7, so I am dealing with IIS7, not IIS6. I suspect you would face this issue on Windows Vista as well.

This happens because IIS7 hosts ASP.Net Applications using the ASP.NET Integrated mode by default. ASP.NET Integrated mode provides applications with a lot of very useful and efficiency-boosting features such as

• ASP.NET services such as Forms Authentication, URL Authorization, Output caching etc. are not available to all content types – where they were previously available only to ASP.NET content types such as .aspx pages.
• IIS7 has tighter unified configuration for IIS and ASP.NET modules/handlers.
• IIS’s modules were traditionally developed using the C++ server API and server extensions previously needed to be (not always but most of the time) developed in the ISAPI filter or extension extensibility mode. This is no longer the case and ASP.NET modules can now talk to the server pipeline directly.

A good detailed explanation of the ASP.NET integration architecture and advantages can be read here:

http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis7/

However, this also means that applications, such as WebOrb which were not developed for IIS7 in particular and don’t use ASP.NET Integrated mode will break as shown above.

The solution is easy enough however – we basically take the first option listed in the “Things you can try” section of the error page. However, because the option text is a little cryptic, I thought I would list the specific steps:

1. Open up command prompt in the administrative mode. (Make sure you are in admin mode else you will get an insufficient permissions error)
2. Go to C:\Windows\System32\inetsrv directory – assuming C:\Windows is your system root.
3. Type in
   appcmd migrate config "Default Web Site/weborb30”
   This is assuming you deployed WebOrb under “Default Web Site” during installation. If not, just replace it with the name of the website you put WebOrb under instead.

You should see something like this:

Go back to the page where you got the error and refresh. You should see the management console which looks like the screenshot below. If you have already closed the window, just browse to http://localhost/weborb30/ assuming that’s where you put WebOrb. Your URL should look similar.

We are set!

I have been exploring the best ways to enable remoting of a Flex / Papervision3D project we have been working on. My goals were to avoid XML based RPC communication as that would mean having to write XML-to-Object mappings on both the Flex and the ASP.Net end.

Several options emerged but in the end, WebOrb for .Net seemed to be the most endorsed and robust option. I think a lot of headache is pushed out of the way when you enable your Flex and ASP.Net teams to work with their own Object models without having to worry about a communication XML Schema. WebOrb also seems to be strongly endorsed by Adobe considering the remoting posts written by Adobe Engineers use WebOrb – at least for ASP.Net remoting. Of course if I was on a Java/J2EE backend, I would probably go for BlazeDS.

I work for a company that has built Flex applications from back in the day it was called Flash MX and we have always defined our own XML-based remoting mechanisms. In fact I think we built one of the first truly enterprise scale, fully Actionscript based applications when we put out IRIS Process Author.

The current project however – I can’t disclose the details as it would violate the NDA – will be our first project in which we take a different path – which will surely prove more efficient from the performance perspective, from the team separation perspective as well as the ease-of-use perspective.

I hope to write a series of posts on using WebOrb from the perspective of someone who has been used to doing things his own custom way before and is now using a standardized object-based remoting framework. I also hope to document any issues I come across that might prove helpful to others – especially considering I am on Windows 7 – uncharted territory for a lot of development tools.

If you know any other equally viable alternatives to WebOrb that I am not considering, please do let me know.