I couldn't find anything to easily deploy my project with remote objects and a web.config to an ASP.NET virtual directory. I did see some documentation about Visual WebDeveloper, but I don't have that installed here. Perhaps I didn't install it when I installed VS.NET. Regardless, I really don't want to go back to install this since I'm not creating aspx pages and the like, but I do want to host my remoting objects in IIS (more details on this in a later post).

What I ended up doing was using the post-build Build Event to create events to copy the files over to the IIS directory, e.g.:

copy $(TargetDir)\*.* \inetpub\wwwroot\tipnet\bin
copy $(ProjectDir)\web.config \inetpub\wwwroot\tipnet

At least this way, my IIS files stay in sync with what I just compiled. It might not be the most beautiful thing ever, but it works.

<serverProviders>
   <formatter ref="binary" />
   <provider ref="wsdl" />
   <provider type="LoggingSink.ServerSinkLoggerProvider, LoggingSink" />
</serverProviders>

The ref syntax is a shorthand way of referencing the SdlChannelSink class. You could use the full type name by specifying the strong name of the SdlChannelSink class if you wish, but this is much easier.

<serverProviders>
	<provider type="LoggingSink.ServerSinkLoggerProvider, LoggingSink" />
	<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>

The problem here is that if ServerSinkLoggerProvider is a class that implements IServerChannelSink, the requestMsg parameter will be null in the ProcessMessage method. If you reverse the ordering of the 2 lines (i.e. put the formatter first), everything works fine.

This is by design, and due to the chaining of sinks that occurs in .NET Remoting. In the first case, the formatter has not yet deserialized the message, so we can't easily get to the IMessage that was passed to us. In the second case, the formatter takes care of the deserialization first, and can then pass the IMessage to the DispatchChannelSinks for further processing and investigation. The overview of .NET Remoting layers from MSDN is lacking a lot of detail, but hints at what causes the differences. Once I went back to Ingo Rammer's book, the technical reason for this behavior became obvious.

In .NET, you use Debug.WriteLine() to write ODS messages. This requires that your assemblies be built with DEBUG information to see the ODS messages. When working with ASP.NET pages, you have a some options to achieve this (the easiest couple are listed here):

1. Include the Debug attribute in the Page tag for the aspx page. For example:

   
   <%@ Page language="c#"  Debug="true"%>
   Testing:<br>
   <%
   System.Diagnostics.Debug.Write("Testing");
   %>
   

2. Include the debug attribute in the web.config file. For example, put this in a section underneath the <configuration> node. You can also do this by changing the config file when running the IIS Manager, selecting Properties for the Virtual Directory, going to the ASP.NET page, selecting Edit Configuration, going to the Application tab, and selecting Enable Debugging.

   
     <system.web>
       <compilation debug="true" defaultLanguage="c#" />
     </system.web>
   

This tool is listed as being freeware, but this is one instance where you get WAY more than you pay for.

Blog entry showing how to add Primary Keys to GetSchema in SqlClient - you could also extend this logic to add other database-specific metadata to any ADO.NET provider

Introduction to Visual Studio Data Designer Extensibility (DDEX) - this shows how you can add/customize functionality to the ServerExplorer in VS.NET.

By adding some simple code to your application, you can get SmartInspect to keep track of the logging in a meaningful way (by process, thread, method, session, etc.). Log events that are "children" of other events can be rolled up and grouped to allow you to focus precisely on what you're interested in. Logging can be done via file or TCP/IP, so you can coordinate log messages from multiple machines. Source code is included for the objects that SmartInspect uses, and you can extend the objects to do whatever you dream up (filter packets, automatically colorize certain events, etc.). You can even install Code Snippets/Templates into the IDE that you use. There are many more features than this, but those are the ones that really stood out for me.

I would highly recommend this product. This company has gone from nothing to having one of the most professional product experiences I have ever seen. They have a very complete, nice-looking, and easily navigable web site; incredibly great documentation (both in general and for developers); trial versions; multiple support options (forum, knowledge base, and email); a blog; walk through samples; and an extremely well-polished user interface. I wish all companies came on to the scene with such a thorough attention to detail.

In short, great job guys. I look forward to using this product more as time passes.

Let's say you have a setup like the following:

unit uExtenderTypes;

interface

type
  TType = class
  private
    FID: integer;
  public
    procedure Display;
    property ID: integer read FID write FID;
  end;

function GetType: TType;

implementation

uses
  SysUtils, Dialogs;

var
  gblType: TType = nil;

function GetType: TType;
begin
  if gblType = nil then
    gblType := TType.Create;
  Result := gblType;
end;

procedure TType.Display;
begin
  ShowMessage(IntToStr(ID));
end;

finalization
  if Assigned(gblType) then
    FreeAndNil(gblType);
end.

As time passes, you realise you want to only do the ShowMessage some of the time, and to do this you think a CanDisplay property would be perfect on the TType class. But remember, you can't change the interface section. You can add code like this to get things ready (only the changed section is listed here):

{$M+}
type
  TDerivedType = class(TType)
  private
    FCanDisplay: boolean;
  published
    property CanDisplay: boolean read FCanDisplay write FCanDisplay;
  end;
{$M-}

function GetType: TType;
begin
  if gblType = nil then
    gblType := TDerivedType.Create;
  Result := gblType;
end;

procedure TType.Display;
begin
  if (Self is TDerivedType) and TDerivedType(Self).CanDisplay then
    ShowMessage(IntToStr(ID));
end;

Note that the main changes are to add the new class - derived from the base class - in the implementation section; update the singleton TType return function; and update the Display method to conditionally display the message.

In order to set this property, we will rely on RTTI since callers outside the scope of this unit will have no idea what the TDerivedType is. The code for this would look similar to this:

procedure SetCanDisplay(t: TType; Value: boolean);
begin
  if IsPublishedProp(t, 'CanDisplay') then
    SetOrdProp(t, 'CanDisplay', ord(Value));
end;

procedure TForm3.btnDerivedClick(Sender: TObject);
var
  t: TType;
begin
  t := GetType;
  t.ID := 30;

  SetCanDisplay(t, true);
  try
    t.Display;
  finally
    SetCanDisplay(t, false);
  end;
end;

Obviously, this technique should only be used as a last result. However, it can get you out of that tight spot for a little while, and the changes are pretty well self-contained so you can do it right when building the next version.