Archives
-
Beware the perils of the VS2005 Development Web Server
One of the slick new features of Visual Studio 2005 is the ASP.NET Development Web Server - basically a scaled down web server that you can use during web application development instead of using IIS. I've been using it for a while, and it generally worked great. However, I recently tried to deploy my web app to an IIS server, and it suddenly stopped working. It turns out that the behavior of one the 3rd party ASP.NET server controls I was using changed when I switched to IIS. In this case, it was a chart control that suddenly stopped rendering its images correctly.
I haven't yet figured out the fundamental problem (the control wasn't designed for .NET 2.0, so it could be a version issue). I'm not bashing the Development Web Server - it's a very handy feature. The moral of the story is that the DWS is not IIS - don't be lulled into believe that they are interchangeable.
-
MFC Serialization behavior change between VC6 and VC7
We recently decided to port one of our existing MFC applications from VC6 to Visual Studio 2003 (VC7.1). This particular application uses MFC serialization to persist MFC object graphs to disk. After some minor changes to get the application to compile, things generally looked good. However, some additional testing discovered that the serialization process was resulting in corrupted files. After a little tracing, we found that the problematic code did something like this in one of the object's Serialize method:
...
VARIANT varValue;
GetBSTRVariantValue(&varValue);
ar << varValue.bstrVal;
The VC6 version of this code worked fine, but not the VC7 version. Stepping through the code in the debugger revealed the issue - the CArchive operator<< overload for the bool data type was being called, even though we were trying to serialize a BSTR. The result is that only the first byte of the string was being serialized - not good. Since this code hadn't changed for years, it was clearly due to a change in the compiler behavior, not the code behavior.
We went back to the VC6 version of the code and stepped through the code in the debugger. The result? It turns out that when serializing BSTRs in VC6, the CArchive operator<< overload for CString, rather the overload for bool. The VC6 compiler was generating an implicit conversion to CString during serialization. Making that conversion explict in the VC7 version of the code resolved the problem.
In fairness to the VC7 compiler, I believe it was generating a compiler warning for this code, which happened to be lost in some other warnings. Yet another reason to be sure that your code compiles without any warnings.
-
Cross page postbacks in ASP.NET 2.0
Brock Allen posted a couple of interesting tidbits about cross page postbacks in ASP.NET 2.0. He talks about two options for accessing data from the post source page - weakly typed access using the FindControl method and strongly-typed access using the the PreviousPage directive. The problem with the PreviousPage option comes if you want to post several different source pages to the same target page. There is, however, another alternative that isn't obvious and isn't really described much in the documentation - the Reference directive. Inserting this directive makes the specified page type accessible in the declaring page. Including the following in your post target page:
<%@ Reference Page="SourcePage.aspx" %>
types the PreviousPage property as Page but allows you to cast the it to the SourcePage_aspx type.
Some people don't like the cross-page posting feature, as it causes strong coupling between pages. I think it definitely has its uses (eliminating the need for the Server.Transfer abomination, for example). One way to address the strong coupling issue is to use interfaces instead of page types, in which case the Reference directive isn't needed. But it's handy to know about if you need it.
Incidentally, this directive is actually part of .NET 1.1, but I've never needed it with that version.. It seems to become more useful in .NET 2.0.
-
NTeam Press
I was rather surprised when I ran across this article on eWeek about the recently announced NTeam project. NTeam, intended as an open -source alternative to Microsoft's Team System platform, is currently about a vaporous as they come - the GotDotNet workspace was created just 3 days before the article was posted. Isn't it a little early for major press coverage? I mean, SourceForge and GotDotNet are littered with with literally thousands of ambitious projects that are now defunct.
Now, I'm not trying to pooh-pooh the project. I think it's a great concept, and the NTeam development team seems to be heavy into planning discussions already. As a small ISV who will likely be priced out of the Team System platform, I would certainly welcome an affordable (ok, free) alternative. But waiting until there's something concrete to talk about before running stories in trade journals seems appropriate here. NTeam got quite a bit of coverage in the blogosphere this week - could that be the reason that eWeek picked up on it? If so, I find that a little worrisome.
-
Development, Virtual Machines, and Winamp
I'm doing a lot of development on Visual Studio 2005 these days. I don't want to install VS2005 on my main machine, so I'm doing my development in a virtual machine (on VMWare). I like to listen to music while I code, and I use Winamp as my music player. I'm a long time Winamp user, and I still prefer it to WMP as a lean and mean music player (plus the FLAC support is better than WMP). But since I'm running Winamp on my main machine and developing in a VM, controlling the player is a bit disruptive - I end up bouncing in and out of the virtual machine to switch tracks.
Recently I discovered a great solution to this problem - WAWI - the Winamp Web Interface. It turns Winamp into a mini web server, and lets you control Winamp remotely over a web browser. Even better, it includes WAWITray - a small app that runs in the notification area and gives you control of a remote Winamp instance running WAWI. It's the perfect solution for me. Recommended.
-
Issues with new MSDN blogs UI
Over the weekend, blogs.msdn.com was upgraded to the latest CommunityServer bits. The new platform has all kinds of nifty new features, no doubt, but it's got some major UI annoyances - especially around comments. For example:
- The comment entry form is not longer displayed automatically at the bottom of the comment list - you need to click "post a comment" first. A little annoying - one extra click - but not a huge deal.
- When you do click "post a comment" and the comment entry for is displayed, it doesn't display the other comments while you're typing yours. That is a big deal - it makes it incredible difficult to comment on someone else's comment rather than the original post, or maintain a conversation in the comments. Bad, bad, change.
- As a NewsGator user, I'm used to clicking in on the "Comments" link that NewsGator adds to the bottom of the page to view the comments people have made to a post. The problem is, that link now takes you do the "post a comment page", not the "show existing comments" page. I'm not sure if this is a problem with the link NewsGator is generating (I haven't tried it in other aggregators), but 90% of the time it's not where I want to go. Of course, resolving the first two things on this list would resolve this issue as well.
- The comment entry form is not longer displayed automatically at the bottom of the comment list - you need to click "post a comment" first. A little annoying - one extra click - but not a huge deal.
-
Value
AMD Athlon 64 3000+ and motherboard: $179
512MB PC3200 memory: $30
Antec Sonata case: $80
Gigabyte Radeon 9550 video card: $66
Finally replacing your ancient 1.1 Ghz celeron machine: Priceless