Fast forward to today. My goal is relatively simple. I have a .NET application built with WinForms. I'd like the same type of ease of use in deploying this WinForm application to my users. I've done quite a bit of research on the best way to achieve this, but I haven't come up with the perfect solution yet. I'm close, but it's not buttoned up all of the way yet. For starters, I would highly recommend the following articles:

• Using Windows Forms Controls in Internet Explorer has a good overview of how to get a UserControl hosted in .NET
• Code Access Security and Distribution Features in .NET Enhance Client-Side Apps is a very complete article about hosting in IE. It talks about how to host an EXE, and gives some troubleshooting advice, including the fact that trying to host a WinForm (as opposed to a Control) will not work. :-(
• Deploy WinForms on the Web is a brief overview with some overlap, but has some good information.
• Security and Versioning Models in the Windows Forms Engine Help You Create and Deploy Smart Clients talks about how to deal with versioning, security, permissions, etc.

I wasn't able to find this nugget anywhere, though. If you want to call methods from your HTML page via (e.g.) JScript, you need to make your EXE assembly COM visible. The easiest way to do this is to select Properties for the EXE in the Project Manager, and press Assembly Information. There, you'll find a checkbox to make this assembly COM visible.

So far, I've been able to get a WinForm EXE hosted in IE, strong-name it and communicate from the web page to the control. I still have several items left to tackle, like wrapping everything up in a CAB file for easier deployment, and getting calls to other assemblies working. I'll comment on those as I get to them, but if you have any pointers on better ways to do any of this, I'm all ears!

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>