You got all excited with the SilverLight 1.0 RTM two days ago. Developing new, unseen cool RIAs. Converting already working applications and web sites to SilverLight. The usual state of affairs.
But stop and think for a moment. Have you tested your SilverLight dependent web site from Windows 2000? SilverLight requirements page says only v1.1 will be supported in future, whose RTM is about 1 year away. SilverLight 1.1 is forward compatible with v1.0, but hey, why should ‘I’ wait for v1.1 to be supported on Windows 2000.
Moreover, even if you try to install either version on Windows 2000, SxS fails and whines that it cannot find gdiplus.dll anywhere in the directories listed in %path%. When you manually copy gdiplus.dll safely to some accessible directory, you get the splash screen saying system configuration not supported.
Get your silverlight here. SilverLight 1.0 RTMed sometime yesterday.
An update to my tantrum is coming in a day or two. Stay tuned.
Aha! I forgot about one bug I encountered in the setup. It installed VSTO for Office 2003. I never had Office 2003 installed on it. The version of Office installed on my machine is Office 2007. Setup went ahead to install its VSTO version for Office 2003 and latter on complained that some functionality (actually most) will not work unless I installed Office 2003.
The question is: I didn’t have the right version in the first place, why install something that will not be supported? It should have detected the correct version.
I got my hands on VS Orcas March CTP yesterday and tried compiling CPlusPlusCodeProvider on which I have been working for five years. The code has compiled and worked flawlessly on all previous versions of VC++ [VC++ .Net to VC++ 2005], but now the new compiler reports an error on assignments lines involving auto_ptr objects.
Whenever I have tried to do <object> = new <type>( *other.<member> );, this new compiler whines. Compiler gives error about ambiguous assignment operators. Says it cannot choose between std::auto_ptr< Inner >::operator = ( const std::auto_ptr< Inner >& ) and std::auto_ptr_ref< Inner >::operator = ( const std::auto_ptr_ref< Inner >& ).
When I looked at the source for auto_ptr none of the classes had assignment operators defined, so the compiler is generating the default implementations. However, they both have a public constructor declared like this auto_ptr( T* ptr ) and auto_ptr_ref( T* ptr ).
I don’t remember if these converting constructors should cause any ambiguity. Converting constructor for auto_ptr is more qualified than auto_ptr_ref. It should be the one that handles this conversion, instead of creating any ambiguity.
As I remember the standard, you cannot create an instance of auto_ptr_ref directly, therefore, this constructor should not be declared public but protected. If declared public, it should have been declared explicit in the first place. Moreover, in the library shipping with VC++ 2005, auto_ptr does not derive from auto_ptr_ref. It has just a converting constructor.
I know VC++ team does not write the libraries themselves, instead it is Dinkumware that should be blamed, if it is really incorrect code.