When using a .NET client to communicate via HTTP, you may notice an HTTP header that looks like this:
Expect: 100-continue

Depending on how stringent the web server is, it may or may not be fine to have this extra header. If you must remove this header, it's very easy to do in .NET 2.0. Just include the following line of code in your application:

ServicePointManager.Expect100Continue = false;

I've been writing a .NET client application that must upload a file to a IBM WebSphere (Java) server. This journey was met with mis-steps all over the place. For starters, it looked like the WebClient class was what I wanted, but it turns out you can't POST both a file and HTML form variables. That meant that I needed to go to the low-level class, HttpWebRequest, to get this done. There is code on google that got me most of the way there, but the web server always ended up rejecting the submission with errors. To make matters worse, I don't own the web server, so support on exactly what was wrong was extremely limited.

Then I stumbled across a paper, Retrieving HTTP content in .NET by Rick Strahl. In that paper, Rick ends up writing a very nice wrapper class to deal with all of the details for you. I put together a test case to try this out, and the amount of code I had to write dropped from 123 lines down to 15. The new code even works with WebSphere. What's more, the wrapper class provides a very nice model for programming applications that need to communicate via HTTP. In my opinion, this is what Microsoft should have delivered with the framework, as opposed to making people write their own wrapper or find Rick's code (which was last updated in 2002, yet still works great).

I made 2 changes to Rick's base class:

• I changed the cMultiPartBoundary variable to look like this in order to give a unique boundary marker: string cMultiPartBoundary = "-----------------------------" + DateTime.Now.Ticks.ToString("x");
• In the method GetUrlStream, there is a place where the end boundary marker is written to the stream. However, according to the RFC on uploading files via POST, you need to have 2 trailing dashes to mark the last end. I added those dashes like this: this.oPostData.Write(Encoding.GetEncoding(1252).GetBytes( "--" + this.cMultiPartBoundary + "--\r\n" ) );

I am one happy camper. I've done this very thing with other web applications in Delphi before, and with the Indy components, it was very easy. Now with Rick's wrapper class, it's easy to do the same kind of thing in .NET.

Using LINQ, you can use variables for evaluation of the query. For example, the following query works just fine. It would also work if you used something like textBox1.Text instead of the variable s.

    string s = "Beverages";
    var results = from c in db.Categories
                  where c.CategoryName == s
                  select c.CategoryName;

I recently needed to monitor the HTTP traffic of an application that I wrote in order to debug why things were failing. Unfortunately, a simple proxy wouldn't work since the HTTPS traffic is encryped by SSL. This makes sense, since you really would hope that the data you send when surfing on a secure web page would be secure. I ended up solving this problem the same way you can solve every programming problem in the world: add a layer of indirection.

To start, I downloaded and installed the latest binaries of stunnel. Before starting, I modified the conf file to add the following entry:

[dor]
accept=localhost:8080
connect=www.MySuperSecureSite.com:443

Then, I installed tcpTrace and set things up to Listen on port 8079 and forward to localhost:8080. Lastly, in my application, I connected to http://localhost:8079/MyPath. This would eventually forward all of the traffic to the real destination, but I was able to spy on the details in tcpTrace since that was just HTTP traffic.

After doing this, I could see where things were malformed and clean my code up to submit things in the desired format.

In the README for the LINQ download, one big feature that was mentioned was the ability to use an external XML mapping file instead of attributes. This decouples the schema information from the code, which is good as a database schema tends to change over time, and you don't want to recompile every time your DBA decides to change something on you. The down side is that there isn't much information out there on how to get it to work. Hopefully, this entry fills that gap.

The first thing to note is the syntax of the XML mapping file. You can take a look at LINQ Preview\Docs\DLINQ Mapping Schema.xsd for more information on the mapping format, but here is a shortened extract from LINQ Preview\Data\samplemapping.xml to give you a look at a concrete implementation:

<?xml version="1.0" encoding="Windows-1252"?>
<Database Name="Northwind">
  <Table Name="Categories">
    <Type Name="Mapping.Category">
      <Column Name="CategoryID" Member="CategoryID" Storage="_CategoryID" DbType="Int NOT NULL IDENTITY" IsIdentity="True" IsAutoGen="True" />
      <Column Name="CategoryName" Member="CategoryName" Storage="_CategoryName" DbType="NVarChar(15) NOT NULL" />
      <Column Name="Description" Member="Description" Storage="_Description" DbType="NText" UpdateCheck="Never" />
      <Column Name="Picture" Member="Picture" Storage="_Picture" DbType="Image" UpdateCheck="Never" />
      <Association Name="FK_Products_Categories" Member="Products" Storage="_Products" ThisKey="CategoryID" OtherTable="Products" OtherKey="CategoryID" />
    </Type>
  </Table>
</Database>

The above code shows how the Categories table in the Northwind database could be mapped in an XML file. One thing of special note here is the Association element which will allow data hierarchies to be established, much like you can do in the DLINQ designer. You can generate this file by hand if you want, or you can use the new version of LINQ Preview\bin\sqlMetal.exe to generate the starting point for you. sqlMetal has a lot of options for you to look at, including a bunch to take save snapshots of database schema information to an xml file, and generate classes and XML mapping files from that saved XML file. A sample command would look like this:

sqlmetal /server:(local) /database:Northwind /map:nwindmapping.xml /namespace:Mapping /code:nwind.cs

The resulting nwind.cs file does not contain any attributes, as they are all stored in the xml file. To use this file, use code like this:

    XmlMappingSource mappingSource = XmlMappingSource.FromXml(File.ReadAllText("nwindmapping.xml"));
    Mapping.Northwind db = new Mapping.Northwind("Integrated Security=SSPI;database=northwind;server=(local)", mappingSource);
    var q = from c in db.Categories 
            select c.CategoryName;
    foreach (string s in q)
        listBox1.Items.Add(s);

While ActiveX has enjoyed a (mostly) deserved reputation for being ill-tempered and hard to work with, I've used it successfully for many years as a deployment vehicle for rich-client web applications that run inside the context of IE. I'll attribute most of that success to Delphi and ActiveForms since the most complicated plumbing is taken care of for me automatically, but still gives me the ability to override what I need. Special thanks should go to Lino Tadros and Steve Teixeira, former members of the Delphi R&D team, to allow this.

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!

LINQ is coming along nicely. This release is full of goodies. Among my favorites: join support, DLINQ graphical designer, LINQ over DataSet, multi-tier enhancements, and improved conflict resolution. But the thing I'm most excited about is the addition of XML mapping of elements! I attended a talk on ORM by Sean McCormack at the WI .NET User Group last night. He is an excellent speaker and spoke about DLINQ for a couple minutes, but hated the fact that it didn't have XML mapping. Maybe this will bring him around. It also looks like I'll be speaking at the WI .NET User Group on LINQ in the medium-term future. I'll be sure to post more about that event and more findings with LINQ. In the meantime, download the CTP now.

Here are my notes on hosting remote objects in .NET:

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.