November 2002 Blog Posts

ILLINK -- Microsoft (R) .NET Framework IL Linker

The ILLINK utility is intended for linking multiple managed modules or assemblies into a single module or assembly. The utility relies on round-tripping using the ILASM and ILDASM utilities and is not able to link the modules containing embedded native code. Only pure-IL modules, such as those generated by C#, VB.NET or ILASM compilers, can be linked.

The general principle of the ILLINK functioning is the corrective round-tripping. The modules being linked are disassembled into IL Assembly language source text, the text is processed and then re-assembled into a single module.

Unhandled exception handling

For a "server in a closet", you can simply turn off the default debugger
dialog.  You can do this on a Machine-wide, User-wide, or process-wide
basis.  The machine-wide and user-wide settings are controlled by:

        HKLM\Software\Microsoft\COMPlus\DbgJitDebugLaunchSetting
        HKCU\Software\Microsoft\COMPlus\DbgJitDebugLanuchSetting

and the process wide one by the environment variable:

        COMPLUS_DbgJitDebugLaunchSetting

The values here are:
        0 - ask
        1 - never attach a debugger
        2 - always attach a debugger

Set it to 1, and there will be no system-provided dialog.

Also this:

Personally, I prefer to limit the scope of this kind of setting to per-process (specifically, mine :-), so I go with the environment variable approach. The only glitch is that, there's not managed way to adjust process-wide environment variables (it violates the appdomain isolation story), so you have to resort to p/invoke. But if you're writing a service, then you're going to have the necessary perms, and this kind of setting makes sense anyways.

\// Declare this somewhere:
[DllImport("kernel32.dll")]
static extern bool SetEnvironmentVariable(string varName, string varValue);

\// Do something like this during the service's initial startup:
SetEnvironmentVariable("COMPLUS_DbgJitDebugLaunchSetting", "1");
AppDomain.CurrentDomain.UnhandledException +=
      new UnhandledExceptionEventHandler(OnUnhandledException);

Apparently there is a bug in TLBIMP which means that, under certain circumstances, the interop DLL that it generates won't support events properly. This is probably a well-known issue that everyone except me knows about, but I didn't find too much about it on Google.

For example, capturing events from Windows Messenger doesn't work by default and you need to take the following steps:

  1. Use Tlbimp.exe to generate a Messenger interop assembly (this is located in C:\Program Files\Messenger by default):

    tlbimp msmgs.exe /out:Messenger.dll
    
  2. Disassemble the interop assembly, and then save it as an IL file:
    ildasm /text Messenger.dll /out:Messenger.il
    
  3. Open the IL file in any text editor, and then change the following line (mark the class as public instead of private):
    .class private auto ansi sealed DMsgrObjectEvents_SinkHelper
    
    to
    .class public auto ansi sealed DMsgrObjectEvents_SinkHelper
    
    and just below that
    .class private auto ansi sealed DMsgrObjectEvents_EventProvider
    
    to
    .class public auto ansi sealed DMsgrObjectEvents_EventProvider
    
  4. Compile the IL file:
    ilasm /dll Messenger.il
    
  5. This DLL is now ready to be referenced in a project.

Good Books [Joel on Software]:

A few months ago I read The Goal, by Eliyahu M. Goldratt, mainly because it has become extremely popular at business schools, and it looked fun. It was interesting, and fun. I didn't understand how the book's theory, called the Theory of Constraints, could possibly be applied to software development, but it was still interesting enough, and I figured if I ever found myself running a factory again, it would be helpful.

Last week I discovered his newer book, Critical Chain. This book applies the Theory of Constraints, introduced in The Goal, to project management, and it seems to really make sense.

I first read The Goal more than 10 years ago when it was recommended to me as a must read by my boss at the time. I was working in the design department of a factory and it seemed to have much more relevance to me then than now. I read it again a few months ago and was astonished at how much more I got out of it. I think a lot went over my head all those years ago. I also read the sequel, It's Not Luck where Goldratt expands upon his theory and applies it more to everyday life. It's the kind of book you read over and over squeezing out a little more understanding each time. Heartily recommended. I think I'll have to get hold of Critical Chain - this sounds good too.

Mike Woodring [DOTNET-CLR] on specifying GAC assemblies in .config files:

...a change made during the beta timeframe started requiring you to use a fully specified strong name for such assemblies in your config files. So (for example) something like <channel type="System.Runtime.Remoting.HttpChannel, System.Runtime.Remoting" /> no longer cuts it; you need to use <channel type="System.Runtime.Remoting.HttpChannel, System.Runtime.Remoting, Version=blah, Culture=neutral, PublicKeyToken=blah" />

This doesn't seem to be particularly well documented in MSDN. The examples I've recently been looking at relating to ASP.NET don't include the version, culture, and publickeytoken attributes and so this explains the difficulties I was having.

I'm not sure if there is a better method, but it seems like the way to lookup the values for version, etc. is to browse to C:\WINDOWS\assembly where you can see the assemblies in the GAC together with their attributes.

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

This guide presents a practical, scenario driven approach to designing and building secure ASP.NET applications for Windows 2000 and version 1.0 of the .NET Framework. It focuses on the key elements of authentication, authorization, and secure communication within and across the tiers of distributed .NET Web applications.

Alex Kipman describes the workaround to the 64kb locking issue with VS.NET projects. [ADVANCED-DOTNET]

[HttpHandler]
Q308001 - HOW TO: Create an ASP.NET HTTP Handler Using Visual C# .NET
Q307997 - HOW TO: Create an ASP.NET HTTP Handler Using Visual Basic .NET

[HttpModule]
Q307996 - HOW TO: Create an ASP.NET HTTP Module Using Visual C# .NET
Q308000 - HOW TO: Create an ASP.NET HTTP Module Using Visual Basic .NET

Enterprise Services FAQ This is a collection of frequently asked questions and answers obtained from newsgroups and mailing lists related to Enterprise Services.

Ethereal is a free network protocol analyzer for Unix and Windows. It allows you to examine data from a live network or from a capture file on disk. You can interactively browse the capture data, viewing summary and detail information for each packet. Ethereal has several powerful features, including a rich display filter language and the ability to view the reconstructed stream of a TCP session.

Andy McMullan's .NET FAQ

"This FAQ tries to answer some commonly asked questions about the fundamentals of the .NET Framework. By fundamentals I mean the nuts and bolts of how the .NET Framework works at a low level - topics like assemblies, garbage collection, security, interop with COM, and remoting. The most commonly-used parts of the class library are also covered. Other aspects of the .NET Framework such as ASP.NET, ADO.NET and WinForms are not covered."

After a 30 day evaluation, I purchased the Professional version of Enterprise Architect today. It seems to be a pretty easy to use UML diagramming tool and, best of all, sold at a very reasonable price (desktop version is US$95, professional version is US$149).

I plumped for the Professional version in the end because it includes code reading and writing. I sort of shy away from such things - I prefer to use UML for the design and then let people make their own way through writing the code - but I figured it might come in useful in future and this version was still well within my budget.

The Law of Leaky Abstractions. [Joel on Software]

"Ten years ago, we might have imagined that new programming paradigms would have made programming easier by now."  "...when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks."

Further to the text I quoted from Drew Marsh the other day about Response.End(), and an e-mail I received from a friend entitled "It's not just Response.End()...!", here's the full knowledge base article:

Q312629 - PRB: ThreadAbortException Occurs If You Use Response.End, Response.Redirect, or Server.Transfer

From Digging into SOAP Headers with the .NET Framework:

If you don't want to disable the ASP.NET auto-generated WSDL from your web service (so that you can replace it with a static document):

...you might want to disable the ?WSDL functionality for your Web service. You can do this by manipulating the web.config file to remove the "Documentation" protocol for Web services. The crucial part of the web.config that removes WSDL documentation is shown below:

<system.web>
  <webServices>
    <protocols>
      <remove name="Documentation"/>
    </protocols>
  </webServices>
</system.web>
.NET Server and Application Pool Identity: useful post from Keith Brown summarising the differences between the built-in identities: System, Network Service, and Local Service.

Q317012 - INFO: Process and Request Identity in ASP.NET

This article outlines the access rights that are granted to the default process account and describes some situations in which these rights may be too restrictive for certain tasks.

Included is a list of the default permissions assigned to the ASPNET account.

.NET Delegates: A C# Bedtime Story

Once upon a time, in a strange land south of here, there was a worker named Peter. He was a diligent worker who would readily accept requests from his boss. However, his boss was a mean, untrusting man who insisted on steady progress reports... [Chris Sells]

Q317129 - PRB: The Common Language Runtime Does Not Support Type 'internal virtual' Methods

"Status: This behavior is by design."

Apparently not. Eric Gunnerson [DOTNET-CX]:

In 1.1, we've changed the runtime behavior [...] and removed the warning.

Drew Marsh on Response.End() [DOTNET-WEB]

That's how it terminates the thread. If you need to watch for exceptions on the other code around the call to Response.End, you need to add a special catch block that handles ThreadAbortException explicitly and just rethrows it. ...here's the IL...