and now I joined AdCenter team since last Monday. over 2 days, I start feeling the differences between shrink wrapped product and on-line/service based team. and it makes me really excited. Hopefully, I can share my experience more on the way.

Please feel free to share your opinion on this PPT.

Catch your elusive bugs for external.pptx

the site name is http://www.debuglab.com. if you can read in Korean, come over there and check out. :)

IMHO, in many cases, we end up like building construction. I think that it is making sense to see an application as a building which has many internal components and aspects. it has fairly complex interdependency between each features and components. However one thing, which I could see in many chaotic or messy projects in engineering stand point, is that team was just focusing on how to build a building and forget about how each buildings in the over all blue print can work together.

We need to remember that we are building harmonic echo system as one big city than just one small application.

Adding to the my other article, I decided to list up some issuses from Beta1 to help you. I'll add information more and more. :)

Side by Side with VS7.x and VS8 Beta1

- Can't start asp.net debugging from VS7.x after installing VS8 Beta1

---------------------------
Microsoft Development Environment
---------------------------
Error while trying to run project: Unable to start debugging on the web server.

Click Help for more information.
---------------------------
OK   Help  
---------------------------

To do the auto-attaching, VS needs to talk to ASP.NET server(IIS). and for proper communication, matched version of ASPNET_ISAPI.dll should be registered or in use. if your server is Windows 2003, you can simply enable expected ISAP dll via IIS manager. for others, with IIS MMC, you can see ASP.NET tab on the virtual directory property and with that you can choose which ISAP will be used for the virtual directory.  

* thanks to Eric Sowell for reporting this issue.

Beta1 issues

- InterOp debugging with IJW Dll...

Because of the change in CLR design, if your project has IJW type managed dll which is C++ dll project built with /clr option, you may see hang or crash of your debuggee in InterOp debugging mode. the having dllmain is not allowed in /clr option.  current solution is to remove dllmain from the dll.

 - Managed code: when your worker thread is calling a method of UI control which is created by UI thread

If a worker thread is calling a method of UI control which is created by UI thread, you may see unexpected exception, which is not fired in normal execution mode, from UI thread when the call is made. it happens because Framework wants to let you know about the improper usage of UI control method. if there should be call from different thread, you need to use “.Invoke()” method to do it.  

Because this exception was not fired in VS7.x, this problem is easily expected from the case of migrating your code from VS7.x to VS8 beta1. you may see that your code is running fine without debugger, but under debugger, suddenly you see exceptions from UI thread. 

Well, as QA, whenever I heard their mythical belief on TDD, It makes me think why TDD is believed that much.

TDD, it sounds like very testing oriented. yes it is. I agree. and it is good approach. but is it all? and can it find all issues? I don't think so. but many of TDD believers want to believe that it is the final solution for everything.

IMHO, I think that it is just a trend which is good trend because it is focusing on the quality of code at the beginning. however, I don't think that it is everything or final thing which can solve every problem or prevent all issues from your code.

Adding to TDD, we need to understand the bigger picture. you should see the forest with trees, too. otherwise,you will lose harmony in your overall design and process.

- First Chance AV

- Unhandled Exception

- Userbreaks from System to process under debugger

- Appverifier(a tool which is part of Application Compatibility Toolset) notification via Int3(User break)

*ACT is downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyID=7fc46855-b8a4-46cd-a236-3159970fde94&DisplayLang=en

If you are using debug build for testing, you don't have to run your app under debugger in most of cases because your debug build may have enough asserts to show errors in early stage.

However for many QAs, using retail build which will be shipped to customer is more general. so monitoring app with Debugger and appverifier is very interesting ways to do.

For example, I saw fair amount of issues that the thread by RPC call crashes and the AV caught by RPC handler. so caller may handle it without actual crash but it ends up as random and catastropic errors. however under debugger, you can see this kind of issues. so you can easily figure out the real cause of random issues.

Adding to this, with various Appverifier options, you can expose memory and handle issues much easier by reducing the tolerance of memory/handle mis-usages. it is really useful to improve overal stability of your product.