December 2004 - Posts
'Twas the night before Christmas,
and all through the house,
Not a creature was stirring,
Especially my hot water heater,
which decided to eat itself on Christmas Eve,
the day before we host Christmas dinner for the extended family.
Naturally.
Woo-hoo! A while back I was
complaining about generics not being CLS Compliant in .NET 2.0. Apparently the folks at MS have
changed their mind. Great news. [via
Richard Blewitt]
So far most of my time spent with Visual Studoi 2005 has been just playing around. That's changing - I'm ramping up to do some serious development, 05 style, and looking forward to it.
After installing the November CTP, I was pretty impressed. In particular, the documentation really seems to be coming together - the coverage on some features (like Web Parts) seems to be dramatically improved. My first little project - interacting with the Index Server OLEDB driver - wasn't too successful, but that was a bit of a sideline project, so it doesn't worry me too much.
One thing that does worry me - or rather, baffles me - is that "Add Web Reference" in Visual Studio STILL generates fields rather than properties on web service proxies. I mentioned this back in the May CTP timeframe, and it's still a problem. WSDL.EXE does the right thing, but not Visual Studio. My bug report on the topic was kind of blown-off, but I've reopened it.
The good news is that the generated proxies are now flagged as partial, which is a good thing.
UPDATE - Microsoft has now said that the "Add Web Reference" generating fields problem is fixed in beta 2. Not only that, but my bug report on the topic won "Bug of the Week". Woo-hoo!
After an interminable download, I finally installed the November CTP version of Visual Studio 2005. The first part of the install - the actual IDE - went without a hitch. The second part - MSDN Library - didn't go so well. It complained that Windows XP SP2 was a requirement for the MSDN Library install. Huh? Visual Studio doesn't require SP2, but the help does? Weird. I'm doing this all in a VM, so it's not really a problem to install SP2. It just seems like an odd requirement.
UPDATE - After installing SP2, the MSDN library wouldn't install - it complained about requiring the .NET Framework 2.0, and claimed it wasn't installed. I backed out the whole thing, installed SP2, then re-ran the entire Visual Studio install. It worked fine this time. God I love VMWare.
Imports System.ComponentModel
Public Enum Mode
Mode1
Mode2
End Enum
Public Class Class1
<DefaultValue(Mode.Mode1)> _
Dim Mode As Mode = Mode.Mode1
End Class
The resulting compiler error is "error BC30469: Reference to a non-shared member requires an object reference." It seems to be some sort of scoping confusion between the field and the enum (if you rename the field it works).
We're encountering this while adding a web reference to our web service (so the classes are auto-generated). It only fails in VB.NET - the equivalent code in C# works just fine.
Ever find yourself stuck on a Windows XP machine with only the built-in CD burning support but needing to burn an ISO image to CD? I did over the Thanksgiving. Luckily I ran across Burn-at-once. It's a nice, simple, free (donation-ware) tool that does the job nicely. Recommended.
Update - Geoff Appleby pointed out ISORecorder, which also looks quite nice (although it seems to require XP SP2).
The geek world is all a-flutter with the release of Google Suggest. My first reaction was "hey, neat". However, it quickly became clear that the hardcore tech stuff that I usually end up searching for (weird error messages that I'm trying to diagnose, or compiler errors, or things of that ilk) wasn't going to benefit much from the suggest feature. But hey, next time I'm looking for Paris Hilton's latest video, it'll be a snap.
My second reaction was - "View Source". The Javascript from the autocomplete function is easily viewed here.
My third reaction was - oh my god, do Google programmers actually code like this? Or do they run their Javascript through a Javascript obfuscator/compactifier/reformatter. Lord, I hope it's the latter.
Oh my god,
this is so my life.
According to this LadyBug post, Microsoft is not adding support for executing ASMX requests in an STA thread pool (ie the "ASPCOMPAT=TRUE" directive that is available for ASPX pages). This is something that I complained about long ago, and I'm very disappointed that it isn't being addressed in v2.0 of the framework.
There's huge amounts of business logic running out there as COM code (most of it written in VB6 and therefore apartment threaded), and people aren't going to be inclined to rewrite or port it all. A great way of exposing that logic is as a web service - in fact, Microsoft has a Patterns and Practices guide describing what they call the "Web Service Facade". But without STA support, scalability seriously suffers (to put it mildly), and Microsoft's recommended workaround of running the COM object as a COM+ library application is problematic - many COM objects don't play nice under COM+. I've had to hack around this limitation, and while its doable, it's not particularly elegent or fun, and you still take a performance hit.
Here's one of those fun issues that may or may not be a bug, depending on how you look at it.
With our product we provide an ActiveX control, written in VB6. Increasingly, customers having been writing rich client apps using .NET rather than VB6, and our ActiveX control has worked just fine in that environment. Until .NET 1.1 SP1 (and .NET 1.0 SP2), that is.
After installing 1.1 SP1, attempting to add the ActiveX control to a Windows Forms form in Visual Studio displayed the rather cryptic error "Invalid Primitive Type: System.Reflection.Missing. Only CLS compliant primitive types can be used. Consider using CodeObjectCreateExpression.". Huh?
Using the AxImp tool with the /source parameter provided a little more insight (although with an even more cryptic error - "The file can not be opened because it's in use by another process" - resulting in a truncated, incomplete .CS file). It turns out that some of the methods on our control contained non-variant optional arguments that don't define default values. For example, a method that results in this IDL:
HRESULT FunctionWithOptionalsNoVals([in, optional] double dVal, [out, retval] BSTR* );
would work in 1.1, but not 1.1 SP1.
A quick search of the MSKB revealed this article - apparently the original framework didn't properly support default values in ActiveX controls so they changed it. That change caused the framework to choke on our control.
So is this a bug? It turns out that's not a simple question to answer. In the sense that it broke previously functional code, yes it's a bug. But it raises a different question - was our method definition valid to begin with?
Unfortunately, the answer to that question seems to be indeterminate. Why? Because the OLE Automation spec describes the optional attribute as "valid only if the parameter is of type VARIANT or VARIANT*". But clearly that isn't true - VB6 (and most every other programming language) will happily let you create a non-variant optional argument, and its quite common to see that in type libraries. Nor is the defaultvalue attribute required by the compiler when the optional attribute is specified (and clearly VB6 will happily allow you to specify optional without defaultvalue, although the semantics of that is unclear).
Bug? If so, where? The COM spec? VB6? AxImp? No matter how you slice it, it's yucky. Fortunately, the fix is relatively simple - specify a default value, which we should have done originally anyway.
More Posts