June 2004 - Posts

• VSS - where are we going?

  A recently published article on MSDN talks about the planned roadmap for VSS. I've read through it eagerly, looking for a feature I missed long ago, but to no avail. The feature I'm talking about is the (as called in ClearCase terminology) “Streaming” concept. Imagine the following situation (which I believe you are all familiar with): Two developers working on the same project. One of them assigned a feature request that should take 4 days. At the end of day 1, the feature is not ready yet, and the application cannot be built with what was written already. Well, our developer want to go home, he Checks-In all the files he has been working on, and leave. The next day, the second developer comes, and get the latest version from VSS. But then - SURPRISE! - the application cannot be built! So what should the first developer do? Should he not check in the file? but then he might lose it, since it's stored only on his local machine. Should he check in the file? He will then break the whole application! The “Streaming” concept says that the application does not have only single version, as in VSS, but as many versions as needed. For example - the first developer will check in the file, but not to the main app version, but to a sub version called “Developer Stream”. This stream holds the version of this developer only. This version will be promoted to the master stream when the whole feature is ready for action. This actually raise another question - how are we suppose to treat the source control apps? Should we use them as versioning  AND backup apps, or only versioning? If we'll think of them as versioning products only, then the problem is not even raised. Developer one should not check in the files at all, until he has finished working on them and they can be part of a version. And about the backup issue - there are a lot of 3rd party products that can handle that, regardless of the VSS. So, how do you utilize the VSS? Versioning only, or Backup & Versioning? How do you solve the situation described above? Posted Jun 16 2004, 11:08 PM by memi with 5 comment(s) Filed under: VS.NET

• Things I like in Office - Excel XML

  We have an application which should produce reports in Excel format. The first thing I thought about was to send the client an XML string which conforms to Excel standard, and set the content type to “Application/vnd.excel” (BTW, does anybody knows what the 'vnd' stands for? I have no idea.). Problems began when it was found that the Excel should have some pre-defined formatting, as well as many formulas. Things started to complicate. Next thing I was looking at the Web Service Toolkit for Office 2003. A very nice tool indeed. However, I felt uncomfortable with it for two reasons: 1. It looks awkward to retrieve the xls file from the server to the client, and then go back to the server to retrieve the data. 2. Our project is in .NET (naturally...), and I really wanted to avoid using VBA with it. (I can't use .NET for the webservice, since there will be no .NET on the client machines.) Next, please. There are some very nice components for creating Excel files on the server, like Softartisans's Excel Writer and Aspose's Aspose.Excel. I've considered using them, and then stumbled across their price. COMON! More than $1000K for an Excel component? I'll better purchase the whole Office Suite, and put it on a seperate machine, which will solve all my problems. Well, continue googling. And then I stumbled across this link. Mmmm.... Interesting. I started investigating about this Excel XML, and it really looked promising. Now I'm quite sure this is the approach I'm going to adopt. No Excel on the server, pure XML / XSL creation, really lovely. Some minor problems were to be solved (with some help from Scott Hanselman) and we all set. Lessons? There are 1000's way to populate data in Office. The problem is not the “How-To”, but the “Right-To”. And of course, and most important - There's nothing like good old Google. Posted Jun 06 2004, 01:24 AM by memi with 1 comment(s) Filed under: General

• ObjectSpaces - Lesson not Learnt

  Now, after the dust has settled after MS announcement of delaying ObjectSpaces until Longhorn release, I think it's time to see what we've learnt from that. For a long time, most of the entries in the BlogSphere discuss features that will be rellevant only in VS.NET 2005. Reminder: VS.NET 2005 will be released in the first half of 2005 (hence the 2005 in its name). Meaning: In a bit less than a year. No doubt many features of it, as we know them today, will change dramatically until its release date. If a citizen of Mars will land here today, and the first thing he'll do is to read .NET blogs (right after making world peace), he won't even know there is something called VS.NET 2003. He'll think everyone uses VS.NET 2005, write full blown application using Generics, uses the VSTS massively, and creating their UI using Avalon. Hey guys - we are in the present! Time now is June, 2004. Our current environment is VS.NET 2003. Our .NET Framework version is 1.1. Our applications get rendered by either HTML or WinForm. Our source control software is VSS / CVS / ClearCase / Something else in PRODUCTION mode, and our only use of Avalon is when reading about Glastonbury. Yeah, VSTS is quite sexy, but it also can be delayed until Longhorn or whatever timing MS will choose. Note: I have nothing against MS. VS.NET is their product, and they can release it and its features whenever they want. But, as we learnt from ObjectSpaces, release dates can be quite flexible, and we don't want to look back a year from now, and find out most of our entries discussed completely irellevant subjects. So PLEASE, write something that we can use today, in applications we develop today, because the customers want them today. I haven't heard of any customer that said: “Wow, this Avalon thingy looks cool. Let's wait with our application until Longhorn will be shipped.” Posted Jun 04 2004, 02:05 PM by memi with 5 comment(s) Filed under: General