-
-
After a couple of hectic weeks and a couple of extremely hectic days I've finally moved out of my flat and I'm ready to go for a 4 week vacation to Cuba tomorrow. (See my about pages for a little more details).
My activity here will be quite low for a while. Updates about my trip can be found shortly in my upcoming travellog.
See you all in a while, when I get to WLANs in Los Angeles, San Fransico, Anaheim, Seattle etc.
-
-
Every time I get the time to sit down and get into some part of the framework or VS.NET that I don't know well i deeply regret not having done that before.
Feeling fine with xcopy deployment for a long time, I figured I'd give Web Setup Projects a go, and naturally they're great. This gem at MSDN shows the procedure for setting up the web.config of an ASP.NET application using an Installer class and a Setup project. Cool!
-
-
I've just finished setting up my new Dell D600 notebook, and as always surprises occur. I was about to edit my typed dataset XSD file when nothing happened in VS.NET 2002. The XSD designer would not open. I then tried to add a new dataset to the project to manually move the schema. Then I got this nice message:
The daVinci Diagram Surface could not be found. Please reinstall Visual Studio.
I reinstalled Visual Studio with no success. A quick google (always google before you reinstall - AGBYRI) returned a solution that Steve Smith came up with just 5 days ago. We both have the Office 2003 Beta installed (I have the Beta Technical Refresh as well) and this seems to overwrite these dlls:
c:\program files\common files\Microsoft shared\msdesigners7\msdds.dll
c:\program files\common files\microsoft shared\msdesigners7\msddsf.dll
c:\program files\common files\microsoft shared\msdesigners7\msddslm.dll
c:\program files\common files\microsoft shared\msdesigners7\resources\1033\msddsui.dll
Steve suggest reinstalling in a certain order, but that's not necessary. Just overwrite these files with some from a machine without the Office 2003 Beta installed. I don't know what problems it will cause for office though. Too bad I couldn't find a Bug Report feature on officebeta.microsoft.com.
-
-
If you look up the DataRow class in the .NET Framework documentation you'll see this:
[Serializable]
public class DataRow
In the happy beleif that this was entirely true I designed my remoting interfaces with DataRow as parameter and return values to transport DataRow objects standalone. But no. I got a SerializationException and Malcolm Stewart with MS Developer support explains why in the adonet newsgroup:
The DataRow has no default constructor and no custom serializable method - either of which
would be required for what you want. In order for a DataRow to be
serialized, it must belong to a DataTable in a DataSet - the DataSet is
currently the smallest unit of data that can be serialized. We are aware of
this limitation and it is due to change in future versions of the product.
Please change this!
-
-
I've been using GDN Workspaces since day 1 with VS.NET integration. I simply love it!
What would be cool is added functionality for codestats. I'd like to see codelines per project and per member in the workspace. Maybe "lines added" and "lines removed" for each user. And maybe monthly stats? This feature should be fairly easy to implement with counts on checkout and checkin and would promote competition between project members.
It would also be cool if you could flag a class or codefile for another member of the Workspace, for revision or simply a good ole' braggin..
After having sold my appartement yesterday I seriously consider moving in at GDN:)
-
-
Today I somewhat unvolunteerily dove into System.Security.Cryptography. It became a shortstory and i picked up several useful pointers on the way. I finally got a cryptoclass together that is supposed to be pretty safe according to secure sources.
Hopefully useful reading for some.
-
-
Erik fights for the removal of [TableName] from primarykey-names and sets an equal sign between Table and Class.
His point about the ID field seems ok, but as I see it, this all boils down to setting a standard and keeping it. In my opinion the naming in the database is somewhat irrelevant because I usually like to have alternate propertynames in my code anyways. For example I always use codegen attributes with my typed datasets to prefix all columnnames with "Item" so that they appear consequetively in Intellisense (sucks to skim through all the elements for the DataRow to find the column named "Size"). Using codegen attributes for the columnnames also makes the code more resilient for database changes, and enables Erik to change "CustomerID" to "ID" in the database without any implications for the code other than a simple change in the XSD.
With regards to the dataset/datatable and OOP I feel that setting Table = Class is a dangerous simplification. A table or tables might often map directly to the Table Module [Fowler] pattern as a dataset, but in some cases Data Transfer Object [Fowler] constructed from database information (as a Custom Business Entity [MS Data Application Block] ) might be a better solution than Table Module. In .NET however, because of the serialization capabilities of the dataset, the Table Module works great as Data Transfer Object. Unless the structure is too large or complex that is.
If you're working with software reengineering Table Module usually becomes completely impossible when you have to handle old, patched and poorly formed database-structures and you have to abstract the Tables.
Constructing a class that is similar to a well-formed table as a Data Transfer Object makes sense in most green-field scenarios. This is because you get to define a comfortable table structure from day one, and the typed dataset that makes implementing Table Module a breeze. But saying that a Table is the same as a Class is too easy and removes the careful consideration that should be done when architecting an application.
-
-
At Lambda the Ultimate it doesn't seem to be much enthusiasm about the new partial type construct in C#. Microsoft is introducing this new feature to enable separation of classes to separate files, thus simplyfing code-generation.
If you think about it, this should prove to make development of asp.net webforms (among other things) a lot cleaner. Take the entire contents of your InitializeComponent method and generate+compile it into your partial class at buildtime based on the <asp:> tags in your aspx file. That would would clean up a whole lot. The only thing I can see that is needed to acheive this is to supply support for all object property-settings in the actual asp tags.
Another potential ASP.NET 2.0 feature is masterpages. Microsofts ASP.NET PM Shawn Nandi talks to aspnetpro about it. And the ASP.NET Team has released a control to implement Master Pages at asp.net. Here I really hope they get it right. I fear a mix between PageMaker and FrontPage for handling this and I wish for a true object-oriented solution. At the moment I've implemented Page Controller based on Enterprise Solution Patterns for Microsoft .NET which basically constitutes Master Page. What I miss is visual inheritance in VS.NET that will work for inheritance hierarchies.
I can see the point about encapsulation and extensibility related to OO made by the Lambda guys. But on the other side there is a great potential for productivity enhancements. As long as sensible use of codegen and tidy integration with development tools is applied this will help Microsoft reach their goal of reduced codelines written per task.
-
-
Martin is speculating about young developers platform preference. Beeing a young developer at 23 and just two months out of school I can somewhat relate to Martins assumptions. Among most "regular computer geeks" in my school there were virtually none that perferred Microsoft technology. They all wanted java and linux. These were naturally also often some of the best students (although some were just lost). The Norwegian demoscene (scene.org), which is among the most active in the world, is dominated by youth, and java have the majority of votes. It's the "doItFromTheCore" and "the less user friendly the better" mentality.
Additionally there seem to be a tendency among (at least Norwegian) schools to prefer open standards for the curriculum, often argued by the "independent standard" point. In my bachelors degree for example, only 2 weekhours in one semester were spent on .NET while approx 4 weekhours over 6 semesters were spent on java programming. Their argument was that; they did not want to be biased (by teaching with Microsoft tech), that Microsoft Software wasn't secure enough, and of course the financial aspect. I tried to tell them about MSDNAA for the last two years, but that was ignored.
.NET is in my opinion the by-far best enterprise development platform. Our bachelor project was J2EE based and I was annoyed about it's lack of productivity for 4 months. Some of the hard-core linux geeks from school are now slowly turning against .NET. But most of them are clinging as hard as they can to open source and java.