1. MSDN has a Remoting Example for hosting in IIS. The nice thing about the sample is that it shows how to use the BinaryFormatter for optimized communication over the HTTP channel.
2. When using the HttpChannel and BinaryFormatter combination, HTTP errors still come back as text. This leads to SerializationException errors on the client. Richard Blewett wrote a custom channel sink to fix the HttpChannel/BinaryFormatter/ASP.NET host bug.
3. The connectionStrings element in the web.config file is only valid when running ASP.NET 2.0. You can change your virtual directory to use ASP.NET 2.0 by running Internet Information Services, right-clicking on your virtual directory and selecting Properties. Then, go to the ASP.NET tab and select the 2.0 ASP.NET version in the combo box. You can also modify the web.config file here by pressing the Edit Configuration button.
4. Put the web.config file in the root of the virtual directory, and the assemblies in the bin subdirectory.
5. If you want to test the remote object, you can't just surf to the URI of the object (e.g. http://localhost/tipnet/MyAppServer.rem). If you do, you'll get a "Requested Service Not Found" error. You need to go to http://localhost/tipnet/MyAppServer.rem?wsdl instead. Be sure you explicitly specified the SdlChannelSink if you use other channel sinks.
6. Lastly, be careful when defining channel tags in web.config. Don't close XML elements out prematurely. It's easy to do, and hard to spot once you've done it.

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.