MS KB list of apps (some by MS, including VS.NET) that have trouble under XP SP 2. Most of them are due to ports needing to be open in the built-in firewall setup that's on by default in SP2.

842242 - Some programs seem to stop working after you install Windows XP Service Pack 2

A buddy was asking me if you can use Platform Invoke (P-Invoke) from an asp.net page if you are not using a code-behind .cs file (as created by the vs.net app wizard)?

update -- got it working using a .cs code behind file

I couldn't get it working in only a .aspx file. I moved the p-invoke part to a .cs file that the page inherits from (dynamically compiles this file on demand). Here's how:

<%@ page language="c#" inherits="Interop" src="interop.cs" %%gt;

<% 

Response.Write( GetTicks() );

%%gt;

Note the inherits and src attributes in the page element. They point to the Interop class in the interop.cs file. This file sits in the same dir as the .aspx page on the web server. ASP.NET compiles this source file on the fly whenever a change is detected.

In interop.cs:

using System;

using System.Web;

using System.Web.UI;

using System.Reflection;



using System.Runtime.InteropServices;



public class Interop : Page 

{

	protected string Hello()

	{

		return "hello world" ;

	}



	protected ulong GetTicks()

	{

		return Win32.GetTickCount();

	}



}



public class Win32 

{

    [DllImport("kernel32.dll")]

    public static extern ulong GetTickCount();

}

Sweet! The tickcount is displayed on the page!!

---

I played around with it, but can't get it to work. I don't find anything quickly on the web that says you can not, but looks like the asp.net compiler doesn't like definitions of a class in the .aspx file (in the script terd).

You can definitely do this from a .cs file. The problem seems to be that do declare the Win32 API that you want to call, you end up declaring a class with the DllImport attribute. This works fine in .cs file, but not so much in a .aspx file in a script terd.

tried something like this, but can't get it to work:

<%@ Page language="c#" %>

<%@ import namespace="System.Runtime.InteropServices" %>



<% 



public class Win32 {

     [DllImport("kernel32.dll")]

     public static extern unsigned long GetTickCount();

};



int x = 1;



x = Win32.GetTickCount();



Response.Write( x );



%>

When cruising the net for an answer, came across this tip sheet all about p-invoke.

Platform Invoke Cheat Sheet

Working on an exception in a release build (WinForms) - how to best debug. Starting with this guy's take on debug symbols, the .ini file (which doesn't seem to work for me), and the MSDN Library.

Line numbers in stack trace.

What I've found so far:

• As with Win32 c++ code, you should generate .PDB symbol files for release builds. (project properties, generate debug info = true)
  
• Keep the PDB somewhere safe, where you can get back to the corresponding PDB for an exe out in production that's barfing.
  
• Also like Win32 code, the path to the .pdb is buried in the release EXE, so if it can be found at runtime, the symbols will be loaded. (but haven't figured how to point the debugger somewhere ELSE to find the PDB's. above article seems to say you can, but not HOW)
  
• Exception.StackTrace for release builds shows the stack with function names, but no line numbers. Cool feature: the existence of the .PDB in the same directory as EXE makes the stack trace automagically show line numbers!
  

Helpful links:

The INI file that sits with the EXE to turn on/off optmize and tracking. (I tried this, and didn't see any additional info - at least in the stack trace shown from the exception)

Enable JIT-attach debugger (2 different reg settings - for managed and unmanaged code)

Quite dated, but always good to hear what Eric Gunnerson has to say. Here, he compares a for loop in C# and C++ and notes there is very little difference in the compiled/executed code.

Re: C# compiler optimization

Not .NET related, but you can get Google search results for your domain with this web form.