You had me at "Hello World" : ASP.Net

In God We Trust, Everybody Else Must Bring Data

HelloWorld — Mon, 25 Aug 2008 23:25:00 GMT

One day, I was presented with a problem, that the finalizer was not called during application pool recycle. I was busy, so I did not have chance to respond. Later on, I checked the code, it was modified to inherit from CriticalFinalizerObject class, and a comment saying that even though the class is inherited from CriticalFinalizerObject, the finalizer sometimes is not getting called. There was a logic in the finalizer that is often not got executed, the assumption was, the finalizer sometime was not called.

After digging the code, I discovered what was going on, above the logic that often not get executed, there was one line of code that close a FileStream object that is also a field of this class.

Managed code does not guarantee the order of the objects that are being garbage-collected, the finalizer may have accessed the garbage-collected objects. The code below the code that closes the FileStream object did not get executed if the FileStream has been garbage-collected.

It does not matter whether the class is inherited from CriticalFinalizerObject or not, the exception will give the impression that the finalizer was not called.

A quick look on ASP.Net Event Log shows ObjectDisposed exception whenever the logic is not called, a simple logging showed that the finalizer was always called. After isolating the issue, the fix is much simpler and guaranteed to work all the time.

Next time you hear about a problem, ask for data, profiler, repro steps. Just like a Test Manager that I knew said, ‘In God we trust, everybody else must bring data’.

Replacing ASMX Web Service with WCF Web Service

HelloWorld — Fri, 01 Aug 2008 22:38:10 GMT

I found a good article about replacing ASMX web wervice with WCF web service here (ASMX to WCF migration). Very cool, and my client application do not need to be recompiled.

Just one thing that I notice, I believe on step 3, instead of XmlSerializerAttribute it should be XmlSerializerFormat. Have fun!

Free Microsoft Press e-books (LINQ, ASP.Net AJAX, Silverlight)

HelloWorld — Thu, 03 Jan 2008 20:56:59 GMT

Microsoft is offering free e-books from Microsoft Press. The subjects that I have seen, LINQ, ASP.Net AJAX, and Silverlight 1.0. All of these are introduction e-books. Those are new cool technologies.

I would like to encourage you to take advantage of this free e-books here.

Using X86 COM interop with ASP.Net application in Windows x64

HelloWorld — Sat, 14 Jul 2007 05:51:00 GMT

It has been almost two months since my last post. It has been very busy here..

I got several good notes with one my previous post, about using x86 COM interop in x64 environment. I also had few questions about using x86 COM interop with ASP.Net application in the 64-bit Windows, such as Windows Server 2003 x64, or Vista x64.

Well, IIS in 64-bit Windows is also 64-bit and uses 64-bit version of .Net Framework. You might deployed your app as pre-compiled binaries or deploying the source, either way, the same error will be thrown in the app is using a 32-bit COM interop. The same error, Retrieving the COM class factory for component with CLSID {GUID HERE} failed due to the following error: 80040154.

If you deployed the ASP.Net source code to the server, ASP.Net does the compilation and it is more challenging to force ASP.Net to compile it as 32-bit application, as the IIS itself is 64-bit.

There is a way to do it, I don't say that this is ideal, but it works.

Configure IIS to run 32-bit ASP.Net application.
http://technet2.microsoft.com/WindowsServer/en/library/140077b8-8c96-49b0-be17-e47095983c2b1033.mspx?mfr=true
Register ASP.Net 32-bit with IIS.
Open a command-prompt window at %windows%\Microsoft.Net\Framework\v2.0.50727 and call aspnet_regiis -i.
Enable the 32-bit ASP.Net web service extension from IIS Service Manager (it is not automatically enabled from step 2).

Your ASP.Net application and your 32-bit COM interop now will work. The most ideal situation would be to get the 64-bit version of the COM interop.

Code Coverage result from ASP.Net project

HelloWorld — Sat, 06 May 2006 04:47:00 GMT

One thing that I love from Visual Studio 2005 unit testing is the code coverage result.

Obtaining code coverage result for ASP.Net projects it little bit tricky. From my experience, the requirements are:

IIS must be in the same box where you run your test assemblies.
You have to be the admin on that box, or if you are not, the web project must run with the same identity with you.
If you are using Remote Desktop to work on your server, make sure you are connected in the console mode (command line: mstsc /console /v:YourServerName)

To setup your test project to generate code, open your solution, click File>Add>Existing Web Site, select localhost, and add your site from there.

After your site is added, open the test run configuration, select Code Coverage option, and you will be able to see your ASP.Net project there, check the checkbox, and your test will generate code coverage result.

What will happen if you add a remote site instead of local site? You can add remote site only if the remote site has FrontPage Server extension installed and configured, but still, unless you are running the test in the same box with the IIS, you will not get the code coverage result.