January 2004 Blog Posts

Scott Watermasysk is Looking For the Best FTP Tool:

I am tired of holding my breath every time I have to FTP a couple of files to a live site. I would like to find the hands down best FTP tool out there. Free is nice, but not necessary.

Any suggestions?

I used to use SmartFTP when I wanted a GUI interface, and NcFTP the rest of the time. Since I reinstalled everything on my laptop recently, I've started using Internet Explorer as a GUI FTP client since I need this so infrequently and it does a good job without having to install any software. NcFTP is the client I use for scripting FTP; for example, it is what downloads the log files from this site each day as part of an automated task.

Richard Blewett writes about a custom channel sink to solve the problem where you get strange remoting error messages from a SerializationException about formatter version mismatches:

An unhandled exception of type 'System.Runtime.Serialization. SerializationException' occurred in mscorlib.dll

Additional information: BinaryFormatter Version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552.

I have to admit to being pretty mystified when I first came across this a few months ago having managed to steer clear of .NET remoting for the most part. This bit of code looks like a real boon for those moments when you run into this issue, which happen periodically as you maintain and update your remoting code.

A couple of weeks ago, Patrick Logan made reference to one of the PDC sessions on InfoPath saying that it was "Better than previous demonstrations and white papers...".

I blogged about this session at the time and I was less than impressed. However, during the last month or so, I've spent quite a bit of time with InfoPath trying to sort out how to fit it into the development landscape. It really is a powerful product with its rich support for real XML and it presents a very intuitive interface to form users once you've published a design. In fact, for one project that I'm involved with, we are actually going to use InfoPath as the main forms engine and our application will piece together new InfoPath forms on the server-side before shipping them down to clients over HTTP (see the InfoPath SDK for information about the make-up of InfoPath forms).

I can't help still feeling a little confused by the target user for InfoPath. It is pitched as a power user product rather than as a development tool - there aren't quite enough features for developers (though I have been impressed by a few of its subtleties) and the lack of support for embedding InfoPath forms in your own applications lets it down. It dreams of a world where web services and XML documents are ubiquitous within organisations and where it is important that power users be able to consume them in wonderful new ways not conceived of by their developers. I'm not sure we live there yet and whether we ever will remains to be seen.

The HTMLEditor control is a wrapper for MSHTML, the rendering portion of Internet Explorer (and IE's largest single component). It is written in C#. Unlike the .Net webbrowser control, this is not an ActiveX control. Rather it is an ActiveX Document. Even if you are not interestd in MSHTML, you may be interested in the HTMLEditor as an example of advanced .NET / COM interop. It's also not suitable for embedded web browsing - use the ActiveX for that. [via Jeff Block on DOTNET-CX]

In his post about the coming year, Tim Sneath gives his list of hurdles that he thinks must be addressed in order to achieve critical adoption of .NET:

  1. Reducing the learning curve for those new to the .NET world, by providing better help, more powerful wizards and tools and supporting the complete software development lifecycle.
  2. Making it easier for existing applications (particularly those written in ASP and Visual Basic "Classic") to be migrated across to the .NET world.
  3. Providing tools and guidance to IT Professionals to help them deploy and manage the .NET Framework and associated applications.

From my experience in 2003, the third one is the most important. There is already momentum behind teaching people about .NET (it started way before it was even fully released) and there is already effort in the migration area. What I found most, though, was that while developers are starting to come to terms with the new world of .NET, support staff and IT managers are still pretty much in the dark. Where IT departments might have developed pretty clear strategies for deploying and maintaining applications written in, say, ASP, when it comes to ASP.NET they are faced with new challenges that they are unprepared for. For example, how many people know the ins and outs of the files and folders that are written when an ASP.NET application is running. Have you seen the impact an incorrectly configured virus scan can have when all the temporary ASP.NET assemblies are continually scanned?

So I say a significant focus through 2004 should be pointed towards building documentation about best practices for the deployment and management of .NET (and in particular) ASP.NET applications for busy IT departments.

I've been making occasional posts to this blog for almost 2 years now - I started at the beginning of March 2002. At that time, I was about as enthused about the publishing capabilities of Radio as I probably am today with FrontPage 2003. Last year, I moved from Radio to my own somewhat simple blog engine written in .NET against a SQL Server database. Although what I have is much more basic than I could get using one of the more established .NET blogging engines, I learned a lot from the exercise of putting mine together. I notice that Don Box posted recently to the same effect, and I'm keen to see what insights Don brings as he goes through this process again.

My goal in keeping a blog was to help myself keep track of things I'd found and to be able to go back and search for them later, a sort of online notebook. From time to time now I can think "I know I read something about that before and I must have blogged it." Then I do a site search and it helps me find what I need. The fact that anyone else might be interested enough to read what I write was sort of a bonus really.

During the last 2 years, keeping track of the various blogs I read, and hence the use of an aggregator, has become an integral part of my professional life. Keeping up-to-date with what is new in the .NET development community has become much easier given the number of bloggers in this area. So much so, in fact, that I rarely drop into any NNTP news groups any longer. However, I frequently use Google Groups to search for people who might be having a particular problem I'm experiencing and, even better, to find others who have posted solutions. Whilst doing a normal web search on Google does sometimes find answers, there seems to be a much higher noise level than the results I get from Usenet searches. The problem, though, is that this suggests a potential imbalance.

If more and more people stop posting in news groups and start keeping blogs, and more and more people post answers either in comments or in their own blogs, then the usefulness of Google Groups looks set to diminish, at least for people in those communities. On the other hand, web searches won't quite be so specific. It would be nice if Google had a blogs tab, but how to identify a site that is actually a blog? Maybe they could index syndication feeds (RSS and the like) and somehow link these through the permalinks to the actual pages that contain the content, flagging these pages as suitable for the "blog search". Sure, there are a hell of a lot of people blogging about things that you probably don't want to search for, and lots of news sites that aren't really blogs, but it might be a nice experiment to see what value there could be in such a search tool.

I've updated my site so that I can publish general pages (non-blog posts) using FrontPage 2003. Looking back, I guess I used to look down on FrontPage users as people who really really couldn't manage HTML. In early versions, FrontPage used to do horrible things to perfectly good markup adding superfluous tags and generally messing up layouts.

A few weeks ago, I think following some posts mentioning FrontPage by Robert Scoble, I decided to take a look at the latest version that is part of Office System 2003.

Things sure seem different and while you can go in for the bells and whistles controls that add lots of extra files that do goodness knows what to the site, for editing HTML and laying out ASP.NET controls it does a good job. I particularly like the Dynamic Web Templates that allow you to create a template page and specify multiple areas that can be edited for page instances. These templates can include menu controls that automatically populate and update pages derived from them as you add new navigation links.

So last night I sat down and started mapping out the site in FrontPage and I finished it off today incorporating the previous content and deleting the stuff that had become too out of date and that I didn't have time to keep up. Since I only have a handful of pages, the whole process only took me a few hours including getting to grips with a few FrontPage foibles. Hopefully, it will be a lot easier to manage now.