Archive for January 2005
Had a nice Zinger Dinner at KFC, Gulshan-e-Iqbal with Mr. Saqib Ilyas (INETA Pakistan Country Leader) and Mr. Hammad Rajjoub. Discussion Points: INETA Activities, INETA Event at NED the next day, and MSMQ + Windows Services.
I had spent the past 3 days trying to figure out why a Windows Service I had developed wasn't performing the task I expected it to, and since I couldn't figure out a way to debug a Windows Service, Mr Hammad (who also happens to be my Guru) was the one person I knew I could count on. :)
Windows Services are primarily background processes that keep running while you are free to do something else. If you want to perform a task that takes a lot of time in ASP.NET, a Windows Service is the best choice, since the ASP.NET page that initiated the (long running) process would probably timeout before the process ends. The ASP.NET page does not initiate or communicate directly with the Windows Service. It sends/places one or more Messages in a Queue (Microsoft Message Queueing) which is/are subsequently read by the Windows Service and the task is initiated.
Anyway, if you try to run or debug a Windows Service in Visual Studio.NET, the "Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command." message would appear (and for good reason too). As I mentioned before, Windows Services are applications that run in the background and cannot be run like other applications. Also, you cannot catch and display Exceptions in a Windows Service as you would in a typical Windows or Web App. In order to run a Windows Service, do the following:
1) Build your Windows Service Project in VS.NET to generate its exe.
2) Run the Visual Studio.NET 2003 Command Prompt; OR On the DOS prompt, go to C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 (Directory path may vary).
3) Use the following command to run your Windows Service. (Subsitute the items in [...] according to your local app.)
installutil C:\[YourAppPath]\[AppName]\[Debug Release]\[AppName].exe
You can view your Service running by Navigating to Start > Control Panel > Administrative Tools > Services.
To start your Service, right-click it and select Start from the context menu. Thats it !
So, How do you Debug a Windows Service? Very Simple.
a) Insert a breakpoint in your Windows Service app in VS.NET.
b) Build and run your service using Steps 1 to 3 above.
c) Select "Processes..." from the "Debug" Menu at the top. (The Processes Window would appear)
d) Locate your service in the list. (It would appear with the name you gave to the Service Project, NOT the one you specified in its property sheet.)
e) Click you Service in the list and click the "Attach" button.
To uninstall/unload the Windows Service, use the following command at the DOS prompt.
installutil /u C:\[YourAppPath]\[AppName]\[Debug Release]\[AppName].exe
As it turned out, my Windows Service wasn't running becoz I had used a "\" (backslash) in a value (without the escape character) that had been read from a config file. The 3 of us sat there glued to my laptop's screen, although I was distracted by the young ladies on the other table. :) Fortunatly for me, Hammad my man was there to save the day.
ActionScript 1.0 uses a C/C++ resembling syntax for the include directive for including .as files to the code, like
Whereas ActionScript 2.0 uses C#-resembling syntax as
import mx.remoting.NetServices // Use without the semi-colon
var s; // Declaration
s = new String(); // Object Instantiation
... some code ...
s = new Number(); // Yes, this was possible !
Now, with ActionScript 2.0, you can specify type in the declaration statement.
NOTE: Don't waste time trying to run ActionScript 1.0 code on Flash MX 2004. For more information on Flash Remoting with ActionScript 2.0, go to
However, as with every other Web Application development technology, the emphasis is on the generation of HTML that would be sent to the web browser. Each and every ASP.NET Server control needs to generate some HMTL code that would allow it to be visible when the page is rendered. This holds true even for web apps communicating with XML web services. The bottomline is, HTML is needed to format and display any information that needs to be displayed, and for every postback that occurs on a typical web page, a lot of unchanged HTML is again loaded into the browser.
Enter Flash Remoting Component for .NET. This component would completely change how GUIs are developed for Web Applications in future by allowing Flash movies loaded into the browser only once to communicate with .NET Assemblies and web services without having to load again when information needs to be sent back to the page (postback). Also, in contrast with ASP.NET Server components where the developer has to think about style (GUI) as well as behavior (functionaliy), Flash Components require less attention in terms of the GUI and developers can focus more on the behavior. Recent examples include the GUI of www.myWallop.com where the whole application is Flash-based as opposed to the typical HTML web pages we are accustomed to seeing.
Their TTS, known as RealSpeak, is excellent. In addition to supporting multiple languages, it provides very natural sounding Speech in American, British, Australian, and Indian accents. They also have a web-based demo app. Check it out !