I converted one ASP application to VB.Net using Microsoft ASP migration assistant utility. It was interesting
to see that the utility created all the required interop dlls for my unmanaged COM components. so I saved my time in
running tlbimp on each COM/EXE/DLL(unmanaged) or by using Visual studio. Cool Eh!!
I found one very interesting and quite unexplored issue (atleast i didnot get much on googling  ) that was                                                                                           my call from managed environment to unmanaged got failed for no obvious reason. Prima facie, I got feeling
that it happened due to some wrong marshalling of data which eventually proved true.

Let me staright jump into the issue by one example and explain its fix.

my backend (C++) has one API implementation something like this

CFoo::CreateMyList(

                        /*[in]*/   VARIANT*                     vSomeInVaiant,

                        /* [out] */ VARIANT*             pvSomeOutVariant,

                        /* [in] */ BOOL bSomeBoolean,

                         BOOL*                         bRetVal )

my default VB.Net code (after conversion) was something like this,

blnRetVal = CFoo.CreateMyList(vSomeInVaiant, vSomeOutVariant, bSomeBoolean)

this call was ending up in some unhandled exception resulting a crash in application. To dig more I disassembled
my interop. I found the intermediate signature in my interop dll something like this

.method public hidebysig newslot abstract virtual

        instance int32  CreateMyList([in] object  marshal( struct) vSomeInVaiant,

                                            [out] object&  marshal( struct) pvSomeOutVariant,

                                             [in] int32 bSomeBoolean,

                                             ) runtime managed internalcall

{

  .custom instance void [mscorlib]System.Runtime.InteropServices.DispIdAttribute::.ctor(int32) = ( 01 00 03 00 00 00 00 00 )

} // end of method IFoo:::CreateMyList

 when I hardcoded vSomeInVaiant in backend, everything worked fine. that meant the runtime marshaller is not able to do
 his job properly for in variant. I donot owe to whatever fix I am going to tell you now.

 I read it somewhere that by default VB.Net passes everything byref so I needed a way to pass it byVal. I found a workaround.
 you enclose your variant (I'm sorry Object in managed env.) inside parantheses. that will make your runtime to evaluate it
 as an expression first and then it will be forced to pass byVal.
 
 the next thing i did was
 
 blnRetVal = CFoo.CreateMyList((vSomeInVaiant), vSomeOutVariant, bSomeBoolean)
 
 believe me the trick worked seamlessly. I applied this trick everywhere in my project and it worked.
 
 To summarize it,
 
 pass in variant enclosed in parantheses
 pass out variant as it is
 pass in/out variant ( never tried so far  ), you need to let me know.
 
 I am open to more discussion on this. I will be obliged for any comment.

Reference: http://aspnettechstuffs.blogspot.com/
    

Writing alert in javascript and Response.Write in ASP to debug has been quite traditional. It just gives you an idea of the variable value runtime, what if

• You want to frequently change the variable’s value on runtime to do some test
• You want to step over or step into the function
• There is a big variant (ASP) or object/Array (Javascript) and you just don’t know its dimension but want to see it all

There could be tons of reasons, you need a good debugging tool. I here tell you some simple tricks to ease your job.

Prerequisite: Microsoft Visual Interdev (comes with Microsoft Visual Studio 6.0)

Debug Javascript: By default, javascript debugging is disabled in browser. To enable it, Open IE, Go to

 Tools -> Internet Options -> Advanced -> Browsing

1. Uncheck “Disable Script Debugging (Internet Explorer)”
2. Uncheck “Disable Script Debugging (Other)”
3. Check “Display a notification about every script error”
4. Uncheck “Show friendly HTTP Error Messages”

Now whichever line you want to start debugging with in Javascript, just write keyword debugger before that and run your page.

What will happen next: You will be prompted with an error (“A runtime error has been occurred, do you want to debug?”). Now click Yes and choose visual Interdev to debug. You will find interpreter halted on your “debugger” line. Now you can debug it as you debug any other language. Cool Eh!!!

Debug ASP: VBScript is generally preferred as server side language in ASP. Like javascript, vbscript debugging is by default off in IIS. To enable it, Type inetmgr on run prompt, (it will open your IIS (web server) config) Now browse to your app directory under IIS Right click Go To

 Properties -> Configuration -> Debugging

1. Check “Enable ASP server-side script debugging
2. Check “Enable ASP client-side script debugging

Now whichever line you want to start with, write keyword stop before that. Now run your page.

What will happen next: You will be prompted with an error (“A runtime error has been occurred, do you want to debug?”). Now click Yes and choose visual Interdev to debug and Bingo!!! You can debug your ASP code like anything.

Reference: http://aspnettechstuffs.blogspot.com/