November 2005 - Posts
At my company we've been working with SQL Server 2005, and in particular Analysis Services 2005, for the better part of a year. One of the new features of SSAS 2005 is Analysis Management Objects (AMO) - a managed class library for administering SSAS. AMO let's you define cubes, measures, and dimensions, process cubes, monitor traces, etc. It's very powerful, but we've struggled with it because through the entire beta program, it was virtually undocumented. The method and class names were listed in the documentation, but there were no descriptions for anything, nor was there a developer's guide for how to use the classes.
I'd always assumed that MS would flesh out the documentation by the time the product shipped. Apparently I was wrong. When I installed the RTM bits, I was surprised to find that the AMO documentation was still just a skeleton. For examples, look here
, or here
. Note the rather conspicuous blanks in virtually all of the description columns. I don't recall Microsoft ever shipping with such gaping holes in the documentation (at least, not in the .NET era). It's surprising that a company with the resources of Microsoft would do so.
To be fair, SSAS 2005 is a killer product - a huge leap forward in OLAP capabilities. Over the last year, I've really come to appreciate the power of OLAP and BI, and I suspect SSAS 2005 will bring OLAP much more into the mainstream (if you're not down with OLAP yet, I strongly recommend you take a look - it's hugely powerful stuff). Hopefully Microsoft will flesh out the documentation in the near future, to make it easier for ISVs to take advantage of.Update
- via Chris Webb
, Microsoft released a December update to the SQL Server 2005 Documentation (available here
). In this release they've started fleshing out the AMO documentation at last. It's not complete, but it's a step in the right direction.
One of my co-workers wanted to use a Windows Forms (2.0, in this case) TabControl as a way of swapping between sets of controls, but without display the actual tabs (controlling the switching entirely through code - a sort of swappable panel stack). After some fiddling around with various control settings, I found that the following seems to work:
- Set SizeMode to Fixed.
- Set ItemSize to 0,1. The control won't let you set a size of 0,0, but 0,1 seems to have the desired effect.
- Set Appearance to Buttons. This removes the tab control border.
And that's it. You can work with the tab pages easily in the designer, and use the TabControl properties to set the active tab at runtime. Update
- One limitation with this approach is that you can't easily change the background color of a tab control. So if you want, for example, a white background on your form, you're out of luck.
OK, this commentary is a little late, as plenty has been said about Live.com's initial lack of support for Firefox, and the problem has already been addressed. But dammit, I'm writing it anyway.
A while back Robert wrote
about an MS web site with no RSS feed. His stance?
Sorry, if you do a marketing site and you don't have an RSS feed today you should be fired.
Robert, my version of that comment is:
Sorry, if you do a web site and you don't support Firefox today, you should be fired. Especially
if the web site is targeted at tech types, which Live.com clearly is (at least initially). Why? Because the majority of influentials (the tech type influentials, anyway) run Firefox. In fact, virtually everyone even remotely technical that I know runs Firefox these days, including my boss' boss. Hell, you probably would have been better off ONLY supporting Firefox.
By only supporting IE initially, an entire group of users (and a rather important one) were disinterested right out of the gate, and getting them back on board is going to be extra work that shouldn't have been necessary.
I know that there are time and resource contraints on these projects, there's no feature in Live.com that should have been given a higher priority than Firefox support. I hope that the initial response from the blogosphere has made that clear for the future.
PS - I'm not actually in favor of anyone geting fired. Just, you know, a little dramatic exaggeration for effect. :)
The MSBuild team has released
a great new task, the AssemblyInfoTask. This task makes it easy to automatically update the assembly version numbers (both AssemblyVersion and AssemblyFileVersion, as well as other assembly information attributes) as part of your build process. Neil, on one of the PMs on the team, was nice enough to give me an early look version of the task, and it ROCKS. It's very flexible and easy to use - easily the best solution to the problem that I've found.
It took me a couple iterations to figure out the best way to incorporate it into our multi-project, multi-solution build, but with some tips from the MSBuild team, I got it working very cleanly and effectively. I'll post some info about how I did it in another blog post when I get a chance.
Oh, and they've released the source (with unit tests) as well. Very cool.