re: VB6, R.I.P. - Frans Bouma's blog

# re: I'm alive!@ Monday, May 05, 2003 11:04 PM

welcome!

Greg Robinson

# re: I'm alive!@ Monday, May 05, 2003 11:06 PM

Thanks, buddy. :) I'll add your blog to my list of links. :)

Frans Bouma

# re: I'm alive!@ Monday, May 05, 2003 11:55 PM

Howdy, noticed your sig on GoT, welcome on board :)

Paul

# re: I'm alive!@ Tuesday, May 06, 2003 12:05 AM

Heya Paul :D. I was looking for your blog but couldn't find it. Will add a link as well :)

Frans Bouma

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 6:48 AM

This would be a nice LLBLGen 1 addition!

Paul Gielens

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 7:12 AM

Yeah :) I was investigating some techniques to implement variable filtersets on resultsets (i.e. joined columns from one or more tables/views), for the O/R layer for LLBLGen v2. One of them was this technique, the other was a dynamic build query using parameters and build using a stringbuilder and then fed to a command. The stored procedure as shown above was slower than the dynamicly created query. I tested it with random input parameters, and the stored procedure couldn't keep up. That was an eyeopener though, so I'll include a dynamic query engine.

But LLBLGen v1.x can indeed win a lot with this, because the sole thing lacking in it is the ability to write custom selects on a combination of fields. With this technique that would be possible.

Frans Bouma

# Frans Bouma's blog@ Tuesday, May 06, 2003 7:59 AM

Frans Bouma's blog

TrackBack

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:37 PM

Any movent in the LLBLGen workspace?

Paul

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:44 PM

Not that I'm aware of. some people joined lately but I haven't checked if they were very active. it goes as with most OSS projects: big plans by a lot of people, but a few really execute these plans.

Frans Bouma

# re: I'm alive!@ Wednesday, May 07, 2003 1:59 AM

Hey Frans! Welcome!

Eric J. Smith

# re: I'm alive!@ Wednesday, May 07, 2003 3:19 AM

Thanks Eric! You got a blog yourself I can link to?

Frans Bouma

# Emitter@ Wednesday, May 07, 2003 4:03 AM

Emitter

TrackBack

# ShowUsYour-Blog!@ Wednesday, May 07, 2003 4:28 AM

ShowUsYour-Blog!

TrackBack

# re: It's not all bizznizz apps@ Wednesday, May 07, 2003 11:11 PM

Just a little FYI, CsGL is not just for c#. One of the reason the new library's called something different is this reason. The new library being worked on is CLS-compliant as well as cross-runtime/platform. We've got some cool stuff coming down the pike. As always, as listed on my (sad) page, which is hosting the new library, I could really use some non-Windows testers.

Ridge

# ISerializable@ Thursday, May 08, 2003 3:54 AM

ISerializable

TrackBack

# re: Borland's prices are too high?@ Thursday, May 08, 2003 6:31 AM

I'd like to do perform a feature comparison before I made a judgement, but on its face I don't think $999 seems too high if the product features are that compelling.

Think of it this way- if you're a carpenter, how much do you pay for your tools over time? I know that the tools are extremely expensive, and that they are maintained and replaced over time as needed. What's the value of what you produce with those tools? For those of us working in software development, these are the tools we use as part of the trade, and the work that we produce with them justifies their cost to a large extent.

randy

# re: Borland's prices are too high?@ Thursday, May 08, 2003 11:40 AM

I just appreciate you addressing the HTML reformatting issue with MS. Be sure to post their response when it comes forth.

Ron Green

# re: Relationships@ Friday, May 09, 2003 3:32 AM

That's a big post Frans! :-)

Eric J. Smith

# re: Relationships@ Friday, May 09, 2003 3:40 AM

heh :) yeah, it turned out much larger than expected because I thought I had to explain some stuff before diving into what I wanted to say. :)

Frans Bouma

# ISerializable@ Friday, May 09, 2003 6:30 AM

ISerializable

TrackBack

# re: XPath in T-SQL?@ Saturday, May 10, 2003 4:43 AM

I have to disagree - while I'm very worried about CLR code showing up in SP's, I think pattern matching is a natural extension of SQL and a welcome extension. Like SQL, XPath is used to define "what" I want (declarative), rather than "how" to do what I want (procedural). The WHERE clause is used to filter records, and becomes much more powerful if it can match on addresses with apartment numbers, text fields containing URL's, etc. I very much agree that procedural constructs in SP's is a bad paradigm mix, but SQL has long needed some improved pattern matching abilities.

Jon Galloway

# re: Relationships@ Saturday, May 10, 2003 5:36 AM

There is a solution to your first woe: denormalize for performance.

What is the difference between maintaining an OrderCount property in a Customers object (or OrderExists, or whatever it is you want to record about the relationship), and providing a field in a Customers table with OrderCount?

If you don't like the performance hit of traversing Orders, then don't. Denormalize for performance.

Your complaint about using intermediate tables: "which entity is this intermediate table representing? None..." shows either a basic misunderstanding of abstraction, or a double-standard, as you don't seem to have a problem with the concept when OO-methods do it.

Yes, a relationship is an entity -- an abstract entity. (Note, "abstract" is used with its common English definition here, not the OO definition.) Not every table which defines a many-to-many relationship entity contains additional fields describing the relationship, and this does not make the relationship's abstract reality a "bad thing" in any way.

Hiding the reality of the relationship entity, or giving it less "value" as a real thing to be considered in design is a mistake.

Then, happily your CMS example discusses the real differences between object and relational data models. For a given situation, one will provide a more efficient representation than the other. And once you commit to one or the other, translating back and forth is a rough boundary to cross, best avoided if possible. These are the points that need to be blogged and taught until everyone knows 'em.

Since your point was not to write about the merits of the relational model, it is understandable that you did not include an example where the storage and retrieval inefficiences of the object model make it a worse choice than the relational model.

The real solution is to understand both approaches well enou

Eli Robillard

# re: XPath in T-SQL?@ Saturday, May 10, 2003 12:31 PM

I have to disagree as well. XPath comes because of the XML support in Yukon. Apart from that it doesn't make a ton of sense, however, you definately don't want to query xml data with T-SQL... because T-SQL is designed for RDBMS systems, not xml.

Jesse Ezell

# re: XPath in T-SQL?@ Saturday, May 10, 2003 8:51 PM

If they use it solely to add new predicate clauses to the WHERE clause, indeed to filter out rows matching the single XPath clause, it is ok to me, however the usage of XML as a storage form, requires the existence of XSL and XPath to work with the XML, and I do not see how these two can be mixed with T-SQL.

Frans Bouma

# re: Relationships@ Saturday, May 10, 2003 8:58 PM

The problem I have is about the very different ways of how relations are physically stored in the database: via foreign key constraints, via combinations of constraints, via check-constraints, via instead of triggers etc. While you can store relations ALWAYS via a separate object which holds the complete information about the relationship, which entities are involved, which attributes participate in the relationship etc. You then eliminate the necessitiy of intermediate tables plus f.e. the necessity of needing f.e. combinations of constraints or the addition of attributes which serve no meaning. Intermediate tables which formulate the m:n relations (like non-obvious intermediate tables like 'Orders' in Northwind which defines the m:n relation between Employees and Customers) can be entities, but are necessary to formulate a relation between two OTHER entities. That's weird. You'd like to define that relationship with only the two entities involved, since these entities have the relationship.

Frans Bouma

# re: XPath in T-SQL?@ Monday, May 12, 2003 2:44 AM

As you say, XPath is a pattern matching language, so it is a natural fit for using in the where clause. It is not functional at all. XSLT is (although some disagree), but XPath isn't.

What the MS plans are for merging OO code with XML and RDBMS paradigms is still unclear to me as well, but this article might shed some light: http://www.research.microsoft.com/~emeijer/Papers/oopsla.pdf

I do not expect this kind of technology in the Yukon release though.

Teun Duynstee

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:15 AM

Even with a data reader, you will end up caching data in memory at some point along the line (whether it is in your own objects, the UI, etc.). Not using the DataSet does little to solve this problem. What it all boils down to is that there isn't any really easy way to get around the concurency issue in a disconnected environment.

DataSets are very cool. ObjectSpaces, which are built on top of the DataSet (at least at the time of the last preview), will let you do the same types of things (and much more) with objects and show just how cool the DataSet is. Still, I do agree that the DataSet is not suitable for a complex domain model. Custom objects always win out there (but again, they must cache state in the same way that the dataset does...it is just a pain to write all the extram code).

Jesse Ezell

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:42 AM

Jesse is right. The only way to prevent having an inconsistent state in your copy of the data is to lock it after you read it, let the user change it, and then commit it. If not, you'll always have to deal with an optimistic concurrency conflict in your application, regardless if you are using DataSets or any other persistence layer.

The persistence layers you mention can solve the issue if they are the only AppDomain accessing the database. If you have two AppDomains accessing the same database, you have the same problem. If you have two processes, or a server farm, you'll have the same problem. If you are using only one AppDomain to access your database, then you could tell that to the persistence layer so it caches it more agressively, but it will be a deployment-time optimization. You will still have to deal with optimistic concurrency issues in you code, because you'll will want it to scale to multiple appdomains...

Andres Aguiar

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:53 AM

Caching in ANY form is an issue, and you always have to take into account that when you read data on a given time T, the microsecond after that it can be changed by another thread. Indeed, if you do not want that, you should lock the row, not helping performance.

DataSets however give you the feeling they take care of this, which they don't (in full). The problem is that they make it easier for the developer to work in a stateful way with data cached in memory than f.e. the DataReader approach does. If you need to update a userrow f.e. you can simply execute an Update statement on the database, or update a cached userrow in a dataset, then persist it. THe latter will probably not work well in an environment with heavy changing data.

Andres: your example of the webfarm and the multiple appdomains is a good one.

I'm not against the usage of a dataset as a datacontainer between tiers, however if you use it as an equivalent of Fowlers UnitOfWork, it gets a little tricky.

Frans Bouma

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 6:23 AM

I found working with a timestamp column very helpful. See "Distributed Concepts and Design, Addison Wesley". A must have book for enterprise developers.

Good post Frans, to bad lots of people (even on dotnetweblogs) seem to be indoctrinated by MS's marketing strategy and refuse to dig in on this issue.

Paul Gielens

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 8:05 AM

If you are trying to use DataSets as a global caching mechanism then you are right, they are not good for it.

If you use them as a container for Business Entities instances, for example an Order, when you retrieve one, change it offline, and then persist it, then they work great.

I don't want to just execute an update statement to persist the data because I won't have optimistic concurrency, I'll have to build it myself.

They are also good when you want to cache mostly read-only data. If you have an ASP.NET app that uses DataReaders for filling grids, you'll have better performance than using a DataSet. If you then want to cache that data in a middle tier, or in the asp.net tier itself, then you'll have to change your app.

If you bind to a dataset, you'll have worse performance in the web server (the same in the database server), but you can add caching for read only data very easily, and that will imply a great improvement in the overall performance/scalability of the application.

Andres Aguiar

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 9:56 PM

Nice research. I guess now I'm still wondering my I shouldn't make the next leap and go with an O/R mapper all the way? A few months ago I would have said no way, but then again I was convinced that sprocs were the way too. So please more enlightening posts like this last one instead of the endless debate on the forums. Thanks.

Paul Wilson

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:17 PM

Paul, a MONTH ago I would have said: "Stored procedures are the way to go". However, there are times in life when you face the results of choices you've made, you don't like what you see, you suddenly know you made the wrong decisions. I've to admit I've spend 2 months developing a visual stored procedure designer for my generator just to meet the requirement to first generate stored procedures, and then generate call classes for these stored procedures. These 2 months were a total waste of time, because it is a) undoable to write a decent visual stored procedure designer without forcing the user to write SQL statements, and b) it will result in time-consuming work because the use has to design EVERY SINGLE action he wants to perform on the database in a stored procedure. For CRUD operations, that's easy. But what do you do when you have 3 foreign keys in your table and you want to have several delete stored procedures based on any combination of these foreign keys? That's 6 stored procedures if I do the math correctly :) Not a pleasant sight with a lot of tables.

I think the debates on the forums did help me find another way out of this by going the other way around, which ended up in tiny pieces of code which produce on the fly what is needed. If you set it up in a way that the small statements use factories which produce agnostic objects with db specific code INSIDE them, you have very portable code (just change the factory).

So I won't say the 'endless' debates on the forums are not worth it, I think they are. Every developer thinks on a given point in time they know what's best in a given situation. During debates on forums you learn other peoples views, and they will probably not enlighten you on the spot, but will work through in your work in some way, I'm sure of it (either by strengthen you in your believe you're right, or in a realisation you're wrong so you can change your way of doing things).

If you wa

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:20 PM

(the comment got clipped)
If you want to write all the logic by hand, there is NO WAY an O/R mapper can help you. O/R mappers, and related generators, are ment to generate common code based on a database scheme / input parameters and using a set of choices which might be the ove rall best. But NO O/R mapper will ever beat a handwritten, handoptimized DAL with stored procedures for every single possible query with a combined calling mechanism which is smart enough not to get data when it shouldn't. Like John Carmack will never b e able to deliver a generic 3D engine which will perform top notch in every single 3D game possible.
 

 
So, if you are aware of the compromises taken, you can then start looking at the advantages of using a ready-to-roll framework over writing it all by hand and check if the advantages are outweighting the disadvantages related to the compromises taken. W ith a solid O/R mapper or related generator, I'm pretty sure the ready-to-roll framework is well worth it.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:36 PM

So are you basically saying your next version will be an O/R mapper instead of a code generator? If not, then my question is still why your code generation approach (but without the sprocs) vs. something like EntityBroker?

Thanks for your time.

Paul Wilson

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:47 PM

It will be both. It will generate code which utilizes a common framework, the code generated will be focussed to work with entities and collections of entities (Like 'Customer' and all code to handle the entity customer).

It will also allow you to generate lists, like order + orderdetails, some people like to use. These lists are pre-generated (the code to deliver you the list), can have filters, are typed (its a typed datatable) and can originate from an existing stored procedure (or not). It will also allow you to generate dumb datatable lists, if you want these. This last category can also be generated on the fly, using code and the same dynamic query engine, by the developer.

I generate code, but not all code necessary is generated. A lot is precompiled in an assembly, like all O/R mappers use. The reason I generate code is that I wanted to make life easy for the developer: thus in a gui he designs the usage of the O/R mapper, the O/R mapper is then created for the developer. The developer doesn't have to add a single attribute to work with the code. Also the generator does an extensive analysis of the database schema, so m:n relations are embedded directly into the Entity classes. (So for northwind, you'll get Customer.GetEmployees(), which in fact is an m:n relation via Orders. ).

EntityBroker requires you to write a lot in attributes, I generate this out in code. THere is not that much difference.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:13 AM

Hi Frans,

Just out of curiosity, did you run the test with specific stored procedures too, instead of the generic one?

I understand that that wasn't a realistic option in your opinion, but I'm still curious regarding the result.
:-)

Best Regards,
Jimmy
###

Jimmy

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:21 AM

:) No I haven't. I did however profile the difference in speed between a stored procedure with optional parameters and a stored procedure tailored to one single filterset and the optional parameter one was much slower, since the optimizer can't optimize away a filter on a column even when the parameter is optional.

I have to test it extensively to say anything about the speed between dedicated stored procedures and dynamic queries (thus in the case of 3 foreign keys which are a possible filter, you have to write 6 stored procedures and then select one of them to run the query of that moment), but I don't think they'll be much faster than the dynamic queries (the dynamic queries have to be build up each time which takes some time, network speed can be a factor when a high amount of queries is executed), based on f.e. the books online documentation of SqlServer 2000.

Hand-optimized stuff is always the prefered way of doing things when performance is absolutely a matter of life and death. So is assembler. Neither one of them is recommeded in day to day applications due to the hard way of maintain such code.

Frans Bouma

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:27 AM

I got an error so I try again...

It would also be interesting to see how dynamic SQL in a stored procedure would perform compared to the other options.

Best Regards,
Jimmy
###

Jimmy

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:27 AM

Frans,

If I understand correctly, your dynamic query generator will run against JET -- which is used a lot in shared hosting environments. (Not everyone wants to pay for SQL Server.)

That would be very nice indeed...

Paul Schaeflein

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:53 AM

Paul Schaeflein,

I do understand that shared hosting environments sometimes offer access database support as the only support for databases, however I firmly believe that access is not the way to go for n-tier applications. Access is a single-user toolkit for applications which need a (small)database. Other applications can better target databases which are ment to perform in a multi-user environment. If they do not want to pay for a database, MSDE is there to the rescue.

The generator works with database drivers and database specific generators. In theory it's possible to write a driver for JET and thus a query generator for JET, however that's not planned. (It will not be that much work however).

Frans Bouma

# Frans Bouma's blog@ Wednesday, May 14, 2003 4:24 AM

Frans Bouma's blog

TrackBack

# Andres Aguiar's Weblog@ Wednesday, May 14, 2003 4:24 AM

Andres Aguiar's Weblog

TrackBack

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 8:55 AM

Also, what are the trade-offs in a large system. For example, one with 200+ tables (or how about one with 1000+ tables), 3 Sprocs (INSERT, UPDATE, DELETE) per table plus 1 more Sproc for each type of search per table. At this point, with at lesat 1000 Sprocs, even in the optimized world of specialized sprocs, how many would actually be kept in memory, as compared to how many would be dropped out and require a recompile each time they are used? Just some food for thought...

JimS

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:39 PM

I'm not proposing to agree or disagree with your premise (I rather suspect that I'd have a foot in both camps, in fact) but I did wonder about the validity of the benchmarks.

Firstly, did you try using the "WITH RECOMPILE" option when you created your stored proc? As you'll probably know already, this gets round (at a cost per execution) the inappropriate query plan problem. In fact, with optional search criteria that might influence the query plan I'd say it was essential.

Secondly, to echo a previous comment, did you try building the specific SQL string required in the stored proc and using "exec"? I would expect similar response times to dynamic SQL since the query plan must now be generated fo each execution.

A third option might be to use a 'master' stored proc to accept the optional parameters and then pass control to 'sub' procedures that contain queries that are not hampered by the optionality. Of course, we're starting to run the risk of substantial duplication at that point, with increased maintenance costs becoming a potential downstream problem.

I think I might be inclined towards the dynamic route in order to be able to exercise better control over the duplication issues.

Assuming execution times can be equalised, the remaining issue may be in the area of access control. There may be benefits to be had from restricting table access to stored procedures, perhaps because of referential integrity concerns.

Mike Woodhouse

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:50 PM

Mike:
The execution plan is the same with every input, this is because the stored procedure uses the same code. Check the stored procedure in the linked blog. Specifying 'With Recompile' would slow down the execution without any benefit.

Building strings INSIDE a stored procedure is even slower and not an option. T-SQL is not ment to be doing string contatenations, and it also kills the caching of execution plans, because you can't re-use execution plans based on parameters (allthough sqlserver tries to replace hardcoded values with parameters).

The Dynamic queries ARE parameterized. Therefor the queries will re-use execution plans (there are 6 execution plans possible with the test done: 3 foreign keys, 6 combinations). The dynamic queries were not created using the concatenation of the values in the query, but using parameters.

Delegating the call to other stored procedures inside a stored procedure wouldn't have helped either, I can do that selection in C# too, avoiding slower T-SQL execution code. The point was: is it worth it to do this:

1) create 6 stored procedures (which are fast)
2) create 1 stored procedure with optional parameters (which is slow(er)
3) create dynamic queries with parameters (thus in the end 6 of them).

1) is probably one of the fastest, but requires 6 stored procs in our situation for that particular table. Not that nice. 2) is slower than 3) so 3) is IMHO the best choice.

About access control: I read that more and more, but it's hot air. I'll try to explain why later on.

Frans Bouma

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, May 15, 2003 12:06 AM

Maybe as an interim solution they could fix the problem in the upcoming release of the Web Matrix.

Ron Green

# re: Stored Procedures vs. Dynamic Queries.@ Thursday, May 15, 2003 1:47 AM

Good work! I just posted my thoughts to my blog (linked to my name above) rather than spilling them here...

Richard Tallent

# Frans Bouma's blog@ Thursday, May 15, 2003 5:19 AM

Frans Bouma's blog

TrackBack

# Frans Bouma's blog@ Thursday, May 15, 2003 6:01 AM

Frans Bouma's blog

TrackBack

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:33 PM

But still no refactorings? No "extract method", "rename method", "move method", Renaming a variable in one place and renaming them everywhere in it's scope automatically? Those are things I can't hardly live without since I've been using Eclipse for Java developement. And *might* even be a reason why I keep using Java although I'd prefer C# as a language.

Zef Hemel

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:40 PM

No refactoring functionality. I heared C# builder of Borland (to be released this summer) will have refactoring-functionality. Refactoring is something that is not considered 'useful' in the MS community, since it is a tool necessary by people who think while they write code (like in the eXtreme Programming world). So "if you design your software well enough, you don't need refactoring". I agreed with that for a lot of years. At the moment I'm doing a lot of designing while I write the code, and refactoring would help a lot in this case.

Frans Bouma

# re: #define debugging testing@ Sunday, May 18, 2003 12:42 AM

http://dotnetweblogs.com/sbchatterjee/posts/7189.aspx

SBC

# re: #define debugging testing@ Sunday, May 18, 2003 1:14 AM

I do agree with what you write, and I maybe confusing bugs (they are all bugs after all!), but I think I can solve 99% of all bugs just tracing things. That's for my personal case.

I also wanted to point that in real world (at least the world I live in ;-) scenario, average developers spend way too much time in the debugger than they should, and this just costs a whole lot of money to projects, in terms of productivity.

Simon Mourier

# re: #define debugging testing@ Sunday, May 18, 2003 1:21 AM

Tracing can be a tool to find code error bugs, why not? It shows you the state on a given line and you can do that with printf's or looking at a locals window in a debugger ;)

I agree that way too many developers simply do not know what debugging is really about. If a method deep down the call chain is probably not good, they do not know that because they never tested the methods calling the code either on pre-/post conditions, fire up a debugger, break at the start of the call chain and step ahead till doomsday not knowing where to look for because they do not use their head.

Frans Bouma

# SBC DotNet Weblog@ Sunday, May 18, 2003 7:29 AM

SBC DotNet Weblog

TrackBack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:18 AM

Very bad advice IMO. Use VS.NET 2003. The amount of time you save will be more than enough to deal with any of these issues.

Here is the classic Early Adopters article about framework versioning:

http://www.3leaf.com/default/articles/ea/SBS.aspx

.NET was designed to support versioning, the solution is not ignoring versioning, but learning how to properly use it.

Jesse Ezell

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:24 AM

Then please help me in this situation, since I can't think of any real solution. How am I going to FORCE versioning onto developers using visual studio.net 2002? I can only tell them to use the assemblyBinding tags in their own config files otherwise it WILL NOT WORK.

If this visualstudio.net 2002 user is not developing an executable but also a library (based on your library), he TOO has to tell HIS customers to include the assemblyBinding tags otherwise the code will NOT WORK.

All versioning is focussed on UPWARDS compatibility. However no-one is talking about .NET 1.1 assemblies which are used in .NET 1.0 environments.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:47 AM

*dang* wrong quote :)
[quote]
Adopter:

This works both ways. If you’ve built a v1.1 component, there’s nothing to prevent a developer from referencing it from a v1.0 application. In this case, your v1.1 component finds itself running on the v1.0 Framework. This situation is more dangerous than the reverse, as there’s the potential that your component uses something that doesn’t even exist in v1.0. If this is the case, expect a “missing method” exception.
[/quote]
I tested this and this is not true (see error listed in the blog). My 1.1 assembly is not run against the .NET 1.0 install on the machine even though the .exe file is compiled on that same machine using csc v1.0.3705.288, thus .NET 1.0.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:57 AM

If you have both frameworks installed, can you compile using the command line in the 1.0 environment?

Paul Schaeflein

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:04 AM

Yes you can, you can manually compile against whatever framework you want. An ISV can opt for that route as well, however this can be cumbersome also when the set of assemblies have dependencies etc so you have to write NAnt files to build manually. It's not an easy situation, and I think not a lot of ISV's have thought about this, I for one hadn't until I tested it this morning and discovered I made a mistake upgrading to VS.NET 2003, even if the editor is much better and very helpful.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:21 AM

At CodeProject there's a tool converting projects and solutions from VS.NET 7.0 to VS.NET 7.1 and vice versa:

http://www.codeproject.com/useritems/vsconvert.asp

Thomas Freudenberg

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:24 AM

In VS.NET 2003 IDE, you can choose which framework to compile against.

Project Properties -> Build -> Supported Runtimes -> Change

Jack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:29 AM

[quote]
In VS.NET 2003 IDE, you can choose which framework to compile against.

Project Properties -> Build -> Supported Runtimes -> Change
[/quote]
Only for .exe projects, and also this adds assemblyBinding tags to the .config file of the .exe project. You can't set this information on f.e. C# class library projects. VS.NET is also not compiling with .NET 1.0 if you select it in that dialog, it will compile using .NET 1.1, it will only change your app.config file so the compiled .exe uses .NET 1.0 because all referenced system assemblies are redirected to .NET 1.0 versions. This works ok.

THomas: thanks, can be a life saver in supporting multi-platform applications.

Frans Bouma

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 20, 2003 3:29 AM

Great article! Thank you! And thank you for your answer on the newsgroup.

Sasha

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:33 AM

again, I'm missing something here. .NET 1.0 is to DirectX 8.0 as .NET 1.1 is to DirectX 9.0. Get the drift? Just make the change and people will follow and soon enough no one will care about .NET 1.0, as they will all WANT to have 1.1 installed and running (and this includes those developers 'stuck' in VS.NET 2002 land)...

JimS

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:17 AM

Oh yeah, great selling argument: "You can use this software only with visual studio.net 2003. If you have still visual studio.net 2002, please upgrade.". :) I don't think that's gonna work.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:19 AM

Frans: What about using a third-party IDE, such as SharpDevelop or C# Builder, to compile your release build?

Phil Weber

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:01 AM

This is horendous advice. .NET fully supports Sxs versioning and assemblies. You need to figure out how to use it properly. See the Early & Adopter article, read about publisher policy files, etc but *don't* write riduclous stuff like "ISV'sL do NOT upgrate to Visual Studio .NET 2003!" Not only does it look bad for you but it looks bad for this site (of which many .NET people have been pointing out how much totally incorrect and bad advice is given out daily).

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:08 AM

You can’t **compile** against either framework version, but that you can use the <supportedRuntime> and/or <bindingRedirect> elements to run in either environment, assuming you don’t have dependencies. When we say compile against X, what we are really saying is that the compiler stamps the X version in the assembly metadata for the referenced version, which is the one the CLR tries to load unless redirected in the config files. Any code compiled in 2003 will target by default 1.1, but can be redirected using the configuration files. If you want to redirect to 1.1 from 1.0, you use the <supportedRuntime> element. And, if you want to go from 1.1 to 1.0, you use a slew of <bindingRedirect> elements. All of the VS.NET 2003 UI (C# and VB) to target runtimes creates the config files, but still stamps 1.1 versions in the assembly metadata. So, if you want to target 1.0 with code you wrote in 1.1, just add a section to the app config file. If you're an ISV, you probably have a setup process. Why can't you write this into your setup? Seems to be no big deal to me. What other software platform let's you upgrade without recompiling in a cleaner way?

Stephen Fulcher

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:11 AM

Sam: the early & adopter article is not mentioning class libraries. If you are selling class libraries, you are falling into this pitfall. It is NOT ridiculus advice, since I *AM* now in this situation and I *CANT* fix it, unless I go back to visual studio.net 2002 or compile the sourcecode by hand for 1.0, or supply the assemblyBinding tags and *HOPE* my customers are going to include it in their config files.

Do you know a solution then? I don't. You can say "It's horendous advice", but what are my options? I'm delivering a set of class assemblies to customers, who can (and probably will) use Visual Studio.NET 2002. I *CANT* compile these with .NET 1.1 because these will give them serious errors, unless they include the assemblyBinding tags in their config files. I've tested this today. I lost a complete day to test what I can do, and didn't find a solution. Therefor I posted this article.

If people are OFFENDED by this, I'm sorry, but it's the clear hard reality for SOME ISV's.

I also do not see why it would look bad for me. I warn other people to think twice before they move to vs.net 2003.

So Sam, as an invitation, please offer me a solution so I can fix this properly. I don't see one. Requiring customers to buy visual studio.NET 2003 is ridiculus in itself, and I can't do much more. A customer with solely visual studio.net 2002 is not focussed to include redirects for .net 1.0, because he never had to. *THATS* the issue. Who is paying the bill for all the supporthours my people have to give customers because they can't run the code they bought? Should I do something to my code to make this easier? If I can, please tell me. I don't know what.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:12 AM

when I said "this site", I meant "dotnetweblogs as exhibited by the main feed" fyi

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:18 AM

Stephen: if I was selling solely a .exe, it wouldn't have been a problem. The problem is with the class libraries. I can't supply them with a .config file (I wish I could).

It would have been really great if a class library compiled with vs.net 2003 and run by an application build with .net 1.0 would immediately use .net 1.0 assemblies. That would solve the problem. However this is NOT the case. Of course a customer can add the assemblyBinding tags, it's the solution that worked, however a customer has to add them. I didn't KNOW that. It's not mentioned anywhere that you have to add these tags to a .net 1.0 (!) application's .config file to make its class libraries (which are probably compiled with 1.1) use .NET 1.0 assemblies.

Because this is extra support trouble, extra trouble in codebases, it's wiser to keep the code in vs.net 2002, because this will keep you out of the trouble. I predict this issue will cause trouble for some ISV's. Now everyone is selling 1.0 versions, but this will change.

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:19 AM

I am not going to do this with you. While I appreciate your fustration, bloggers here need to learn *not* to make grand denouncements of something. You didn't say "some". You said "ISVS: do NOT upgrade." So all ISVs should not upgrade? Surely *most* ISVs are not exhibiting this problem. Having a blog that is public conveys a responsibility for being accurate as well as posting content free of rants or grand pro/denoucnements. You get the lecture today because there is just so much of this going on in general on this site, and prominent .NET people and bloggers are starting to complain. 'Nuff Said.

Sam Gentile

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:31 AM

If some 'prominent' .NET people have complaints about my blog let them contact me. I think that's the obvious way to do it. I haven't received *one* complaint besides some in these reactions here.

It's not just frustration, Sam. It's cold hard cash I'm loosing here, and no-one is paying it back because I made the decision to move to visual studio.net 2003 and I didn't know any better. If I can help others with a warning it would be great so others won't loose money over an obvious upgrade.

If I re-read the reactions on this blog, I see some good tips and some "this is bad advice"-replies. What's the problem? Is it BAD to tell the world Microsoft scr*ws developers over with their hardwiring platform targets in their IDE's? Apparantly. Good to know, so I can keep the blogs down to cheerio's for Microsoft's good deeds while keeping my mouth shut about their not so good deeds.

Yes, I'm offended now. I sincerely tried to fix this myself this day, I can't. Microsoft doesn't help me, I hope I helped some ISV's out there today so they make the right decision. If that's against the will of some 'prominent' .NET people, please let them contact me and perhaps they can HELP me with this.

I'm more than willing to type a long essay about every detail how to fix this, so I can say: "ISV's: it's safe to upgrade to visual studio.net 2003, read how".

Frans Bouma

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 8:59 AM

Last post from me on this. Apparently, you still don't get the difference on "some" versus "all" and "giving good advice" versus saysing "ISVS: Do NOT." Do I have to spell this out any more clearer? I checked every word of what I wrote with Scott, and spoke to him and he was fine with it. Complaints is refering to not just *this* site but the high number of incorrect .NET information that shows up on the *dotnetweblogs main* feed from a number of blogs on dotnetwegblogs. Scott and I recieve complaints on it. I gave you good advice on how you could have blogged it and how to make a blog successful. You chose to ignore everything I wrote. It's your choice. This is all I am going to say on this.

Sam Gentile

# Loosely Coupled@ Tuesday, May 20, 2003 9:25 AM

Loosely Coupled

TrackBack

# Frans Bouma's blog@ Tuesday, May 20, 2003 9:25 AM

Frans Bouma's blog

TrackBack

# Frans Bouma's blog@ Tuesday, May 20, 2003 9:25 AM

Frans Bouma's blog

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws

TrackBack

# Robert McLaws - BoyWonder.NET@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws - BoyWonder.NET

TrackBack

# Robert McLaws - BoyWonder.NET@ Tuesday, May 20, 2003 9:25 AM

Robert McLaws - BoyWonder.NET

TrackBack

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 11:52 AM

I have been stuck having to compile my NUnitAddin project with VS.NET 2002 to ensure compatablilty with both. Yes I might be able to add redirects to devenv.exe.config but I don't think users would be very impressed. I have heard it is possible to compile against the 1.0 assemblies in VS.NET 2003. It would just take a while to manually change them all. I've just written a snippit of code to change all assemblies in a solution to be the 1.0 versions. If you've got NUnitAddin installed you can use 'Test With... VS.NET' on the following method. Put this code in the solution you wish to convert...

using System;
using System.IO;
using System.Reflection;
using System.Diagnostics;
using EnvDTE;
using Microsoft.Office.Core;
using VSLangProj;

public class SolutionConvert
{
public static _DTE DTE
{
get { return (_DTE)AppDomain.CurrentDomain.GetData("DTE"); }
}

public void BuildWith_v1_0_3705()
{
foreach(Project project in DTE.Solution)
{
VSProject proj = project.Object as VSProject;
foreach(Reference reference in proj.References)
{
string assemblyPath = reference.Path;
string assemblyFileName = Path.GetFileName(assemblyPath);
string frameworkDirectory = Path.GetDirectoryName(assemblyPath);
string frameworkVersion = Path.GetFileName(frameworkDirectory);

string newFrameworkVersion = "v1.0.3705";
string newFrameworkDirectory = Path.Combine(Path.GetDirectoryName(frameworkDirectory), newFrameworkVersion);
string newAssemblyPath = Path.Combine(newFrameworkDirectory, assemblyFileName);

if(frameworkVersion != newFrameworkVersion && File.Exists(newAssemblyPath))
{
Debug.WriteLine(assemblyPath + " -> " + newAssemblyPath);
reference.Remove();
proj.

Jamie Cansdale

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 11:53 AM

.References.Add(newAssemblyPath);
}
else
{
Debug.WriteLine(assemblyPath);
}
}
}
}
}

Jamie Cansdale

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:22 PM

First, it's pretty easy to create separate VS 2002 and VS 2003 project files that point at the same source. Then you can work in VS 2003, and do your final build in 2002 (or you can set up a batch/makefile to do a command line compile).

Also, if you build an assembly from VS 2003, you can reference that assembly from a VS 2002 application just fine. You do not need binding redirects or policy files in this case. These come into play if you have a strong named component, and you want to replace it with a newer version (and you want everything redirected to the newer one).

Scott Swigart

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:38 PM

Or, you can maintain 2 downloads and EDUCATE your developers on which one to use.....

Robert McLaws

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:32 PM

Scott Swigart: did you try it? Of course you can reference it from vs.net 2002. It even compiles ok. It starts up even, but when you call a method in a class library build with vs.net 2003 from a .NET 1.0 application, AND that class library uses an assembly of .NET to do something (in short: something useful), it will crash with an exception that it can't load the right assembly (the 1.1 version) so your call will not succeed. I tried it, it fails.

Robert: maintaining 2 versions is nice, but what if I upgrade my own class library? Then I have to maintain 4 versions. Perhaps even 6 after another upgrade. I'll look into this, it might be the only solution which will not be a burden for my customers, if I implement it right in my generator.

Frans Bouma

# Frans Bouma's blog@ Wednesday, May 21, 2003 4:27 PM

Frans Bouma's blog

TrackBack

# Loosely Coupled@ Wednesday, May 21, 2003 4:27 PM

Loosely Coupled

TrackBack

# re: Microsoft gets Database Performance crown back!@ Thursday, May 22, 2003 8:17 AM

I used to work for a software vendor as an evangelist and we were primarily a microsoft shop. I can't tell you how many times I had to deal with anti-microsoft/pro-oracle battles. after a while i got pretty good at quoting statistics that dispelled a great deal of it. i think most of it has to do with good marketing on oracle's part.

slowly the myth is getting displaced.

-Mathew

Mathew Nolton

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 7:29 PM

Thanks for the explanation. Would it be possible/easy to write a VS add-in that raises warnings at compile time of usage of a framework assembly of a higher version than x (x being configurable in the add-in). Even if it is indirect (your project referencing a third party assembly which references etc...)?

This would be really usefull.

Teun Duynstee

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 7:34 PM

It definitly would be possible, you have to walk reference chains using reflection, but how to implement it as a pre-compile add-in... I really wouldn't know :)

Frans Bouma

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 9:32 PM

Why not just set the supported runtimes in the project properties dialog.

Also once you have changed the references manually to 1.0 and then manually back to 1.1, the projects will revert to 1.0 on compile. You are stuck with 1.0!

Victor Lindesay

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, May 22, 2003 9:36 PM

Victor: you can't set that setting in class library projects. Try it, the setting is not there. (The setting is only available on .exe projects which will generate redirect tags to 1.0 in the .config file, no compile against 1.0 is done in VS.NET 2003 unless you hard-reference to 1.0 assemblies.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:35 PM

Interesting...! I have to admit I usually say "Don't use functionality locking (your words) except when you really have too!" and that because of runtime efficiency. But this was a refreshing viewpoint!

To see it your way, how do you tune the solution so that the second user isn't kept from doing what he wants too, for longer time than absolutely necessary? I usually use a custom lock table for this and I use a time interval for when the lock isn't valid anymore and that way I deal with ctrl-alt-del, for example. Do you have a better solution to this?

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:50 PM

Interesting concept Frans. I see two places you need to detail out before this is realistically feasable.

The first thing you need to detail out is the 'lazy' user who will simply lock out others for long periods of time.

For example, say Joe selects the row that Jack wishes to modify first, but now Joe either goes for a cup of coffee or out to lunch, or gets called away for a dire emergency or just plain forgets to release the row for Jack to be able to use. Do we simply lock out Jack until somebody gives Joe a much needed kick in the butt? While software which tosses away a fraction of the work done is not a good thing, an even worse thing is software which slowly grinds work to a halt.

The second is scaling. Webservices are not needed in small scale systems. You can accomplish the exact same functionality in a simple two tier setup, avoiding all the inefficiency webservices would introduce. But in large scale systems, don't lose sight of reality. Yes, webservices work great, but now you also introduce physical distance also.

Sure, Joe could do the work Jack is and avoid duplication. Except Joe works in the corporate HQ in NYC. Joe is employed in HR and wants to alter John's home address so his next paycheck reaches him on time. Jack however, is John's manager and wishes to add change John's work extension ASAP because he's in sales and the website needs to pick up this change for new customers to reach him.

Now the question becomes who do we piss off first? Do we lose potential sales because a new customer can't reach our sales rep? Do we piss off John because his paycheck arrives late? Maybe we piss off Joe because we've now doubled his workload. Or maybe Jack because Joe left John's row locked while he left for lunch at noon - except it is 9am where Jack is.

And all because our 'more efficient' system won't allow two users to update two separate fields from the same row in our empl

Dave

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:51 PM

It depends on your application. If you are using a webapplication frontend, you're stuck in the request-response paradigm, so there is no other way then to lock using the mechanism you describe (which is commonly used, f.e. in CMS-es).

Another scheme can be where you still have the lock-table where you store locks on functionality, but a service which manages the locks and communicates with clients bi-directionally. Clients will notify the service that they're freeing a lock and the service can then notify another client waiting in line to enable the functionality.

But indeed, wmost of the time you are forced to implement a time-period to the lock on the functionality as well. However, if the organization is organized well and the software streamlined as well, it shouldn't be very common that a user tries to start functionality that's locked by another user.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:53 PM

Damn... gotta learn to be more to the point! :-)

I wanted to end by asking if my concerns were legit because I do agree.... optimistic/pessimistic locking really doesn't cut it 100% of the time.

Interesting post Frans!

Dave

# re: Concurrency Control Methods. Is there a silver bullet?@ Friday, May 23, 2003 11:54 PM

(My previous comment was targeted to Jimmy)

Interesting thoughts, Dave! How functionality locking is implemented can change from organisation to organisation. I can imagine a boss can overrule a lock on a given set of functionality or an admin can unlock a set of functionality at any given time, making the workflow continue. It is all about keeping the workflow going. If someone stalls it, it has to be tuned, both on the organisational side and on the software side.

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 1:10 AM

Frans, yet again... study the Fitch and Mathers sample. For what I can remember it provides a nice, solid, clean way to stop people from bashing the broker.

public enum Blah {
Pending = 0;
etc

Nice post... the writing style reminded me of your friend Fowler, to the core of the problem in mummy_understandable communicative language ;)

Paul Gielens

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 2:26 AM

Fitch & Mathers? hmm. Well like I said, it can be done on a lot of ways. I haven't looked into F&M a lot, but if they build in functionality locking, it's a nice real life example. :)

Frans Bouma

# Frans Bouma's blog@ Saturday, May 24, 2003 6:53 AM

Frans Bouma's blog

TrackBack

# mads studentblog@ Saturday, May 24, 2003 6:53 AM

mads studentblog

TrackBack

# Concurrency and Other Data Topics from Frans : IDunno@ Saturday, May 24, 2003 6:53 AM

Concurrency and Other Data Topics from Frans : IDunno

TrackBack

# re: Concurrency Control Methods. Is there a silver bullet?@ Saturday, May 24, 2003 10:24 AM

Great article, Frans! Reminds me of a Bill Vaughn quote - debating concurency resolution strategies is like arguing about where to stack the bodies after the accident, instead of putting up the traffic signals to prevent the accident in the first place.
 
Handling concurrency on the front end allows for some big optimization gains at update time, such as batch updates (in the case of editable datagrids, for instance, a user can be editing several rows at a time). My favorite strategy for that is to pass in all the update rows in XML, use OPENXML in a SP to dump them into a temp table, delete the old rows and add the new ones (all in a transaction). The same procedure can just as easily free the row locks when it's done.

Jon Galloway

# re: Why I think some people shouldn't use VSNET 2003.@ Saturday, May 24, 2003 10:47 AM

Frans, I think what you are saying essentially true, but only for Component vendors. If someone is writing a general app, then Visual Studio 2003 is preferable. I've posted some more details on my blog.

Mike Sax

# re: Why I think some people shouldn't use VSNET 2003.@ Saturday, May 24, 2003 7:46 PM

Mike: that's why I'm talking about libraries :). General app developers are also able to target 1.0 in vs.net 2003 by the .config generator in vs.net 2003 which adds redirect tags in the .config file, for .exe projects. :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Sunday, May 25, 2003 8:42 PM

Don't throw it all away ;-)

While I love to use (more VB-style than hardcore C++) hungarian notation, I completely agree with Microsoft's view on how public stuff should be named. So all my public interfaces look the "Microsoft way", internally I use HN. Nice feature: Parameters are easy to spot inside the code of a method because it doesn't use HN unlike the other local variables.

Roland

Roland Weigelt

# re: Farewell, beloved Hungarian Coding.@ Sunday, May 25, 2003 8:45 PM

That's what I did for an hour of converting interface code (I have already thousands of lines of code of this library with HN, waiting any longer would only be stupid) but it doesn't look right to me. I see your point, however for myself it was harder to get rid of the habit to write HN code when I kept local variables HN style. It's a matter of getting used to I guess. after another hour of refactoring it doesn't hurt my eyes that much anymore. :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 12:35 AM

In the devteam I work in, everybody uses the mixed HN/non-HN approach. Comparing source code of other team members (with HN used internally) with sample code from the Web (no HN at all), I must clearly say that the code without HN is harder to understand (note that this is also valid for code that is not related to our everyday work, otherwise the comparison would be biased). The worst problem is finding the difference between local variables and private data members (if people don't use the "_thisIsPrivate" notation).

There is one huge advantage of HN that I don't see mentioned often in discussions: Intellisense. Typing the first characters and then invoking Intellisense will filter the entries shown in the drop down list very nicely (e.g. "m_" for all private members, "str" for all local strings, or "m_str" for all private string members). I even add a specific prefix for controls on a winform: "c_" (followed by a VB-style lvw for listview, lbl for label etc.).

Roland Weigelt

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 12:49 AM

If you want to do it totally correct, you should use this.memberVariable instead of just 'memberVariable'. It's a bit of extra typing, but makes it more readable IMHO (but because I'm now in HN-Rehab I'm not in that phase yet ;))

The intellisense argument is definitely true, in VB and C++ it's a real timesaver, however with the mixed api naming schemes in .NET it gets a bit messy IMHO, also with VS.NET 2003 the most used name is picked first, which saves you even more time.

Your point about the control prefix is a good one, if you look closely at MS' own contradicting documents they mention a prefix for a textbox or button control here and there. I'm not sure what I'll do about that, btnOK is very logical. Just having 'ok' as variable isn't telling me anything.

Also the different typed variables which are very closely related to a single item are now harder to formulate: sometimes you have 2 variables of different types holding the same semantic value in different type formats. You can do that easily with HN, you can't with this caMel/PasCal casing. I do get the feeling though you are forced to think deeper about a name for a variable, which is a good thing IMHO.

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 2:27 AM

> I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword.

In C# you can escape reserved names with an '@', so you can define your parameter as @operator, and users of your library will see it as operator.

Fernando Tubio

Fernando Tubio

# re: Farewell, beloved Hungarian Coding.@ Monday, May 26, 2003 2:33 AM

hmm ok, didn't knew that, thanks. I think I stick with my new name for operator though. :)

Frans Bouma

# Frans Bouma's blog@ Monday, May 26, 2003 5:14 AM

Frans Bouma's blog

TrackBack

# Chad Osgood's Blog@ Monday, May 26, 2003 5:14 AM

Chad Osgood's Blog

TrackBack

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 7:23 AM

Are you suggesting to have something like pesimistic locking but without really locking the database? Like storing a row in a table that says 'I'm updating Customer #1'?

Andres Aguiar

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 7:33 AM

Yes, you use logic in your application to unlock / lock functionality in your application to perform operations. You can do this in a number of ways, f.e. in a table where you store 'locks on functionality' with a serialized transaction.

It takes some effort, but it pays off, the application will force you to focus on the organisational part of rolling out a software application which is where teh real benefits of software are found.

(similar problem: some developers complain about source control systems that they work against you when more than one developer wants to check out the same file. They forget why 2 or more (!) developers try to work on the same file, why isn't there 1 developer doing that work and they others doing other work so they prevent clashes/merge conflicts and other nasties)

Frans Bouma

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 6:33 PM

Mmm... I don't like it, it's a double edge sword....

What happens if a programmer 'forgets' to check the table? What happens if there is a totally different application that you cannot control that is using the same database?

The only way to implement it safely would be to use database locks, and we all know it won't scale.

I have some ideas, I'll blog on them as soon as I can find some time ;)

Andres Aguiar

# re: Concurrency Control Methods. Is there a silver bullet?@ Monday, May 26, 2003 6:43 PM

If you take into account what can happen when a programmer 'forgets' something he should do, any given example of good technology will fail. I don't see that as an argument. Locking parts of an application's gui or inner works because the current user is not allowed to work with it is not an easy way out, I admit. It's far easier to just let the database figure it out, which will lead to systems which are not that efficient (as I wrote). You don't need database locks. You can write a singleton which manages the 'locks'. RDBMS-es are not using different systems for managing their locks.

Using optimistic locking or similar to prevent concurrency problems is fighting the symptoms of badly designed software. It's better to design it RIGHT so concurrency problems are not an issue. If I might add: every major CMS vendor implements functionality locking, they lock in their guis editable items so other editors can't work on them while an editor is editing these items.

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Monday, May 26, 2003 10:51 PM

have you had a chance to work with firebird? With ms sqlserver becoming expensive ( 20K/cpu in a production environment? ), it provides an opportunity for a strong but much less expensive rdbms ( e.g. stronger than access and mysql ) to gain popularity.

i read the comments on the firebird site about the small footprint and fast transactions. i think i will have to download it and see what this new version is all about.

-Mathew Nolton

Mathew Nolton

# re: Firebird .NET data provider v1.0 released@ Monday, May 26, 2003 10:57 PM

Not with a recent version, I used Interbase a few years back but I don't think it's wise to compare that with todays firebird version. Like PostgreSQL, Firebird packs all the features you want (and more, it has iirc MVCC, which SqlServer lacks) from a database. I don't have the time at the moment, perhaps this weekend, to give it a testdrive. :(

If you've given it a testdrive, can you post/blog some thoughts about your experiences with Firebird? Thanks :) (so I can see if I should plan some time to dive into Firebird for my next generator toolkit or shouldn't)

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 2:13 AM

Hello:

>so I can see if I should plan some time to dive >into Firebird for my next generator toolkit or >shouldn't

Oh!! if you mean to add Firebird support to LLBLGen this could be great!!!

For me Firebird is great, it's really stable and fast, and it has all features i need ( referential integrity, triggers, stored procs, transactions, ... ), really good admin tools, and it's multiplatform and .......... :D

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 2:21 AM

Yes I mean support for Firebird in the next release, the O/R mapper variant LLBLGen Pro. I can't assure support via the initial shipment of the first version, but I can add support easily after that via a template/driver-addon update. Consider it on the 'essential items todo' list :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:07 AM

Did you see my blog on Serialized UIs? http://dotnetweblogs.com/donxml/posts/7441.aspx Have you read up on Avalon in Longhorn? Sure sounds like your vision is the same as mine, except the definition of a 'browser'. The line between WinForms and WebForms is being blurred by advancements in Longhorn.

DonXML

DonXML

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:18 AM

The 'browser' as an application should go away, iexplorer.exe should not live anymore. That's the idea I was talking about. This will not be possible with a flip of a switch (unfortunately ;) ), but if you ask me, I really do not see the relevance in the future for 2 'forms' namespaces, there is one gui: the desktop (or handheld or whatever).

I hadn't read your blog about serialized guis nor read about avalon (I only saw some screenshots on the windows supersite). What triggered me to write this blog was your remarks on how it should be rendering XML using namespace engines and the like. All neat, but that's not the problem, because with another rendercontrol it can be embedded in IE now. The concept should change, not which rendering engine should be used. (because to me XML is not about visualization, but about datastorage following a structured definition). But perhaps I'm missing something essential which will cause that what I think should be done will never happen :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:32 AM

We are on the same page, but our definitions aren't exactly the same. This is a new world, and until we get a standard definitions behind the ideas, that's bound to happen.

DonXML

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:35 AM

Hmm I think you're right.

I hope that the W3C isn't involved in next-gen webapplication gui definition standards though.

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 3:56 AM

What the hell are you talking about? WinForms and HTML share something in common - developers must control the positioning of various UI elements, i.e. controls. IE *does* have them - the HTML Common Controls. You can even use them in your own apps...including WinForms. IE6 on XP with Visual Styles enabled does, however, bind to CC6, in which case the controls are actually the Windows Common Controls.

Why did GUIs starting hosting in web browsers like IE and Mozilla - because graphics representation has long-since evolved and the methodologies to do them really hasn't. IE already takes care of all the rendering with very little work by a developer to re-invent the wheel to display nice-looking GUIs. Comparing the easy layout capabilities of HTML to Curses is a joke! Sure there are problems when using HTML for your only GUI (InstallShield Developer and Microsoft Money come to mind) but those are overcome by writing simple ActiveX components and implementing your own hosting interfaces, which is still a *lot* easier than rewriting everything like that yourself.

The web is an evolving thing and if browsers don't evolve with it, then *we'll* be the ones re-inventing technologies. Isn't it better than a single organization does it, tests it, supports it, and basically implements a "standard" that everyone uses?

Heath

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 4:00 AM

This sounds eerily similar to the Java-applet view of the future we heard in the mid-90's.

BTJ

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 4:04 AM

Heath: yeah yeah, but I'm not talking about the LOOKS, I'm talking about functionality known for years in f.e. win32 and now winforms which are not possible (or better: are much harder to develop) in HTML if ever possible. I'm not talking about Foo Inc. and their 2 page website with a mailform, I'm talking about webapplications with sophisticated GUI's which are hard to develop in HTML using IE and easy to do in winforms. The main reasons: HTML is markup, not a gui definition language and HTML works disconnected, while it shouldn't.

BTJ: I'm aware of that it sounds familiar :) Java had the disadvantage that the internet was not as connected as it is today: people dialed in via modems, today they have cable or ADSL and are always online, which blurs the separation between apps running elsewhere and locally.

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 6:05 AM

Hello:

> Yes I mean support for Firebird in the next > release

:D There any expected date for the release of the next version ??

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:21 AM

Until Microsoft supports or makes an official statement regarding its position on projects like Mono, I would not count on the CLR and .NET to be a viable cross-platform development environment. Remember, the CLR may be an open standard, but the .NET framework is not. There is nothing stopping Microsoft from suing projects like Mono and DotGNU and that is enough to keep me away from thinking about .NET as a solid cross platform solution.

Joshua Hoover

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 7:29 AM

"soon" :) I hope before august.

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:40 AM

See my url, we are on the case!

Kingsley Idehen

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 7:46 AM

Kingsley, cool :) I read somewhere the HWND issue is/was a bit of a problem with mono winforms, but if that's been fixed, I think mono will have a decent winforms implementation, which opens up a whole new ballgame :) Good stuff, Kingsley, keep up the good work :)

Frans Bouma

# re: Firebird .NET data provider v1.0 released@ Tuesday, May 27, 2003 8:34 AM

Hello:

Thanks and keep up good work :D

Best regards
Carlos Guzmán Álvarez
Vigo-Spain

Carlos Guzmán Álvarez

# DonXML Blog@ Tuesday, May 27, 2003 11:34 AM

DonXML Blog

TrackBack

# DonXML Blog@ Tuesday, May 27, 2003 11:34 AM

DonXML Blog

TrackBack

# Read/Write Web@ Tuesday, May 27, 2003 11:34 AM

Read/Write Web

TrackBack

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 5:57 PM

You got some points but I don't think you could expect to see Winform support "all over" in some time.

If you only target Windows user with the latest Microsoft OS then Winforms is great. If you plan to target other users then web might be the way to go.

Also...the web is no longer meant for stateless applications. You got many ways for implementing persistence in most web application frameworks. However, the applications are much harder to develop on the web.

Viking

# Tim Berners-Lee@ Tuesday, May 27, 2003 9:40 PM

Just for the record, Tim Berners-Lee made the first web browser... not Andreessen!

bruce

# re: Don't try to re-invent the browser, please.@ Tuesday, May 27, 2003 9:49 PM

hmm, in that context, what *is* a browser then? since with gopher you also could traverse hyperlinks (sort of). Berners-lee did indeed invent a tool/format to hyperlink texts, however the concept of the browser as we know it today is not made by Berners-lee afaik, but by Andreessen and his team at NCSA.

Frans Bouma

# About the indenting...@ Tuesday, May 27, 2003 11:01 PM

I think it removes the tabs if you choose to <enter> another line down because a lot of people (me included) dislike lots of whitespace on otherwise empty lines. If you want it to redo them when you move upward that could cause some really funky stuff when you're just cruising the sourcefile looking for something to copy and you see the cursor jumping around to each line's "next logical place to insert stuff" :)

I agree with the rest though, especially the compilation issues.

Jeroen

# re: My wish-list for the next Visual Studio.NET release@ Tuesday, May 27, 2003 11:08 PM

Yeah, the whitespace is indeed a burden. However, the editor knows it should indent when hitting enter, the editor could simply look at the indentation of the line ABOVE the current line (if the current is empty). Ah well... :)

Frans Bouma

# JonGalloway.ToString()@ Wednesday, May 28, 2003 5:51 AM

JonGalloway.ToString()

TrackBack

# re: Don't try to re-invent the browser, please.@ Wednesday, May 28, 2003 5:53 AM

Nope, TBL definitely bulit the first web browser as we think of it today. The team at NCSA just built a better one.

The reason people like myself are crying out for an update to IE is that it still doesn't support the current batch of standards to an acceptable level. It doesn't even support all of HTML yet (the <abbr> tag springs to mind), it's CSS2 support has a distance to go and the sooner they support alpha transparency in PNGs (which was standardised in 1996) the better.

I'm interested in the rendering engine, not the browser. As it is, I use Gecko engine browsers (currently Firebird) and can't really see myself moving back to IE even if its end user functionality (tabs, popup blocking, typeahead find and so on) caught up. It's just too convenient having a browser that I can install on any operating system I care to use.

Simon Willison

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 7:28 AM

Your list is great! I'd like to add one minor thing:

Give us an option to either: remove the "Add Task" line from the task list or possibly move the "Add Task" line to the bottom of the task list.

Visual Studio takes up so much screen real estate - the add task line takes up so much room for something that I never use.

DM

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 10:24 AM

Re Error harvesting. Long ago I worked on with a PL/1 compiler that attempted to continue after errors. It had to assume what you meant to say instead of the error, and one wrong assumption generated a mass of meaningless errors.

Be careful what you wish for!

David

# re: My wish-list for the next Visual Studio.NET release@ Wednesday, May 28, 2003 8:29 PM

David: heh yeah, I remember those days with the Sun 'CC' compiler when you forgot a ';' all hell broke loose. Fixing that ';' and all errors went away. :) However, what I ment was clearly repetitive errors which can be found but are now skipped. But indeed, we should be careful what to wish for :)

Frans Bouma

# re: Farewell, beloved Hungarian Coding.@ Thursday, May 29, 2003 4:15 AM

I was a strong proponent of using the "this->" convention for C++, but with C#, I don't see the point. There are no free functions, so you are either referencing a member function or a function in another object. So saying this.DoSomething() no longer adds a lot of extra readability/information for me.

I am torn on the notation subject. I don't, and never have, liked Hungarian to annotate the type of variable referenced. But I do like it to indicate purpose. m for member, a for local, in for input parameters, out for output parameters, k for constant, s for static. These add meaning and context to me. Dropping the a for local is not a big deal to me, but when I loose the context of input, output, and members. Then I start to have more of an issue.

I try to work both ways to get myself used to no prefix context. But it does hurt.

Jim Argeropoulos

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 5:10 AM

Hi Frans,

I used your previous version on one or two projects and really liked it. One question though....what type of price range was you thinking for your next release?

Or is it too soon to say?

Thanks

John

John

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 8:40 AM

Bindable entities by implenting a binding interface upon a business entity... hmm looks farmilair ;)

Frans you thought about entity v.s. value objects? When is an object considered to have an identity and presumable be and entity? Or an object with no identy presumable a value object(depending on the object context?).

Paul Gielens

# re: My wish-list for the next Visual Studio.NET release@ Friday, May 30, 2003 8:49 AM

About the help tab: I find it much easier to use external help. Then I can use Ctrl+Tab to switch between editors and Alt+Tab to switch to the help window and back.

Dan

# re: A quick update on LLBLGen Pro@ Friday, May 30, 2003 8:56 AM

John: around 175 euros incl. VAT for a site license, thus unlimited number of developers can use that license in your company.

Paul: Entities are the elements you focus on when you design an ORM/NIAM model, thus f.e. the tables in your database. The entity classes talk about the same entities as the entities found in the database, they should be the same.

Besides these entities you have views defined over a number of attributes of a collection of entities. These are also supported (typed datatables).

Frans Bouma

# Emitter@ Friday, May 30, 2003 9:03 AM

Emitter

TrackBack

# re: Entity: why do some people who write IT books re-invent definitions?@ Saturday, May 31, 2003 2:06 AM

Evans, Domain Driven Design
@ http://www.domaindrivendesign.org/book/

This is NOT Fowler... I added Fowler as a ref because of his thinking about identity maps. I'm just telling there's a difference between objects that have an identity (entities) and objects that don't (value objects). This makes a BIG difference within domain models and because LLBLGen Pro seems to generate large parts of the domain model as well... Read a few lines in Evans's manuscript and perhaps we'll conclude we are thinking 1:1 but blogging the other way around.

Paul Gielens

# re: Entity: why do some people who write IT books re-invent definitions?@ Saturday, May 31, 2003 2:15 AM

I don't see why people have to be focussed on a difference, of course they are different: one is defined in the persistent storage as an entity and the other one isn't. Value objects are views, collections of attributes which do not have a semantic meaning, entities do. The definition is over 25 years old, but in the definition you quoted, an entity embeds logic: they encapsulate operations. Which is wrong, the logic is embedded in code outside the entity, the entity using code.

Frans Bouma

# Frans Bouma's blog@ Saturday, May 31, 2003 7:25 AM

Frans Bouma's blog

TrackBack

# XUL is the future - The Desktop War is Heating Up @ Sunday, June 01, 2003 10:29 AM

Wonna see the future today? Check out XUL (XML UI Language) @ http://xul.sourceforge.net

HTML was the markup for the browser. XUL is the markup for the desktop. The browser war is over, but the desktop war is just getting started.

Gerald Bauer

# re: About sharing Intellectual Property, USP's and Patents@ Tuesday, June 03, 2003 1:43 AM

Lol, my girlfriend is studying commercial economics (marketing), so this basically means we’re in the same boat.

Is your wife participating in the marketing offensive for LLBLGen Pro?

Paul Gielens

# re: About sharing Intellectual Property, USP's and Patents@ Tuesday, June 03, 2003 1:55 AM

hehe same thing indeed! :D

She helps with the positioning of the product, the formulation of the USP's, basicly to make it a product that appeals to a wide range of people instead of just die hard nerds who live in a code-editor all day. :) Research of target audiences, analysis of what they really want is very important, because no-one wants to develop a tool that is perhaps kick-ass but is not used by a lot of people because the target audience wants other things than you deliver :)

It's very funny how developers always try to avoid others messing with the specs of what they have to write but at the same time developers are also very busy to convince marketing people that the developer knows everything about USP's, what's really important to the user etc. :) The best software is still written by developers who have convinced themselves that stuff like "It just works (tm)", "it does what people want it to do" and similar phrases, are the true sellers of software and not feature number 10987342 which is used by 0.001% of the user-base :)

Frans Bouma

# The Bleeding Edge@ Tuesday, June 03, 2003 6:33 AM

The Bleeding Edge

TrackBack

# re: Microsoft, developer editions should be free.@ Wednesday, June 04, 2003 10:09 PM

I agree Frans, but at least it's much better than the original tag price, and it will certainly appeal some new database developers.

Paschal

# re: Microsoft, developer editions should be free.@ Wednesday, June 04, 2003 10:25 PM

I didn't even know the original price tag was that huge :) (a MSDN subscription makes you lazy I guess ;) ). There are a lot of developers in the world who do not have a lot of money but do know how to code (and are now working with free tools to write their .NET code). If MS truely wants to win the 'war' against Open Source and free tools, they should act better. But ok, it's a start, that $49.- .. :)

Frans Bouma

# re: Microsoft, developer editions should be free.@ Thursday, June 05, 2003 1:59 AM

I seem to recall that the shipping on that free Oracle copy is pretty pricey, though - wasn't it in the neighborhood of $35 for a full set of CDs?

Mike Gunderloy

# re: Don't try to re-invent the browser, please.@ Thursday, June 05, 2003 11:17 PM

Maybe we do not all have the same use of HTML. Said simply: If you think I'm going to develop my web site using web forms, then you are dreaming. I think, you are talking about different things, different needs.

jonx

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:04 AM

thats still not on the desktop dude.
and quite frankly i dont think the bulk of the mono effort is centered towards desktop applications.

Tq

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:36 AM

Frans, the problem is more on the user experience. And believe me, I tried with non developers people, it's a nightmare.

Installing Linux properly with 10 people sharing the same network is not really there.

And I like Linux, but as a developer and for some specific applications. ;-)

Paschal

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 12:42 AM

It can be tough to setup, I know :) I've worked with Unix for a few years so I could manage, but indeed, if you're used to 'C:' and nicely layed out folders, you get confused rather fast. However, if the boxes are setup ok, like: the user sees a desktop with open office on it, it can browse corporate folders shared on a server (which are mounted as a folder, great system), work with the files and read/write email, there is not a lot they can screw up. Most people in offices spend their day in office applications, so if you can make the box to be good at doing that, a LOT of businesses can use linux at the desktop today.

Mind you: even today a lot of businesses are on win9x/winME, and that's no picknick either ;)

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 1:21 AM

Frans, one term says it all: TCO.

So Linux can read/write MS Office docs. Problem is, you STILL have to retrain every single user to use some very separate apps there.

Virtually every shop out there with predominantly MS desktops will have to retrain their support too. Nowadays the help desk is a decent percentage of TCO for a company.

Seems the EXACT same argument was being made back in 1998-1999. You know, the old "we have apps" and "we have better security" and "bug fix releases come quickly" and "the purchase price is next to nothing". And Linuz since then has what? Moved from 2% market share to 3% on the desktop?

TCO, bud.

Dave

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 1:32 AM

Retraining is an issue indeed, however is there a clear view on this, how much the impact is? I think it greatly relates to the level of computer savvyness of the user. A word processor isn't that hard to work with, type, select font, save, print. However, support has to be retrained and that's costly, but even then: when your organisation is on NT4 + win98 and now moves to win2k3 server + winXP, it's day and night for both support and end user. THere, too, support personel has to be retrained to get the most out of the platform. I don't know if that retraining will be that much different from the retraining of the sysadmins to work with /etc files :)

(after all, linux or FreeBSD for that matter, isn't anymore at the level of 1998, 1999, where it was a mess. A lot of the configuration files have now gui applets, are better documented and there is overall better documentation. It still takes some effort, but I still believe its ready for the desktop and it can be worth it. With Mono on linux, (if everything pans out correctly), applications written for windows (desktop apps) can work on mono on linux as well, which makes the switch worth it.

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:21 AM

The problem is not technical. Even if Linux was easier to install and had everything an end-user would need, they will need:

- A worldwide distribution model. MS has it, and is very difficult to build.
- Make the internal help desks and support center to support Linux. This is _very_ hard to acomplish. The companies invested _a lot_ of money in training people with Windows technologies
- Books, training courses.
- Partners that can make money on it. There are much more ISVs in the Microsoft arena than in Linux's
- Probably more reasons ;)

Andres Aguiar

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:52 AM

Interesting article in the last InformationWeek: http://www.informationweek.com/story/showArticle.jhtml?articleID=10100565

"More than a third--38%--say Linux's greatest weakness is the limited availability of business applications for the operating system, up from 32% a year ago. Nineteen percent say the proliferation of different flavors of Linux is a problem, up from 12% a year ago, raising the fear of incompatibility among the various versions, as happened with variants of Unix."

And not to mention the pending legal action from SCO, which undoubtedly is going to have some impact. Already, there are analysts (I think Gartner but I may be wrong) that have cautioned against using Linux at all right now in the face of that action.

Tim Marman

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 2:55 AM

Duh. If I read Randy's original post, I would have realized that it was Giga and not Gartner who said that :)

Tim Marman

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 4:36 AM

I don't know how many of you have used Lindows, but Lindows is VERY usable. My mom -- which is not quite techno-phobic, but definitely a hard sell -- would be comfortable with Lindows.

However, I disagree that Mono will make the shift. The only way that could happen is if they had a 100% solid Windows Forms implementation, so there could be desktop app compatiblity. Not only is Ximian not interested in doing it (someone else is), I have grave doubts that anybody short of a team of dozens, maybe hundreds, of Windows _experts_ could ever pull it off. Windows is a moving target, as Wine has showed, and Windows Forms is so leaky an abstraction that it's impossible to forget that there's Windows underneath.

Brad Wilson, The .NET Guy

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 4:41 AM

Brad: windows forms is such a pain because it is based in HWND's and messages when you want to do tricks (and who doesn't). If you can create an api that has the same interface as system.windows.forms, but calls into the gnome/kde libs, it will work. If mono isn't gonna do winforms, it will indeed be something else that needs to make the shift. I also don't see why a winforms implementation should use wine or a win32 imitating layer, everything that's needed is already there, in X.

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 7:03 AM

Maybe everyone knows the basic functionality of a word processor or a spreadsheet, but it's the power users who know the shortcuts. Where MS flat out beats the competition is standardization of everything.... toolbars, menu shortcuts, ... even a unified scripting language.

These power users do alot for a company. They heavily influence perceptions. They are the most highly productive employees. They deal with the brunt of questions that the help desk would otherwise have to.

Compare your arguments for Linux to those elitists who insist on tableless layouts in websites. In a sheltered corner... weblogs made by us geeks and read by us geeks who generally have standards-compliant browsers... this sort of stance works fine. In the real world... businesses strapped in bad economic times seeking every dollar of revenue from other companies whose lack the support to upgrade their browsers or connections... is it any wonder CSS still hasn't caught on?

Dave

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 8:31 AM

Anyone else notice that the linux guys only halfway decent products are the ones they clone from MS or some other commercial company? Then, they say they hate MS, because they just steal stuff from everyone. Some people have a bad case of Robin Hood syndrome. I would hate to see the day when commercial commercial software companies cease to exist... there wouldn't be any cool products to clone anymore. :-)

Jesse Ezell

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 9:06 AM

errr, doesn't every software company clone aspects of others? I don't know, but 'Excel' isnt a microsoft invention, nor is 'wordprocessor' or even wysiwyg wordprocessor :)

Frans Bouma

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 9:21 AM

Mono is far, far... far from ready. Besides Mono is claiming an independant framework and not a 1:1 copy for .NET. And what'll happen with Mono once MS releases .NET 5.0 concerning compatibility? I can't imagin commercial companies taking such a risk for serious apps.

Paul Gielens

# re: When Mono is completed, Linux is the option for the desktop.@ Saturday, June 07, 2003 11:45 AM

I don't think Mono will be enough. I think it will increase Linux's viability as a server platform, but not for desktops. The availability of good applications and good support for end users is the key there.

randy

# re: Optimization the right way: optimize your algorithms@ Sunday, June 08, 2003 4:38 AM

Interesting article, I like your approach. At the end of the day we use dotnet for speed of development, who has the time to think about the msil and low level optimisations ?

Gotta respect the demo programmers anyway, if you could get such amazing effects out of an amiga or an st we should trust you when it comes to dotnet :D

OmegaSupreme

# RE: Windows.Forms on Mono@ Monday, June 09, 2003 7:56 AM

I'll be very happy if we can get to a point where most .NET desktop applications will run on Mono , but it's not going to be easy. The problem is indeed Windows.Forms, as Brad Wilson said.

The mono WinForms implementation IS based on Wine, and is thus is limited by the extent of Wine's Win32 coverage. As Brad said this is always going to lag by a certain amount, although I hear it's currently good enough to run MS Office and StarCraft (GTA 3 soon, apparently)

Frans: I watched the mono WinForms mailing list go over and over the question of whether their implementation should be based on Wine or not. What it came down to was that anyone who had *really* looked into it found out that WinForms is *such* a leaky abstraction that you couldn't do it without emulating at the *very least* all the message pumping behaviour of Windows.

The other problem is that (in the main) the only ppl who really know how WinForms works are old Win32 developers, who understand what is going on beneath the abstarction. These ppl are the only ppl who are going to be able to write a reasonably compatible implementation of WinForms in a reasonable amount of time. Unfortunately, they don' t (as a rule) know GTK/QT/X, and generally are used to programming on Windows. I think the wine-based WinForms implementation is going to flesh out a lot quicker than any non-wine one could.

So, as it stands, to run WinForms apps, you'll need Wine. For all non-WinForms apps, though, mono should be great.

In the end, I think this is a shame. When I first heard about Mono, I was thinking about how great it would be to just be able to run Windows apps on Linux. I've since seen that this probably won't happen (seamlessly). What you CAN do, however, is write a cross platform non-gui app, or even a cross-platform gui app by using GTK# or QT# (& I think there is now a SWT port as well).

Wow, I've written too much. I'll shut up, now!

Swythan

# re: A quick update on LLBLGen Pro@ Tuesday, June 10, 2003 9:26 AM

So, Frans, when are you going to add the SQL CE option? That would be really sweet!

Darren Pruitt

# re: The 'benchmark' code@ Thursday, June 12, 2003 6:32 PM

Frans,
Here is my test on a Celeron 1.8 running XP Pro. I can run more tests against separate servers later.

The dynamic query wins by 17 seconds.
Dynamic - Total time: 00:01:33.5845680.
StoredProc - Total time: 00:01:50.7292208.

This is good news, since I am building a routine to copy data between tables on different servers using DB2/400. The class uses a select statement to retrieve the source data, then creates an insert statement from the source dataset for the target.

I wanted to handle this for many tables and potential libraries and did not want to create and manage all the stored procedures. I don't care if the table structures change and have a generic copy routine.

I will wrap this in a web service and use it to copy policies between our production and test libraries that reside on separate servers.

I enjoy reading your common sense and practical articles and comments.

Ron

Dynamic query benchmark
Benchmark started on: 6/13/2003 12:14:45 AM.

Benchmark ended on: 6/13/2003 12:16:19 AM.
Total time: 00:01:33.5845680.
Amount of runs: 10000. Max. amount of rows retrieved: 830
Stored procedure benchmark
Benchmark started on: 6/13/2003 12:16:19 AM.

Benchmark ended on: 6/13/2003 12:18:09 AM.
Total time: 00:01:50.7292208.
Amount of runs: 10000. Max. amount of rows retrieved: 830

Ron Steiger

# re: Feeding the trolls@ Friday, June 13, 2003 8:32 AM

Please don't take my post as an attack on anyone. It was just a satirical take on Scott's bloodbath of rage.

Marc

# re: Feeding the trolls@ Friday, June 13, 2003 9:12 AM

Oh, come on Frans. Lighten up a little. Scott's post was funny, and given how frequently self-styled "industry authorities" hold forth about things about which they clearly know nothing, such responses are a harmless bit of venting.

I would agree with you that responding with ad-hominem insults to every ignorant opinion column you read would be excessive, but a choice response to the particularly egregious can be healthy, IMO. No harm in letting off a little steam occasionally.

G. Andrew Duthie

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:23 AM

Good story Frans! If it makes you feel better, I have also wanted to gather a couple of static functions under a contract and realized that it wasn't possible. I also felt somewhat "ashamed" afterwards, but what the heck, it's not the end of the world.
:-)

So, what solution did you choose? Skipping the interface or skipping static?

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:24 AM

lol, this really sounds Familiar to me....

Jonne Kats

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:30 AM

Frans, you seriously disappointed me ;) No clue what methodology you use, but eXtreme Programming (XP) would have trapped that issue probably in the first iteration. Start prototyping dude!

Paul Gielens

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:30 AM

:)
I skipped the interface. The static methods are really handy, since they're one shot calls, so having an object for just 1 call is not that handy. :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:31 AM

Paul hehe I'm not gonna bite! am NOT! :D :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:33 AM

Hehe, wasn’t my intention… just a little teaser ;)

Paul Gielens

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:37 AM

I know ;)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:50 AM

Your implementation SCREAMS Factory Pattern. It's what I use in GenX.NET when I deal with my OutputProviders without needing to know which provider I am using. I'm going to be writing a Factory Pattern tutorial sometime early next week, after I RTM GenX.NET 3.0. Until then, don't scrap your code.... you're just missing one more piece to the puzzle.

Any BTW, you didn't make a fool out of yourself. It can be done.

Robert McLaws

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:53 AM

Also, I know this method would be perfect because GenX.NET uses it for the exact same reason... specific implementations for specific databases. Believe me, understanding this method will take your coding to a whole new level.

Robert McLaws

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 12:56 AM

Robert, I do use a lot of factories, I have the GoF book. :) In my DAO objects (using the DAO pattern) I simply want to call IActionQuery query = DynamicQueryEngine.CreateInsertQuery(//...);

Which one is based on the using directive at the top. This is generated code, so I only have to change 1 line to make it work with Oracle f.e. and the generator generates Oracle code. I understand that when I create the DAO in the DAO factory I can also create the right DQE object and pass it to the DAO, but that's not that efficient because these DAO objects are not living very long. A static method is then more appropriate. Admitted, it can be done using a factory, but a static method in this case is more efficient I think. It's not a big deal, the templates used for the code are closely related to the DQE and the database driver used, so it's a complete package, but I was just wondering if I could create an interface for this, but I couldn't. :)

Frans Bouma

# re: Sometimes, the human mind acts in mysterious ways@ Saturday, June 14, 2003 1:03 AM

Robert: I don't have a central cache system where I can store generic objects, so I can't cache these kind of objects like the DQE. If I could, I definitely would have used the factory route. But now I can't. Image that when I load 2000 customer objects in memory. Then I have 2000 times created the DQE. That's pretty amazingly inefficient :)

But I appreciate your thoughts. You definitely understand what's required for good OO software :)

Frans Bouma

# re: Finally my own skin@ Saturday, June 14, 2003 4:17 AM

The menu and title aren't visible .. Change the color of the text also ;)

Best regards
Marcus

Marcus

# re: Finally my own skin@ Saturday, June 14, 2003 4:22 AM

hehe I know :D I had a margine defined somewhere that bugs the crap out of it. I've almost fixed it :D (famous last words)

Frans Bouma

# Mozilla@ Saturday, June 14, 2003 4:27 AM

Don't forget to test on Mozilla. I'm almost positive what I'm seeing is not correct, using Mozilla Firebird 0.6. :-D

Brad Wilson, The .NET Guy

# re: Finally my own skin@ Saturday, June 14, 2003 4:31 AM

good tip, thanks :)

Frans Bouma

# re: Finally my own skin@ Saturday, June 14, 2003 5:38 AM

I second the Firebird problem. The horizontal lines in the left column extend out of the left column and into the content area a bit.

sirshannon

# Emitter@ Saturday, June 14, 2003 6:05 AM

Emitter

TrackBack

# re: Finally my own skin@ Saturday, June 14, 2003 6:09 AM

phoenix/firebird's lines are fixed. Now I only have to battle with the borders below and at the right which seem to appear in firebird but are not there in IE (MyIE2).

Opera doesn't eat the javascript btw. Not that I care, but perhaps there is a solution. It doesn't understand the createElement statement.

Frans Bouma using Firebird

# re: Move away from stored procedures or not?@ Monday, June 16, 2003 12:41 AM

Very interesting points. In most of the corporate systems, if code is considered to be the the crown-jewels (assets) then *stored-procedures are surely the diamonds. I think there'll be conversion utilities (*SPs into embedded code) to help transition (if any) but it will still rest with the performance of the system. In addition to security, most of the *SPs are valued for performance while handling high volume transactions - if it can shave off a few millisecs then it'll certainly get serious consideration. Good post Frans.

SBC

# re: Move away from stored procedures or not?@ Monday, June 16, 2003 10:33 AM

Views are great. Indexed views are even better. Too bad SQL Server 2000 Enterprise is so damn expensive!

Travis

# mads studentblog@ Monday, June 16, 2003 10:39 AM

mads studentblog

TrackBack

# Andres Aguiar's Weblog@ Monday, June 16, 2003 10:39 AM

Andres Aguiar's Weblog

TrackBack

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 4:35 AM

Any plans for two-way tools a la DeKlarit? If not, what is the process for updating the DAL as the database changes across releases of software?

--Bruce

Bruce Onder

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 4:39 AM

No, there are no plans for two way tools, since these can be pretty problematic. When the database changes, you simply refresh the catalog view, LLBLGen Pro will enlist the classes, typed lists and other elements which are changed because of the changed database and you can apply these changes then, regenerate the code, and are set.

Frans Bouma

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 11:47 AM

Okay. I like some of the features DeKlarit has, but I agree with you that these can be problematic.

I ran 1.2 on Northwind with no problems. I am next going to run it on the database created by my current DeKlarit project and see how the code looks there. :)

--Bruce

Bruce Onder

# re: A quick update on LLBLGen Pro@ Tuesday, June 17, 2003 8:50 PM

Which features do you like of DeKlarit? Can you describe them a bit? Perhaps LLBLGen Pro already will support them :)

LLBLGen Pro is in every word a successor of LLBLGen v1.0 so it is not a simple upgrade, it is a new tool with a broader functionality spectrum, which means that the functionality of v1.0 is extended and re-implemented and new functionality is added. The concept of what the generator will generate is moved upwards, from the DAL to the DAL + BL Facade, which is now integrated. :) (hmm, I'm starting to sound like a person from marketing ;))

Frans Bouma

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 1:44 PM

In theory I like the fact that Deklarit lets me focus on the object model and builds the data model behind the scenes for me. In practice the tool is a bit hard to use, but this is IMO user experience.

For example, in DeKlarit I can create the following entity:

Client
ClientID (PK)
ClientName
TransactionID
TransactionDateTime
TransactionAmount
ClientBalance (sum(TransactionAmount))

This will produce two tables for me, Client and Client1. It would produce a Transaction table only if I created a separate entity (what they call a business component, which i feel is a misnomer) called Transaction and had those same property names in it (Deklarit uses name/identity equivalance on properties).

Bruce Onder

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 1:48 PM

oops, the transaction* properties should be indented a few spaces to show they are a level inside of the Client entity.

Bruce Onder

# re: A quick update on LLBLGen Pro@ Wednesday, June 18, 2003 2:39 PM

Will there be strongly typed tables in 2.0?

Bruce Onder

# re: A quick update on LLBLGen Pro@ Thursday, June 19, 2003 6:53 AM

There will be strongly typed tables, so called typed lists. These can be designed in the tool (the columns and the list of entities to retrieve them from) and contain filters in code, so you can filter on the list at runtime. These are typed datatables.

I'm a strong believer of abstract modelling of datamodels, by using NIAM or ORM (see http://www.orm.net). Therefor modifying a database in LLBLGen Pro is not necessary since the database is created using an E/R model that is derived from a NIAM / ORM model created by a software architect.

LLBLGen detects automatically relations between entities (1:1, 1:n and m:n) and adds properties to retrieve related data automatically. So you can walk these relations by simply pressing the '.' :) -> CustomerEntity c = new Customer("ABC");
string ProductName = c.Orders[0].OrderDetails[1].Product.Name;

All lazy loaded. Also available in a datagrid, you can bind c.Orders to a datagrid and walk the complete model from there, in your grid :)

Frans Bouma

# re: Harry Potter reloaded@ Saturday, June 21, 2003 9:10 PM

You're joking right ;)

Paul Gielens

# re: Harry Potter reloaded@ Saturday, June 21, 2003 11:10 PM

No :) Harry Potter rocks. At first I thought "but... that's a kids book", but that's not true, the books are very funny, you should read one :)

Frans Bouma

# re: Harry Potter reloaded@ Sunday, June 22, 2003 1:00 AM

Never read "one" myself so I better not comment directly related to the book. Although in a twisted way it's quit funny, just imagine reading a book of Harry P. lol Get your sorry ass on the beach in Scheveningen Frans and enjoy the weather reading some serious garbage like the Panorama or even more worse, the Privé ;)

Paul Gielens

# re: Harry Potter reloaded@ Sunday, June 22, 2003 1:06 AM

hehe :) We have all 5 books of HP, and when you start reading one, you can't stop. It's not written like a kids book, it's readable :) and the beach? Are you nuts? It's raining here :)

Frans Bouma

# Emitter@ Sunday, June 22, 2003 7:26 AM

Emitter

TrackBack

# re: A quick update on LLBLGen Pro@ Sunday, June 22, 2003 9:38 AM

Nice! Hurry up, summer! :)

--Bruce

Bruce Onder

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:33 AM

Nice work Frans!

Chad Osgood

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:36 AM

Thanks :) Most of the work done is behind the scenes, this is the first time I can actually show something that is visually attractive and somewhat interesting. :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:38 AM

Very nice UI. Is that the Magic library from Cronwood?

Patrick Steele

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 10:42 AM

Yes, that's the magic library. I haven't used all of its power though, but it is a very handy library for dynamic gui building, you can create powerful gui's in no time. :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 11:13 AM

Yeah, I've done some prototyping with it and it's a very nice package for the price (free!).

Patrick Steele

# re: Create #region macro for C#@ Monday, June 23, 2003 4:38 PM

If you are looking for a tool to quickly place templated code such as regions or properties take a look at QuickCode.Net I have been using it for a while and I like it.

Wes Haggard

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:03 PM

It is looking great..
Will we see any beta's or opportunities to test :-)

Keep up the good work

Michael Hensen

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:09 PM

There will be a short beta cycle of course :) I haven't decided yet if that will be a closed beta or an open beta. Of course there will be a trial version when it's released :)

Frans Bouma

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:09 PM

I use LLBLGen alot, a great time saver. Looking at that screenshot and feature list though, guess I'm gonna have to scrape together a few bucks this time. Go easy on us here in Africa though ;-)

Senkwe Chanda

# re: LLBLGen Pro screenshot@ Monday, June 23, 2003 9:18 PM

Senkwe Chanda: :) I'll do everything I can to make the price as low as possible. It will already have a site license instead of a per-seat license, so you pay 1 price and all the developers in your department can use the tool. It will be around 150-170 euro.

Frans Bouma

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 7:26 AM

Exciting, "generates a complete O/R mapper framework" is just what I wanted to know! I hope that our discussions about OR Mapping will be expressed in tool supremacy!

Heads up!

ps: What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?

Paul Gielens

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 8:30 AM

"What happens with heavily normalised models? Is your tool "smart enough" to let the end user be the director of what to do with what in contradiction to many, many commercial tools out there?"
I know what you are refering to :) but I kept the 1 table per entity restriction. However, it shouldn't be a problem, here is why: at the left you see f.e. a relation between employee and customer, over the entity order, a m:n relation. The tool finds these relations which are not obvious to the user. ('orders' is not an intermediate table between the employee-customer relation, the relation is created using 2 1:n relations).

It is possible to navigate from one entity to any other entity in the system, using the relations. The code generated will embed as much logic as possible to make you navigate/retrieve related entities from any entity you currently have an instance of. So heavily normalized databasemodels are not a problem, you can navigate to any related object without a problem.

Not in the screenshot, because I have to create the designers yet, are the typed lists. These are read-only typed datatables based on entity definitions, which can span more than 1 table/entity, f.e. all orders with the customer fields joined with every row. So for data-retrieval, where bulk data has to be retrieved which spans more than 1 table, you can define typed lists, and the typed list code embeds rich logic for filtering and clever instantiation.

Every entity definition has also a typed collection (hi mr. Fowler!) which embeds logic to work on groups of entities directly in the persistent storage or in the collection itself (and is bindable too :))

I'm pretty sure that on the DML front, you can work easy with the entities and the relations between the entities (plus the dynamic query engine and the filters you can define to retrieve groups of objects also f.e via filters on related objects.), and on the data retrieval front, you can work with indivitual entities, the entity collections or with the typed lists.

I also implemented stored proc execution as a bonus for people who have stored procs they want to embed (select sp's only).

Frans Bouma

# re: LLBLGen Pro screenshot@ Tuesday, June 24, 2003 8:33 AM

(oh, the typed lists use the dynamic query engine and you can f.e. define a dynamic query using the same logic in your own code if you like. Yuo then can retrieve the data in a normal datatable, but the overall flexibility is there. ).

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 1:43 AM

Hi Frans

I recently created tool to generate NAnt build files based on VS.NET project files. If you're intrested check out my post: http://weblogs.asp.net/jan/posts/9255.aspx

Greetz
Jan

Jan Tielens

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 1:46 AM

I've read that posting, thanks for the heads up :) I haven't tried it yet, I already made nmake files for the project I'm currently working on, but for the next time I'll consider it.

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 2:27 AM

A great wish list - unloading an assembly has always been at the top of my list.

Alex Hoffman

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 3:28 AM

A great list, Frans. I'll add that for the documentation (MSDN Library), I would like to see the .NET Compact Framework documentation as a separate collection rather than mixed in with the full .NET Framework documentation.

-Nino

Nino Benvenuti

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 4:35 AM

Darn, I forgot one:
Make the EventArgs object be able to hold an object reference. Now you have to create new eventhandlers every time you want to pass simple event data, you have to define an EventArgs derived class plus eventhandler.

Frans Bouma

# re: LLBLGen Pro screenshot@ Wednesday, June 25, 2003 10:19 AM

Looking good! I can't wait. Just a reminder to take special care for making the dev model of this work well for multiple developers using source control and such.

a

# re: LLBLGen Pro screenshot@ Wednesday, June 25, 2003 10:23 AM

It will generate sourcecode in a directory, not overwriting readonly files. Therefor, ideally you'll do this: check out the files, generate new code, overwriting the files, check in the files again. There are a number of sourcecontrol systems and I can't support them all.

The whole idea is that the generated code is an assembly you work with, thus the code should be compiled as a single assembly, and be referenced from own code, you also don't edit generated code, you derive from the generated code. Therefore, source control misery is limited to a bare minimum.

Frans Bouma

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Wednesday, June 25, 2003 11:37 AM

Here's a couple I'd like to add to the .NET API:

1. More interfaces. Not enough classes derive from interfaces, which makes interface-based testing (read test-driven development) almost impossible. (Think HttpContext.)

2. Better abstraction in ADO.NET. You can't really write clean generic data access code because you can't create a DataAdapter without knowing whether you're doing SQL or OLEDB.

Those two have bugged me for a while.

Peter Provost

# re: My wish-list for the next Visual Studio.NET / .NET api release, part II@ Friday, June 27, 2003 2:25 AM

::Better abstraction in ADO.NET.

Worse - when you use visual deisgn (drag drop them onto a form) you get all the stuff hardcoded. Terrible.

I know you should never code this way, but they DO support it - and they do so wrong.

Thomas Tomiczek

# re: About code generators / generating code@ Sunday, June 29, 2003 12:17 AM

We used a slightly modified version of LLBLGen 1 for a project at the Fontys University. This saved us roughly 70% of the development time...not only because of the generation features, but also the iterative development made possible with LLBLGen. It's fast and easy to do roundtrip engineering using Visio creating the E/R, let LLBLGen update the DAL accordingly and slapping business-logic on top.

About 90% of the generation tools out there aren't useful indeed.

Just to note: LLBLGen also has its weak points... I'm not pr'ing over here ;)

Paul Gielens

# re: About code generators / generating code@ Sunday, June 29, 2003 12:24 AM

:)

Code generators have disadvantages too, like when they are not able to generate the code for the functionality you define in them, or the generated code is not up to par with the functionality requirements you have. I don't think the percentage of useless generators is around 90%, but there are a couple which are not useful in a wide range of applications, however no tool is (try hammering a nail with a screwdriver ;)). That's why you have to make a choice which generator you'll use. That's the question you have to ask yourself, not if generation of code is useful, because it is.

The working-method you describe is the one I forsee also: modelling abstract database models in a high end tool, generate code to work with the physical result of that modeling and on top of that, if possible generate BL code, and if not, hand-develop it. With a form-designer to do the gui (which is also a code generator ;)) it's easy to cut down development time using generators. It's just weird not a lot of people understand that. Ah well, the Not Invented Here (NIH)-syndrome is still roaming I guess. ;)

Frans Bouma

# Datagrid Girl@ Sunday, June 29, 2003 5:48 AM

Datagrid Girl

TrackBack

# Jonne Kats@ Sunday, June 29, 2003 5:48 AM

Jonne Kats

TrackBack

# Eric J. Smith's Weblog@ Sunday, June 29, 2003 5:48 AM

Eric J. Smith's Weblog

TrackBack

# Patrick Steele's .NET Blog@ Sunday, June 29, 2003 5:48 AM

Patrick Steele's .NET Blog

TrackBack

# re: Don't try to re-invent the browser, please.@ Sunday, June 29, 2003 11:02 PM

You have to be kidding me. System.Windows.Forms is such a steaming pile of piss that Mono has to use Wine (windows emulation) in order to mimic it exactly. The "HWND issue" is most certainly not fixed, SWF exposes all the gory details of the underlying Win32 implementation to the world.

If you want a decent cross platform GUI system, use GTK# - entirely unicode, cross platform, containment based layout, sane language bindings etc. If you actually care about having nice GUIs on a webpage (though most webpages look and feel waaaay nicer than your average GUI to me) then you want to use a decent widget toolkit to do it.

MH

# re: Don't try to re-invent the browser, please.@ Sunday, June 29, 2003 11:07 PM

Tell me, why should the underlying implementation of a given method be the same on mono as on .net / win32, i.e.: using win32 functions? If a class 'button' mimics a button, no-one should care how that class does that, be it calling into GTK+ or win32 or other widget lib, the bottom line is that it should behave like a button.

The problems arise when .NET code starts to use HWND related functionality to create 'nice' effects, like vs.net style menus, or a treeview control which does more things than it currently can do.

However, 100% .net code should be runnable on a mono winforms implementation which simply implements the functionality using a native library like GTK.

Frans Bouma

# re: About code generators / generating code@ Monday, June 30, 2003 6:19 AM

I think an important point that should also be made is that programmers the use code generators should understand the code that is generated.

darren pruitt

# re: About code generators / generating code@ Monday, June 30, 2003 7:10 AM

I hope you mean: "understand the interface and functionality of the code generated". I really do not see why a developer who uses a code generator, should understand the source code generated, since he shouldn't modify that code anyway, only extend it, and then the developer should know the interface and functionality.

if class Foo has a method Bar, and all you should hve to do is call 'Bar', why do you want to know how Bar works? I never check the x86 assembler the JIT creates, nor do I decompile .NET library methods (unless they have unexpected behaviour, as in: it looks like a bug).

Frans Bouma

# re: A quick update on LLBLGen Pro@ Monday, June 30, 2003 4:01 PM

How are you handling nullable types in Pro? In 1.2 you use SQL Types.

nullable types

# re: A quick update on LLBLGen Pro@ Monday, June 30, 2003 10:01 PM

The classes are .NET classes and have .NET types for their properties. You can test when a value was NULL, but the properties exposed have .NET types. When you want to set a value to NULL, you simply specify null or nothing. When a field is nullable it will be ok, otherwise an exception is thrown. WHen you read a NULL value from the database, it gets converted to a default value, like "" for NULLs in string related types. These defaults are user definable in a special class. There is no SqlType nor equivalent used anywhere :)

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:44 AM

Totally agree Frans, but you can also add the common scenario of hosting (like myself) where you have a firewall between the live server and the databse box.

I setup the two by letting access to nothing except the port to talk to SQL.

So the two cases you talked about are absolutly not working at all in this scenario.

Maybe the light will come from Yukon where apparently SQL will be closer to the Framework model.
BTW, nice stylesheet on your page ;-))

Paschal

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:47 AM

Oh I forgot also a case I know well where for some specific reasons too long to explain, the live server can connect either to a SQL box or a MySQL box(on Unix).

Using some DAL to switch easily from one to another, how MS think about trusted connections with an ASP Net username.

No way ;-)

Paschal

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 5:50 AM

The firewall solution is indeed a possible 'fix', but firewalls are not that cheap, plus you already run the box inside a DMZ of a firewall. :) What I really would like to see is the ability to use application trusted connections as they are defined in ADO/Sqlserver. You can then define the trusted connection with an application and be done with it, which is in fact what you want. At the moment it's a chewing-gum and iron wire solution: it will hold but for how long? :)

about the css: thanks :))

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 9:15 AM

I have a comment, storing connection string in the compiled form it is "secure" as storing it in text file. The reason is simple if you run a dissembler available with .net framework on this assembly, connection string becomes fully visible. The only solution is encryption.

Michael

# Store Connection Strings in the Registry@ Tuesday, July 01, 2003 2:18 PM

It's possible to store connection strings in the registry, and apply decent DACLs to that. I believe you could also use a local LSA secret if you really wanted to. Writing Secure Code by Michael Howard and David LeBlank has some good info on this. Of course if the web server is 0wn3d that still leaves your SQL box vulnerable, but it certainly raises the bar.

JosephCooney

# re: Serious SqlServer security problem: Microsoft's state of denial@ Tuesday, July 01, 2003 9:08 PM

All the tricks of hiding / protecting the connection string are nice and clever, but they all show how bad the mechanism is. No-one thinks its ok to store your windows credentials in a string somewhere so you can log on; these credentials are stored in a userdatabase and you are granted access. What the text based connection string shows us is that the mechanism is flawed: it should be possible to define which application or which user has access to given objects inside a database, without having to specify a textbased string somewhere with a password.

The integrated security option is in theory a good replacement, in practise it needs some work though.

Btw, Joseph: the idea is neat, but the ASPNET user f.e. is not able to read from the registry... therefor you have to give up some security settings which are applied for you when the .NET runtime is installed by giving ASPNET access to the registry.

Frans Bouma

# re: Serious SqlServer security problem: Microsoft's state of denial@ Wednesday, July 02, 2003 2:43 PM

I can't confirm or deny whether the aspnet user can read the registry by default (it can on my machine, and I don't remember making any special changes), but you can easily configure it so that user CAN read the registry, or change the web.config so that a particular application runs as a different user (which you can give the required permissions to). Also registry access is not an all or nothing permission. Like the file system you can configure the permissions to a high granularity to give the access required. You could also encrypt the connection string (but then the probelm becomes where to store the key), or use DPAPI (which reduces the key management problem). Also if you make all your database access via stored procedures, and only give your SQL User account(s) access to these you can help mitigate the risk if your web server is compromised and your connection string is discovered. Maybe I just don't see the problem for what it is, but it seems to me that there are a number of options available for securing the connection between your SQL server and web server. Here is a useful link re: storing database connection strings securely.

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnnetsec/html/SecNetch12.asp?FRAME=true#storingdatabaseconnectionstrings

Also, as I said in my previous comment Michael Howard and David LeBlank's book "Writing Secure Code" is really good for discussing this sort of thing.

JosephCooney

# re: We're a labeled group now!@ Wednesday, July 02, 2003 11:08 PM

:)

It's the religious nature of it all that I find amusing. I have no problem with code generation and the stuff I've read here about generating and regenerating database layers is great. I just don't think that it's going to take over entire application areas like Ian Wij's seems to in his "Writing Code is Stupid" piece. Evolutionary language improvements and tools to handle the mundane areas sure, but gather requirements and build from a requirements model? Nah.

Writing code is hard. Anything that makes it less hard is good; that includes code generators, testing, decent clients, etc, etc. But none of them are a silver bullet.

And I'm sorry but that quote of yours over on James' Avery's blog "People who do not understand that code generation is the future will be the first who will not be able to keep up with the rest who do." made me smile and kinda makes me feel that it's you guys that are the elitists - I'm glad it didn't end "will be the first against the wall when the revolution comes" ;)

And... How does questioning Ian's idea that code gen can replace "the "small army of generally not well skilled developers" that can be found in most organisations and who are "churning out a mass of ill-specified code through a poorly managed process" with some nirvana in which we "capture the requirements of the model" and have a code generator that can "consume the new model and generate appropriate code".
make me anything but a realist?

Keep up the good work, and prove us doubters wrong.

Len Holgate

# re: We're a labeled group now!@ Thursday, July 03, 2003 1:25 AM

Here I come with a lot of comments only to find that Len has already written such a good one! Typical.
:-)

There's no single way, of course. Code gen is great to improve productivity. But we have to understand what to generate (or what has been generated).

Jimmy Nilsson

# re: We're a labeled group now!@ Thursday, July 03, 2003 3:46 AM

This debate is almost an unrealistic as the "paperless society" debate.

What more can be said?

Ebenezer Ikonne

# re: We're a labeled group now!@ Thursday, July 03, 2003 3:53 AM

I absolutely agree with Len. People who think that writing code will go away are crazy. I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex. So there will always be programmers out there writing code in one form or another.

Eric J. Smith

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:01 AM

Ebenezer Ikonne: what has a paperless office idea to do with generating executable code from models? A paperless office doesn't work because the people IN the office want everything on paper so they print and print and print. If everyone starts using email and not a fax, it might become a reality. But that's another story.

All: What most people seem to think is that code generators should generate sourcecode. NO. They should generate executable instructions. Do not stick with a 'programmer language', because those things are invented for humans. No true code generator should generate plain sourcecode but should generate MSIL or other directly executable instructions.

Programming and developing software have NOTHING to do with programming languages and typing texts in a text-editor. Programming languages and typing texts are related to the implementation of the programming RESULTS. If you pick ANOTHER way of implementing the results of programming, you end up with another method of implementing it, but the end result should be the same: runnable functionality.

Forget 'OO', C#, loops, if then else and other program language related elements. Think in what a program should DO, and image the formulation of those functional elements in readable diagrams which can be drawn easily. Imagine then that those diagrams are fed to a tool which produces an executable. Such a tool can exist (there are already several btw) of hundreds of smaller similar tools. No programming language, no if then else for next switch case while wend, just a model as input and executable code as output.

Diagram quicksort for yourself, not in terms of C or VB, but in terms of plain logic. It's very easy.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:12 AM

"I also think that generating entire applications is rediculous and will never happen. What will happen is that things will continue to be abstracted to higher and higher levels, but at the same time requirements will become more and more complex."
Two mistakes. One is that you can now think it is rediculous that generating a whole application is silly, but perhaps you should use MS Access for a change and build an application with it. 10 to 1 you don't need a single line of code. In the future this will only expand, because if you focus on FUNCTIONALITY and the end result, an executable program (or better: a set of logical components glued together with logic), you'll see that hammering in the code by hand is nothing more than a (often very bad) way of translating the functionality descriptions into a programming language which is transformed into another programming language and so on till executable instructions are produced. Now, the mistake is that you shouldn't follow the same route when you want to generate executable instructions from functional descriptions. You should follow to route which makes it possible in the most elegant, fast way.

The other mistake is that although applications tend to become more complex as a whole, this is not a delimiter for using code generators at all. The reason for this is that if application complexity was a delimiter for a computer, it certainly would for a human. People forget that you can build the most complex applications with the most simple logical building blocks. Once logical elements which contain ready to use functionality are available for generators, you have a layer of elements you can address from within your generator. If you can then generate new logic from your generator with those blocks, you get new blocks, new functionality you can re-use.

Nothing complex at all. Step aside from the programming language paradigm, generators shouldn't think in a language that is ment for humans.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 4:24 AM

In the late 80's, 4GL was so hot. But the problem all the time was that the last 20% of the apps were actually hindered by the 4GL tools so the total result was often not very good at all. (I know, evolution and development...<g>)

And talking about Access, that gives me several really bad flashbacks from old applications of mine... Brr...

Even so, I guess you have a good point. Just as everybody else writing comments here.
:-)

For now, code generation serves me really well when they spit out code too.
:-)

Best Regards,
Jimmy
###

Jimmy Nilsson

# Eric J. Smith's Weblog@ Thursday, July 03, 2003 4:26 AM

Eric J. Smith's Weblog

TrackBack

# re: We're a labeled group now!@ Thursday, July 03, 2003 5:11 AM

Does code generation add another tool to my arsenal? Most certainly. But will it ever replace the bulk of my work? Absolutely not.

First off, for my job, source code is an absolute must. This is not negotiable. I'm not some entry level grunt, I'm the go-to guy when nobody else around here knows how to accomplish something. Jimmy put it very well. Currently I'm wrestling with SAP.... let's see, can I declare a PARAMETER in my ABAP program and create a simple selection screen? Sure. But when I wish that selection screen to ONLY contain plants which are designated as shipping points for a portion of one division, AND this varies depending on authentication.... 4GL can't cut it.

Another point here. Ever see the monstrosity of code the ABAP table grid wizard gives you? Yeah right. Since this code generator has no clue what things I need to accomplish with this grid it has to create each and every hook possible - leaving me to wade through the various sections of code to whittle it down to something maintainable.

Which brings me to my final point. MS Access? ROFL. Forget about the murderous SQL it automatically creates for queries. Forget about the pain in the butt scalability and truely robust security are. Just look at this: what's the outcome of all this code generating?

Yes, it DOES simplify many things. (I began by saying there is a place for code generating.) But it also has a truely disasterous effect....

Ever try to maintain a website written by some secretary who took a FrontPage course and so now deems themself a website developer? MS Access is like that. These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.

Dave

# re: We're a labeled group now!@ Thursday, July 03, 2003 5:23 AM

Dave: Ah, so current implementations of 'generators' are an argument why it will never work? MS Access was an example, a metaphore.

I developed in a 4GL for 2 years, I know what it is like, and I also know that it is stupid to not use a 4GL or a generator when you are developing an application which is database driven (and... whoa, that's about a hell of a lot of applications)

Your example about frontpage illustrates enough: "These non-technical people tend to know just enough to make themself dangerous. TO me, that is the REAL cost of code generation.". Then you really do not understand what I'm talking about. The attitude illustrated in your remark is what I refered to with 'Elitism'. Programming should be possible for everyone who can think logical and can design software. Today it's only possible for people who know their way in a given IDE/Editor, a language, some API's etc. (in other words: stuff you can look up).

Why should a 'technical' person be necessary to create a webgui? I don't see that. Today it is necessary because of the crappy state of most tools, however in theory it shouldn't be. That's not because the concept of a generator sucks, but because the people who wrote the current crop of generators did not understand what a generator should do or they made it that way so the market would buy it, otherwise it was too far fetched.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 6:15 AM

That was my point, source code will never go away..just like the fax machine.

But then again time will tell, like it always does.

Ebenezer Ikonne

# re: We're a labeled group now!@ Thursday, July 03, 2003 6:20 AM

Sourcecode will go away, but when is a blur of course. I think the first places where it will be used less and less is in the average business apps which, excuse me, are most of the time structured the same. And then eventually the other parts. I don't see humans hammering code in 2100.

Frans Bouma

# re: We're a labeled group now!@ Thursday, July 03, 2003 1:43 PM

Frans, to be honest that is that first time in 25 years I've ever been accosed of elitism. :-)

Seriously, to be totally objective, code generator - and I already said this - have their place. But they most certainly are not the be all or end all. Exactly what high level concept is so dramatically new here? Nothing. Before .NET OO you had 4GL. Before 4GL you had MS Access. Before MS Access you had 3GL. SO on and so forth.

Truely eliminating the need for people to write programming code will simply never happen. Never.

So what does this mean? It means that the better a code generator becomes, the more dangerous someone who doesn't understand why a code generator works becomes. Right now I have to deal with people who have no clue why they shouldn't just import their 20 column spreadsheet into MS Access. I mean "it works", roght? Normalization? Fergitaboutit.

Can you optimize code generators to (a) make my job as the technical lead on a project easier and (b) eliminate costs of having someone fresh out of college who can't do anything but write simple SQL? Most definitely. But there ain't no free lunch. There are costs. And those costs sometimes pile up on guys like me.

Elitism? No way. Realistic. If code generators - and let's agree right now this concept has existed for decades now - were realistically as great as you claim, then why hasn't one come along now to eliminate my job?

Do I believe my job in it's current capacity will exist in 2100? Nope. But not because of some code generator, rather, something much more simpler.... evolution.

Dave

# re: Serious SqlServer security problem: Microsoft's state of denial@ Thursday, July 03, 2003 3:57 PM

I think discussion missses two important facts:
1. Problem with integrated security is the way challenge/response works, i.e. passing challenge from web server to SQL which is not a domain controller does not work. However, there is a way to pass credentials securily (including *nix boxes, mind you). It's called Kerberos and 2000/2003 servers do support it.
2. In large scale implementation where people are concerned with SQL administrator having access to web server and vice versa, I think the solution would be to move your data access to a separate box and use .NET remoting.
Just my 2c
Georged

George Doubinski

# re: We're a labeled group now!@ Friday, July 04, 2003 4:16 AM

May I ask, what will be used to "create" these code generators. Do you envision a time when there will be a generator for every problem domain that exists?

Ebenezer Ikonne

# re: We're a labeled group now!@ Friday, July 04, 2003 4:24 AM

What is used to create them? Normal programming languages. Like normal programming languages are used to create compiler generators which then generate themselves based in the input of an (E)BNF syntaxis specification.

I don't know when it will be that for every problem domain there will be a generator. If you look at the level of stubborness that is in the developer community at the moment for adapting even dumb generators, I think it will take a long time before the majority of developers is chosing a generator over the option to hammer it all in by hand.

Frans Bouma

# re: XBOX's 4th of july@ Friday, July 04, 2003 5:04 AM

I agree. Hardly a security hole, but an interesting trick. Linux on an Xbox - who'd have thought? :)

Doug Thews

# re: Serious SqlServer security problem: Microsoft's state of denial@ Friday, July 04, 2003 5:15 AM

What you're talking about is something like Passport, where the system (or SQL database) sends you off to a service to authenticate, and you either come back with a valid key to enter, or not.

So, you could develop your own "Give Me My Connection String" web service that handles connection strings per app (if that's the way you do it). You use HTTPS and your app's authentication credentials (which can be compiled as part of the code - they shouldn't need to be changed). Then, get back your connection string.

I agree that this is not integrated and what you're thinking about (because it introduces a 3rd party), but it eliminates the need to store connection strings as strings anywhere on the web server.

Doug Thews

# re: Whoa, 33 today!@ Sunday, July 06, 2003 9:50 PM

Happy birthday Frans !

Francois Verbeeck

# re: Whoa, 33 today!@ Sunday, July 06, 2003 10:35 PM

Congrats!

Damn, I remember when I was the youngest among all I met at work... :-)

Jimmy Nilsson

# re: Whoa, 33 today!@ Sunday, July 06, 2003 11:17 PM

Happy Birthday!

Roy Osherove

# re: Whoa, 33 today!@ Sunday, July 06, 2003 11:38 PM

Thanks all! :)

Frans Bouma

# re: Whoa, 33 today!@ Monday, July 07, 2003 12:09 AM

Happy birthday! Well, I turn 29 today ... but somehow feel like 33 ;-)

Christian Weyer

# re: Whoa, 33 today!@ Monday, July 07, 2003 12:52 AM

Happy Birthday! :)

P.S. Some portion of cake still there? :)

MM

# re: Whoa, 33 today!@ Monday, July 07, 2003 1:44 AM

Happy Birthday.

whoami

# re: Whoa, 33 today!@ Monday, July 07, 2003 1:57 AM

Happy Birthday! You're 5 days after me but much younger-)

Sam Gentile

# re: Whoa, 33 today!@ Monday, July 07, 2003 3:08 AM

Congratulations :)

Zef Hemel

# re: Whoa, 33 today!@ Monday, July 07, 2003 3:30 AM

Just started subscribing to your blog last week. Good stuff. Happy birthday.

Justin Bigelow

# re: Whoa, 33 today!@ Monday, July 07, 2003 7:15 AM

Happy B-day!

Is that cake chocolate? If it is, can I send you my (snail)address?<G>

Chris Frazier

# re: Whoa, 33 today!@ Monday, July 07, 2003 7:23 AM

Thanks again all :)

Oh, and about the cake, of cooouuuurse nothing is left. :D :)

Frans Bouma

# re: Whoa, 33 today!@ Monday, July 07, 2003 9:49 AM

Congrats!

Paul Gielens

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 5:16 AM

Well stated

Greg

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 6:49 AM

Only in terns of VB versus C# is your argument valid. But I say if J#, COBOL and others can write IL that runs against the CLR (and _that_ is the _only_ relevant thing in this discussion when you get down to it) than why not VB too?

So VB is verbose. So VB originally was to be the RAD tool. Since VB4 it has been much more than that. Do I understand the inner workings of the Win32 APIs, COM/IDL? Do I understand the higher level concepts of OO, relational database design, threading and scalability? Sure do - and they are the cornerstone of my career path.

So C++ can do things more easily codable than VB regarding some of those. That never made me wish to wade into it. While not the best language, VB did allow me to develop clean maintainable apps that did all this.

IMHO, MS did the right thing by allowing me to write to the System Class, use ADO.NET and design multi-threaded apps. It all comes down to one thing only.... does a programmer understand how to use all the tools his/her particular language has?

Dave

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 7:33 AM

Frans, Thanks for explaining. Your post was enlightening, and I'll be the first to admit I did not know (or did not think of) much of what you write. All but the part about VB.Net being redundant. I'll go with Dave on that one, but that's a different story :)

Roy Osherove

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 8:14 AM

I agree with you. I'm from the C side of the fence, but I've done some VB programming the last few years. I know some VB developers that felt threatened/afraid of the change from VB to VB.NET, and they were even more afraid of C#. I feel that MS created VB.NET so that they would not lose the large pool of VB (larger than C++) "developers" out there. I don't understand why VB developers are so tied into their language, when I bring up C# they get defensive. On one hand I think that VB developers can create products faster and on the other hand I feel that they are lazy and unmotivated to understand the "why" not just the "how" of software development.

Phil

# heLP .Net Blog@ Tuesday, July 08, 2003 10:24 AM

heLP .Net Blog

TrackBack

# ISerializable@ Tuesday, July 08, 2003 10:24 AM

ISerializable

TrackBack

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 12:03 PM

Now, to be straight about it, I dabble in C# and will continue to. I've never bee afraid to learn new ways or languages. I used to code in both Assembler and Fortran, but love the RAD-ness of VB. But I do know of many VBers who have a very hard time with the .NET 'evolutions'. LOL!

Dave

# re: Re: Am I the stereotypical VB Programmer?@ Tuesday, July 08, 2003 11:21 PM

Nice article, and I can add another reason why i don't like the With statement; because it encourages people to write things like:
With A.B.C.D
myVar = .SomeVarFarAwayThatShouldntBeAccessedDirectly
End With

In fact, that is what i dislike about VB.Net the most, the fact that it enables people to cut corners where they aren't supposed to (i.e. On Error Resume Next)

Peter Vervoorn

# re: Re: Am I the stereotypical VB Programmer?@ Wednesday, July 09, 2003 11:13 PM

Um, I hope it's not too cynical to suggest that a big reason for introducing VB.NET may have been the claimed 3 million VB programmers out there. That's an awful lot of potential upgrade license fees....

Mike Woodhouse

# re: "Framework-Hell"-solution is here: ISV's can upgrade to VS.NET 2003 without pain.@ Thursday, July 10, 2003 6:50 AM

Frans,
What if the problem doesn't occur on the when I run my program on my machine, but when I tranfer the .dll to my website, then I get the problem message?

kreuzmarket@bluebon.net

Leeman Schmidt

# re: LLBLGen v1.21 has been released! (Mostly bugfixes)@ Saturday, July 12, 2003 6:01 AM

Why no enhancements made by gotdotnet'ers? I'm sure where clauses on each field rather then FK's would be much appreciated.

Further, thnx for the ongoing support and fixes! Heads up...

Paul Gielens

# re: LLBLGen v1.21 has been released! (Mostly bugfixes)@ Saturday, July 12, 2003 6:06 AM

The reason is simple: my codebase wasn't in sync with the gotdotnet codebase. I never included Lewis' updates for the where clause on each field because I found that a little too much (consider 50 tables with each 10 fields... ouch :) ).

Frankly, the workspace effort is a bit of a dissapointment, since not a lot has come out of it, but alas, it's freeware written in spare time :)

Frans Bouma

# re: Don't try to re-invent the browser, please.@ Sunday, July 13, 2003 10:20 AM

Here, here, Frans. I posted on this topic today (see link), and I mostly agree, but I think there is a real syngery possible (God I hate that word, but it actually applies) combining the browser chrome and HTML/CSS with the CLR. If standalone forms would have been enough, Java would have won long ago, but HTML has a decided advantage in layout flexibility (and widget beauty, but I'll stay away from that). HTML forms and toolbars and really suck, but so does Java and WinForms when you need to design a long form with hierarchal datagrid-like properties. The best solution will be to run both in a seamless browser window (w/ or w/o the browser toolbar, just like pop-up windows now), which will overcome the web issues of limited form widgets, fixed positioning, ugly scripts, and server round-trips without sacrificing the things people *like* about browser interfaces.

Richard Tallent

# re: About code generators / generating code@ Tuesday, July 15, 2003 6:29 AM

I couldn't agree more here: "code generator is the future".

btw, when are you planing to release llblgen Pro. I can't wait for that!
Do you have an estimative month?
Will you give the sourcecode at the same price?

thanks,
Matias

Matias Woloski

# re: About code generators / generating code@ Tuesday, July 15, 2003 6:50 AM

Matias: I hope to be finished with it at the end of august 2003 :)

The system is extensible in a lot of ways: code is generated using templates plus the steps the generator takes are configurable using task definitions in an xml file which bind tasks (f.e. directory creation) to an assembly and class which performs hte task). You can then add whatever you like as custom task, using your own assemblies, f.e. get old sources first from a sourcecontrol system or whatever :). We haven't planned source control release for a price, but perhaps we open up the source of the runtime library for licensees.

Frans Bouma

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 12:52 AM

Good article.
We have a mantra here: The first place you need to install source control is in the developer's mindset.

Duncan

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 5:08 AM

That is a very interesting read...

For me, one of the most disappointing things about SourceSafe is that while the IDE was improved so much between VS6 and VS7, and SourceSafe was barely touched.

The last two (fairly large) projects I've been on have used SourceSafe and I've had similar experiences both times. When the project is in its early stages, SourceSafe works fine. When the project matures, and you start to need more complex functionality from your SCM, it seems that SourceSafe just can't cut it.

I think one of the biggest problems I have with SourceSafe is the lack of promotion groups, (ie. to support work on multiple releases at the same time.) Sure, you can hack something together with sharing and labeling, but its just too messy in my opinion.

As far as I know, MS doesn't use SourceSafe (nor should they for the size of their projects) -- so much for eating your own dog food.

I have not had a chance to check out Vault, but it sounds promising.

ps. If anyone is looking for ideas, I want a SCM that will reject a check-in if they don't compile/pass unit tests. That would be very nice.

Don McNamara

# re: Serious SqlServer security problem: Microsoft's state of denial@ Wednesday, July 16, 2003 5:39 AM

Isn't this where serviced components come in handy? Only the credentials of the COM+ application should be able to connect to the database.

The ASP.NET web application can run with less permissions on the system then the COM+ application.

Ramon Smits

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 6:16 AM

I just finished writing an article that should be appearing in September's issue of Pinnacle's Hardcore Visual Studio.NET on making the most of VSS and I agree that, when used for it's intended purpose, VSS works well. It does have some drawbacks not mentioned here.

1. It uses pretty outdated technology. (ex. INI configuration files when it could use something like XML)

2. It's performance over VPN and remote connections in general really sucks. I wouldn't tell anyone to use it over VPN...it slows to a crawl most of the time. If you ARE going to use it over VPN, disable some features you probably won't use like Shadow Folders, Journal Files, and Project Access Rights. The most important feature to enable for VPN users however isn't even configurable from the VSS client. You have to edit the srcsafe.ini file and set CP_OnSelection to False. Normally whenever you click on a folder (a project or project grouping level) VSS performs a selection operation, which can take a while over a slow remote connection. By setting CP_OnSelection to no, users can drill down in the project hierarchy and just double-click or hit Enter when they find the folder they want to actually select, not having to wait a while for each level they expand.

3. It's integration with IDE's is less than reliable. How many times have you got the "Failed to reload project" message or checked out a file only to be told you couldn't edit it seconds later? Stuff like that bothers developers and I'm guessing it would only take someone at MS a week or so at the most to fix.

4. The way it performs "diff" checking is just slow. Vault really spanks the pants off of VSS in this situation. Vault's use of delta's is much more efficient. Also, use of some sort of data compression technology would be nice to help speed things up.

Like you've touched on - I think most people use VSS withouth really knowing the tool that well at all which isn't VSS's v-Hfault at all. I've talked to some of the VSS team at MS and like Don said, a good share of people at Microsoft don't use VSS. They use a command-line tool called "Source Depot" which I believe is a variant of CVS. I still use VSS for some things but have tried Vault and just find it easier to work with as a SCM. Why Microsoft hasn't tried to buy SourceGear yet or at least offer their SourceOffSite product for free with VSS makes me wonder how much MS really cares about what people think of VSS.

Ok, I'm done ranting.

Jason Mauss

# Darrell Norton's Blog@ Wednesday, July 16, 2003 6:33 AM

Darrell Norton's Blog

TrackBack

# re: It's not Visual SourceSafe's v^Hfault@ Wednesday, July 16, 2003 9:21 AM

Sorry Frans, but VSS is crap. The single most important thing that a SCC system MUST do is keep source code (and all past revisions) safe. VSS's very architecture precludes this. It is a client that writes directly to a proprietary database with non-atomic commits. If a client fails in the middle of a commit, you are almost assured database corruption. I've seen it several times over the course of several years. If you only work with the 'head' revision, you are unlikely to notice, but it becomes apparent when you work with past file revisions.

It also has very poor branching and merging capabilities, both of which are important as your product matures.

You also tak about lock vs concurrent editing. Your locking model fails in a number of use-cases:

1. Disconnected editing. This is the largest area where a locking type SCC model fails. File locking does not work well in a disconnected mode, while concurrent models (Such as Perforce, CVS, Subversion, etc) work very well. Indeed, with VS.NET and VSS, it attempts to imitate a concurrent versioning system in the disconnected mode.

2. Highly contested, frequently changed files. Depending on the toolset or project, some files are 'volatile', and must change frequently, are shared accross projects or libraries, and must be changed by more than one user. A locking model does not work well here, as this will act as a block against other users performing work. The suggestion that you delegate work is often impracticle, as there is often one person who is best qualified to perform a specific type of change.

3. The suggestion that user A tells user B what changes to make is yet another form of merge, although verbal instead of toolset based. Why not let the technology handle the merge? That's what concurrent editing was designed for.

As far as scheduling work and shared resources to avoid locking problems, you may be sacrificing development speed for diminished lock contention.

I could write several thousand words on why VSS is a poor solution, but I think I'll leave it at that for now.

Jerry Dennany

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 10:37 AM

How would you script the builds on a machine without the IDE? Would the "elements" be pulled out of the repository to recreate the local "files"?

Robert Hurlbut

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 10:39 AM

No, the tools are not working on the filesystem but with code elements retrieved from the repository, f.e. by calling the repository webservice. The concept of 'file' is not used when building the software.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 11:00 AM

Nice idea that would probably work well in some situations but I'm not sure how practical it would be for web applications.

andy

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 12:25 PM

I would have thought we'd have moved to the document repository scheme by now. I was hoping that was what's now SharePoint was going to give us.

Doug Thews

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 1:58 PM

SharePoint Portal Server can serve as a document repository; however, were you thinking of document == source file, Doug ?

Nino Benvenuti

# re: Get rid of the 'file' concept for sourcecode!@ Friday, July 18, 2003 2:39 PM

Have a look at some of the interactive source and intentional programming stuff at http://aisto.com/roeder/paper.

Pete

# Roland Weigelt@ Friday, July 18, 2003 3:53 PM

Roland Weigelt

TrackBack

# CVSNT will have SQL Server support soon@ Sunday, July 20, 2003 6:52 AM

I stopped using VSS a long, long time ago, not only because it corrupted my files one too many times, but because it supports file locking and CVS's free tools like TortoiseCVS and ViewCVS are much, much better. Does VSS have shared locks now? If VSS still exclusively locks files by default via VS.NET, it doesn't matter.

Money and time spent on VSS and Vault is a waste.

http://www.cvsnt.org

Tom

# And Intelligently Understood Names@ Sunday, July 20, 2003 4:33 PM

When you change a function name in "refactor" mode, all uses of that function name should then change to the new function name. That is, when a function is called, it's automatically converted into a function# by the system, and just referred to by string name for the user.

Lion Kimbro

# re: Get rid of the 'file' concept for sourcecode!@ Sunday, July 20, 2003 10:16 PM

A lot of Smalltalk implementations already work in this way - you save an image of the project, and work, class view like, with programming elements through the IDE. There is no notion of a file. I have not seen and source control systems for Smalltalk though that allow you to track back through changes to elements in the image.

Ian Cooper

# That's nothing new@ Sunday, July 20, 2003 10:28 PM

There are IDEs that work this way. Check out the Smalltalk environments, e.g. IBM VisualAge for Smalltalk or even VisualAge for Java. Working in such an Environment indeed provides many benefits when searching or following references. It's nice. I worked several years with VisualAge for Java and found it very comfortable. Much better than what JBuilder or Netbeans had to offer 5 years ago. Very sad that VA couldn't keep up with the JDK updates ( it was a closed environment hardwired to a specific JDK version). Because of that we had to move on to inferior IDEs.

Stefan Haubold

# re: Get rid of the 'file' concept for sourcecode!@ Sunday, July 20, 2003 10:33 PM

Very good feedback! I didn't know it was already common knowledge in the smalltalk world, I never used smalltalk myself...

Knowing that smalltalk IDE's have had this feature for years already, makes it even more weird why current IDE's for other languages still use the file concept.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 3:15 AM

The file concept remains because so many of our existing tools assume it. To switch, you have to provide the world with a *complete* toolset that works as well as the set we've got now.

Oh, and before that, you have to somehow create widespread dissatisfaction with the status quo.

Eric Sink

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 3:22 AM

Eric: the current concept of a 'file' is already a view of sectors on a harddisk. With the plugin system of the filesystem stack you can create a FS driver for the repository if you truly want backwards compatibility.

It's true that if it ain't broke, don't fix it is written all over it, but I also think that when a major IDE vendor (like MS) introduces it, plus with all the benefits that come with the concept, I think there will be a market for this. But it's a long road, admitted.

I wonder though how MS will set up WinFS in longhorn: after all it's a database which provides views ('files') of the objects inside the database, which can (IMHO) be compatible with the concept of the code element of my blog.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 6:53 AM

unsigned integers are NOT CLS compliant. The C# compiler is correct.

"Most of the members defined by types in the .NET Framework class library are CLS-compliant. However, some types in the class library have one or more members that are not CLS-compliant. These members enable support for language features that are not in the CLS. The types and members that are not CLS-compliant are identified as such in the reference documentation, and in all cases a CLS-compliant alternative is available. For more information about the types in the .NET Framework class library, see the .NET Framework Reference."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:01 AM

Well, the UInt32 structure exposes an uint member. All fine, but why isn't an Int64 used internally and externally?

When you have these kind of types in your core library, you define more than 1 library and not one: the CLS compliant one and the non-CLS compliant one.

It's also bogus testing. You test for type compliance, but what does that mean? Several types in the .NET library expose overloaded operators. These are PART OF the type. However, not usable in f.e. VB.NET.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:15 AM

It is fine to have non-cls compliant members, you just need to make sure that everything can be accomplished without them, just in case a language does not support one of your method signatures.

IMO, VB does to much in the background and doesn't give enough control over this type of stuff. I would be wary of using it for such projects. Apparently, the MS guys didn't think VB should be used for creating CLS compliant programs either, or they would have supported the CLS compliant attribute... So, moral of the story, use C# if you are working projects where you are concerned about Types. VB.NET is very loose with them (I guess some people do actually consider that a "feature," but I'm not one of them :-) ).

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:23 AM

'a' language... I think that definition is too vague. 'a MS language' is better. After all, if I define a new language for .NET, and it doesn't support 64bit integers, it can't use a lot of code since Int64 is CLS compliant but not according to my new language. :)

So, VB.NET apparently forced this uint != CLS Compliance crap to exist. How thoughtful.

Frans Bouma

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:32 AM

Jesse,

To be clear, yes, you can use non-CLS types in your application. However, if you want to be CLS compliant, you can't publically expose any of those types.

Patrick Steele

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:34 AM

Then your language isn't CLS compliant :-). However, just because it didn't have a "long int" or some language specific version of int 64 doesn't mean it wouldn't work. It should be able to use Int64 directly if it supports even the most basic type stuff from the CLI.

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:34 AM

Frans,

VB.NET really can't use unsigned ints. Sure, you can define vars of type UInt32, but once you try and do any operations with them (adds, substracts, even assignement) VB.NET complains because it doesn't know how to convert 'ints' to 'uints'.

Patrick Steele

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:38 AM

Patrick, as long as you have CLS compliant ways to do everything, it doesn't matter much whether the rest is fully compliant (IMO). CLS compliance is a good test to make sure you won't run into any hairy situations, but I don't see any reason to force yourself to ONLY use CLS specific stuff if you run into a situtation where it makes sense to do otherwise.

Jesse Ezell

# re: CLS Compliance testing is useless@ Monday, July 21, 2003 7:43 AM

Jesse, I think we're in agreement on this stuff.

I think CLS-compliance really only needs to be achieved by component/tool authors. If you're just coding an internal application or something simple for yourself, who cares about CLS-compliance? It's only an issue if you want to make a library or utility that will want to integrate with another .NET language.

Patrick Steele

# re: Get rid of the 'file' concept for sourcecode!@ Monday, July 21, 2003 12:02 PM

I've used VisualAge for Java, got to say, it really sucks when you actually want to get at the files - web applications are the most obvious example. It becomes very tricky when you have to work with lots of files - like images, stylesheets etc...

Scott Galloway

# re: The Blob!@ Tuesday, July 22, 2003 8:49 AM

Hahahaha...

I wasn't drinking, but why didn't you say I had to print this out and read it on the toilet? No I've shitted my pants from laughing!!! :)

Dennis v/d Stelt

# re: Get rid of the 'file' concept for sourcecode!@ Tuesday, July 22, 2003 9:04 AM

When using Eclipse with Java, mostly you are dealing with projects, packages, classes, interfaces not folders and source files.

Yiyi

# re: Re: Am I the stereotypical VB Programmer?@ Wednesday, July 23, 2003 9:51 PM

<<an editor that helps you more than any other editor on the planet and with a compiler that is faster than any C or C++ compiler out there>>

I think you are talking about Delphi.

<<tortured for years with C, Pascal>>
when was the last time he tried Delphi. It is still the best dev tool for win32.

I am new to this blog but a long time programmer in vb that switched to delphi 3 or so years ago.
VB.net is just included to keep the .net learning curve down for the beginner Vb programmers . i am sure anyone with some real experiance will move to C# ,after all it was written by the same guy that wrote Delphi and is the best thing (along with the framework) that microsoft have done for years. c# is going to be huge.

Nice Guy Eddie

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Wednesday, July 23, 2003 10:53 PM

What more do you REALLY need to see that MS is committed to their customers? Geez man. You sure do complain about MS a lot. Ever hear the phrase "biting the hand that feeds you?"

You could get a lot more done with MS if you had a more positive attitude. They're still figuring some of this stuff out, just like we are.

Robert McLaws

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Wednesday, July 23, 2003 10:58 PM

What's wrong with critizism? I'm not biting the hand that feeds me. If I can't ask Microsoft why there isn't an SP for VS.NET 2002 released, the world really is in trouble.

Frans Bouma

# re: To Entity.Save() or not to Entity.Save()?@ Thursday, July 24, 2003 1:21 AM

YOu are right.

More crreclty. Jimmy is wrong.

He should have handled both forms with different transactions, diferent objects, different caches etc. Then he never would get the problem, and both things could be commited separatly.

Thomas Tomiczek

# re: To Entity.Save() or not to Entity.Save()?@ Thursday, July 24, 2003 1:24 AM

The problem with one cache per appDomain still exists though if you use separate caches. (or to be more precise: when a cache is used, it will fall apart when multiple appdomains are accessing the same shared repository)

Frans Bouma

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 2:33 AM

Hey Robert, since when is being critic bad???
Do you eat everything your holy "hand that feeds you" decides to give you?

Fabrice

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 2:44 AM

Frans,

Can you go into a little more detail about what you don't like about VS 2003? We are about to make the switch...

Thanks
Don

Don McNamara

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 3:25 AM

Don: if you're developing in VB.NET, I'd recommend you read Greg Robinson's blog and his blogs about vs.net 2003 and VB.NET.

In C# (which I use) I have problems with intellisense and the debugger. The debugger is sometimes failing to show membervariables but shows empty rows. Debugging is then useless. This happens to me 2 a 3 times a week. I have to restart the machine and even then it is kind of random.

I discovered that I don't use the features that come with vs.net 2003 that often. The intellisense 'prefered entry' feature isn't always useful and the stubbers of interface code is useless, simply because it doesn't copy the comments you specify with the interface declaration.

Frans Bouma

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Thursday, July 24, 2003 3:33 AM

Microsoft's support for current customers of the .NET Framework 1.0 and VS.NET 2002 is a complete load of *crap*!

First off, they don't even acknowledge a fraction of the bugs that are in the products. The only thing coming out of Redmond, as always, is upgrade! upgrade! upgrade! That will fix all your woes. Yeah, right. Give me a break M$.

Let me tell you something Microsoft. I'm a consultant who works for major companies who adopt .NET technologies. It's *amazing* in a lot of these shops that they adopted .NET in the first place. Those who have, for the most part, have adopted version 1.0 (and if I'm lucky, SP2 for the framework).

Most don't have any interest at all upgrading to the next version of VS.NET simply because they want to take the "wait and see" approach. You know, M$, the same one they want to take with your operating systems (and that's why Win2k and NT4 is so widely used, despite the all the new features of XP and Win2k3).

If we could get a fricking service pack with *real* fixes in it (what the hell was SP1 for the framework about, anyway? what a waste), then at least I could work hard to convince the management types to keep up-to-date with the latest fixes (usually because they do it out of habit to fix all the bugs in your other products).

If this is the way M$ intends to be, than I for one (and I know a lot of other developers feel this way), think it's a load of crap. C'mon M$ -- support your existing products and don't force people to upgrade to get the latest bug fixes.

M$, you've come a long way from what you used to be, but I'm afraid you're taking a step back with the (lack of) support you are giving your customers.

Load of crap

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Sunday, July 27, 2003 10:56 AM

Robert,

Ever heard of the prase:
'Customer is king' ?

We don't get fed by Microsoft. MS is just one of the firms that deliver IDE's for .NET (Borland is another one).
If you want to use a good product, then critizism is a way to get things done.

If you buy a new car, wich has some production faults, but in a new edition, or a new version of that type of car, these glitches are fixed, what do you expect? You expect that they will fix your car. You don't expect that the manufacturer says: "Oh, we fixed that in our new version, if you want it fixed, buy the new version of that model".

whoami

# re: Don't try to re-invent the browser, please.@ Monday, July 28, 2003 1:30 AM

All pretty windows centric. I cannot see that the imitation of one particular proprietary form tool (that is what mono is intended to be) shall be the bright future. I rather see this as an argument for independant open source form languages. XUL could be it.

Another question is, how comes that it is often easy to convince use to use the so restricted browser GUI. Concepts like collecting favourites and sending links via e-mail to someone else would all needed to be reinvented by a GUI of the future.

Frank Nestel

# Getting rid of the 'File' Concept for Source Code?@ Tuesday, July 29, 2003 2:58 AM

TrackBack

# VSIP Corroboration@ Tuesday, July 29, 2003 7:11 PM

TrackBack

# Hear hear!@ Thursday, July 31, 2003 8:40 AM

Very much agreed. The (language)discussion is going loud around here these days. This is a point I'll definately use in the office wars:)

Mads Nissen

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 9:07 AM

Completely disagree. If I'm testing my application and an exception fires because, say I'd used the wrong type of slash in XPath, then I want to fix it, then carry on. This results in a quick, trivial change, rather than the 30-40 seconds required to stop the debugger, let VS.Net rearrange all it's docked windows, make the change, fire up the debugger. Navigate through the application to the same spot the exception fired so that I can carry on testing from where I left off.

I would agree that pure logic should not be built on the fly - it should take a more formal approach, but stupid coding mistakes need to be squashed rapidly while testing your code.

Unit Testing (as in xUnit) doesn't help in most of these situations if the coding error was part of the presentation layer.

I've written parsers, web apps, win apps in C# all with NUnit during the last 3 years and regularly wish I had E&C.

RichB

# Why Edit and continue is a GOOD thing@ Thursday, July 31, 2003 9:25 AM

TrackBack

# re: Re: Am I the stereotypical VB Programmer?@ Thursday, July 31, 2003 3:26 PM

With is a bad construct because it discourages developers from refactoring their code. If the type expression the With statement refers to contains one or more periods, then the developer should really be thinking about pushing the With-block into the object that it operates on.

In other words, the method with the With-block has too much intimate knowledge of the other classes specified in the With statement type expression.

Having said that, I believe that refactoring should not be a prime concern for any VB developer - I believe that VB should become a much more RAD language used as very rapid glue code for components provided by other vendors. And because of this, I believe that With does indeed have a place in the VB arsenal.

BTW - I was a VB-dev before VB had the With statement...

RichB

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 5:23 PM

Hehe VB crap... debug, change your program, serious hang, terminate the app and IDE shuts down as well.

BOOM, al changes are lost... what the hell did I just do?

Welcome in the world of crappy programming pratices. Please MS leave Edit & Continue out of C#. Disfunctional coding pratices should have their own disfunctional language (VB), let it not be C#.

My 2c

Paul Gielens

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 6:20 PM

Blame the languages for good and bad all you want, but it still all depends on the person behind the keyboard! ;)

HumanCompiler

# Frans Bouma's says Edit and Continue is a bad thing@ Thursday, July 31, 2003 9:21 PM

TrackBack

# re: A pattern in patterned confusion.@ Friday, August 01, 2003 7:17 AM

I completely agree Frans. In fact, one of the requirements for being a design pattern is that it *must* be used by more than one group of people. You simply can't invent something new yourself and call it a pattern unless it's something other people have come up with as well.

Thong Nguyen

# More on the badness of E@ Friday, August 01, 2003 7:29 AM

TrackBack

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 11:40 AM

Very good points and reasons for NOT using Edit and Continue. This is exactly what unit testing has helped us get away from.

Robert Hurlbut

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 2:09 PM

If you think it's bad, don't use it. But put it in there for the people who like it. I want freedom, not constraints imposed on me from the Best Practices Police.

Charlie Zimmerman

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:40 PM

I am kind of amazed at the negative reaction that people are showing for EnC. I don't understand it. How does fixing a stupid bug while debugging and without recompiling encourage bad programming practice? That kind of thing happens to everyone no matter how much forethought you put into your design.

Tosh Meston

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:42 PM

Tosh: read my other article about debugging I posted today. You'll understand why.

Frans Bouma

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 7:44 PM

Frans, nice stuff!

My favourite "Plain old stupidity bug" used to be forgetting this line:

objRs.MoveNext()

:-)

Darren Neimke

# re: More on the badness of E&C and how to debug software.@ Friday, August 01, 2003 11:03 PM

This argument misses the main reason I use edit and continue. I'm an old Scheme programmer, and I just use it like a REPL. When I'm using systems that don't yet have any documentation and are just an API and a pile of messy source, it's an easy way to new up some objects, play around with them, and see how they work.

Edit and continue isn't just about bug fixing; for me, it's also about exploration.

But then, maybe I'm just an old Scheme programmer and don't know any better :-)

LarsBerg

# re: More on the badness of E&C and how to debug software.@ Saturday, August 02, 2003 11:36 AM

see:

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237275853

for my response

James Robertson

# re: More on the badness of E&C and how to debug software.@ Saturday, August 02, 2003 1:23 PM

Come on. What is edit and continue but an automation of the stop, edit and recompile under the covers. I like automation and abstraction, it saves me time. That's why I like code generators. And if you think about it, the same arguments could be applied to code genrators, so there is a bit of a contridiction here. E&C is just another tool to be used at the appropriate times. If you want to stop bad programming habbits in programmers that don't know what that appropriate time is, well then we need to attack some other features of the IDE as well. This spills over into a much bigger philisopical debate over associating ones value as a programmer with the tool that one uses - as in the statment "I am a VB programmer", or "I use code generators". If a language/IDE combination such as VB encourages the use of wizards, code generators, automation tricks, and other 'crutches' to progam without understanding what the end result is, it will get a bad reputation among more diciplined programmers that use another tool (in this case c#). Try on this statment for size "I program in notepad". What does that say? It is language agnostic - notice I didn't mention any language. It could be VB, C# or assembly. So lets assume I am programming VB in notepad. The edit, compile and debug process would be even more painful, requiring me to be even more diciplined. Why in the hell would I want to do that when I could use the IDE? Just for some macho bragging rights?

Doug King

# re: More on the badness of E&C and how to debug software.@ Sunday, August 03, 2003 5:55 AM

Doug: E&C isn't a tool you use for 'testing'. There you go wrong. If you miscoded a statement (used + instead of - f.e.) and you see that in the debugger, you fix that in the code and move on. Do you NEED the debugger to verify that the '-' you just inserted at the spot of the '+' is the correct operator? If you do, you do not understand what code SHOULD be there at that spot. That's the point. If you need E&C to verify if that fix (the '-') is correct, you are using trial and error to code you through an algorithm. That's the point I was trying to make: if you KNOW what you are doing, you can develop software WITHOUT a debugger, because you know which statements should be on which spots in which routines.

Consider this: do you think Windows kernel developers use E&C to fix bugs? Debugging OS kernels is hard (using 2 machines/virtual machines), left alone use E&C. Still people manage to create solid, working kernels. How do they do that? Solid software design.

It has nothing to do with bragging rights. If someone says he develops software in vi or notepad I'd say he's a fool. However, every developer should KNOW/realize why he is using a given tool. Only THEN the developer can truly unleash the power of that tool, because only then the developer knows WHEN to use the tool.

Frans Bouma

# xL8 - Grant Carpenter@ Sunday, August 03, 2003 10:14 PM

xL8 - Grant Carpenter

TrackBack

# re: So Microsoft, when is VS.NET 2002's service pack released?@ Monday, August 04, 2003 1:14 PM

yeah, im looking for a patch to vs2002 right now, but i guess there isnt one.

I like using MS's tools, but their customer service blows. im really sick and tired of it too. VS.net is full of bugs, but they dont seem to care. it really pisses me off.

how are we supposed to get work done on time when we spend all our time trying to work around the half-assed, piece-of-crap utility known as VS.NET?

shane

# This seems an overreaction@ Monday, August 04, 2003 10:38 PM

It is easy to dismiss the plain stupidity bugs, but when working on a mature product, a large amount of time spent debugging is spent on such bugs. If you add a new method and it gets halfway through a million steps of exiting code (some sort of an engine), it is a heck of a lot easier to fix and continue than to stop and get back to where you were. Granted, that is also a reflection of the tools available, but what if several human interaction steps are required to get to that point. Recreating them over and over to reproduce the situation rather than using Edit&Continue seems extreme.

Having said this, note that I don't have or use E&C in the compiler I have now, but I think the concept is well founded. The implementation is another question, and I do think it is a fair argument to say that there may be better walls for the developers to throw themselves at.

Ben Langhinrichs

# re: Why Edit & Continue is a bad thing@ Tuesday, August 05, 2003 10:24 AM

I've developed with tools that don't have E&C and I can tell you this, having it saved me more time than not having it. Particularly when it takes me 1/2 the time to locate and fix the problem using E&C as opposed to having to categorize and determine the cause of the bug. An application that I work on now is what's called an Allocation Engine. It's sole purpose is to perform extensive calcs against a database to provide Oil & Gas companies with the info they need to determine what was produced and what was sold. It has no user interface and hundreds of functions and objects. It is written in Powerbuilder. When a customer reports a bug to us, it can literally take an entire workday (sometimes more) to figure out where the bug is and what is causing it. In order to assist us in this, we generate trace files and insert message boxes. Powerbuilder has NO Edit and Continue. Under the same scenario, using VB6, it would have taken us roughly 1/2 the time to locate and fix the bug because some of these bugs don't pop up until after thousands of lines of code have executed and several minutes or an hour has gone by. By inserting a breakpoint (which PB does have) near the area where we believe the bug originates. We then begin stepping through the code and "watching" the values. Once we see what's happening, (using E&C) we can easily change that line, step into it, check the result and then continue on with the allocation.

The real beauty here is that "IF" you don't like E&C, then don't use it.

Keith Keller

# re: More on the badness of E&C and how to debug software.@ Tuesday, August 05, 2003 1:29 PM

Do the Windows kernel developers use RAD tools to create the kernel? :)

It's about productivity. When I see a bug, I have the ability to fix it, and continue debugging. There's no way to convince me that I didn't just save the time I spent getting to that place in the application.

Rather than reading through your algorithm in your head, why not let the computer help you? When I'm done writing some code, I spend time in the debugger stepping through it and examining what's going on. If you wrote the code and believe it was correct, chances are that if there IS an error, the "execution engine" in your head isn't going to catch it.

Stepping through the code and examining the state things is more reliable and more effective than trying to do it in your head. And it's when you're doing that that Edit and Continue is most useful.

Steve Tibbett

# re: More on the badness of E&C and how to debug software.@ Tuesday, August 05, 2003 2:46 PM

Like I said in my original comments, there is an appropriate time to use E&C as a proper time saving tool. In your scenario (kernal developers) I agree, use of E&C seems silly. But what about tweaking UI code or prototyping ideas, debugging someone else's code, refactoring, etc. E&C is just another tool that compresses the edit, compile, run-code-in-IDE cycle. If you have no need to do the last step, run-code-in-IDE, then E&C is not apporpriate. If there is a good argument to NEVER run-code-in-IDE, instead do unit tests, etc., then E&C could be seen as encouraging bad practices. I submit that this is the real crux of this debate.

Doug King

# re: We're a labeled group now!@ Friday, August 08, 2003 3:18 PM

Personally, I side with the CG’ers and buy into that vision, though I think it may take many decades--if not centuries--to get “there”. Where is “there”? To me, it is the point where over 90% of all programming is via specification rather than coding.

To those defending the need for a seasoned developer I say that they are 100% correct, but for the wrong reasons. Creating correct specifications for a code generator to generate any non-trivial application will remain a specialized skill for a long-long-time to come. This kind of executable specification becomes just another higher level of programming.

The point is NOT that code generators eliminate programming. Rather, the point of MDA, code generation, and executable-model initiatives is that (1) in the short-term they eliminate a lot of tedium (and errors) in writing with our current crop of relatively low-level programming languages (Java, C#, VB, XSLT, PL/SQL -- T-SQL, ABAP, etc.) and (2) in the longer-range vision, allow for developers to remain at a higher level of abstraction--much closer to the actual problem domain--rather than constantly dealing with the particulars of the implementation platform.

Will we always need lower-level systems programmers? Into the foreseeable future, yes, probably. However, our profession has already evolved from designing circuits and flipping switches (ENIAC), to bit twiddling in machine language (punch-cards anyone?), to assembly languages, to lower level procedural languages such as C and Forth, to OO such as C++, Java, and C# and now the massive frameworks/environments supporting business apps (J2EE App Servers/.Net). It seems only reasonable to observe that the bulk of programming will continue to evolve to higher-and-higher levels of abstraction as the tools and the basic building blocks become more refined.

Naim Ru

# re: We're a labeled group now!@ Friday, August 08, 2003 3:33 PM

One more point: remember that if you program in anything other than raw machine language, you are already using a code-generator -- the compiler or VM!

The "code generation crowd" is simply adding another layer of compilation/interpretation on top of the multiple layers which already exist. There is no reason for me to believe that this layering needs to stop at the current state-of-the-art.

Naim Ru

# Internet Explorer.NET@ Sunday, August 10, 2003 6:58 AM

In my recent articles I've explored the concept of the Universal Canvas, a term made popular by Microsoft when it launched .NET in 2000.

TrackBack

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 3:02 PM

Thanks for the pointer Frans and good luck with your 'crunch-mode'! As you know, I'm very much behind with my blogging too. I have at least two blog posts that you have commented very well and which I have to write about again. In a week or two...
:-)

Best Regards,
Jimmy
###

Jimmy Nilsson

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 4:47 PM

Thanks for the support, Jimmy! :) I hope the painting of the house is progressing as planned :)

Frans Bouma

# re: Sorry for the lack of updates...@ Monday, August 11, 2003 5:41 PM

Perhaps not progressing as planned, but at least progressing enough.

Ah, I found another area for applying Agile/XP. "What is the smallest amount of painting that would possibly work?"
:-)

Jimmy Nilsson

# re: Sorry for the lack of updates...@ Thursday, August 14, 2003 12:19 PM

Frans will this be a public beta?

Have you decided on a pricing structure yet?

Cheers

free4all

# re: Sorry for the lack of updates...@ Thursday, August 14, 2003 12:21 PM

The beta won't be public, but a select group of people will beta-test the betaversion. The estimated 'street' price is 170EUR excl. VAT. for a site/department license, thus 4 developers? 1 price :), and the runtime license is of course free.

Frans Bouma

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 4:52 AM

Well, +1 for you here, Frans.

I received a lot of e-mails the last few days from different Microsoft channels, providing some very useful information on the whole Blaster thing. And yes, it made me wonder why, in spite of the early availability of patches, the worm could do so much damage over the last few days.

So, I totally agree with this entry from you.

Admittedly, I always placed you more or less in the anti-Microsoft camp. I guess, that's because some of your first postings in the DOTNET-CLR discussion group of DevelopMentor, which were actually the first words I ever read from you. Back then, if I remember correctly, you'd just started developing for the .NET platform. Those first postings were quite critical and, I still think, far too agressive in their lack of nuances. So, now I'm kind of ashamed for hanging on to that first impression---and I apologize: you seem quite objective to me now.

And when MS screws up, I count on some serious ranting from you towards Redmond: just to illustrate your objectivity. ;)

Stefan Holdermans

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 4:59 AM

I started developing with .NET in march 2002 :P But I agree, sometimes ranting can be counterproductive when you want to make impressions, however even rants do get heard. I'm not in the anti-microsoft camp, however due to .NET I left the pro-microsoft camp which was a thing I never thought possible :)

It will be all right, when whidbey will be released.

I also think MS should have done more to protect users. I mean: WHY isn't there a free add-on for windows 2000 which simply acts as a firewall like in XP? They have the code already there, it's in XP, why do I have to buy an expensive firewall for windows 2000? Just to block some ports. That's the kind of thinking that's still not there in Redmond. It will be there, but not at the moment or at least too less :) Ah well.. nothing's perfect :)

Frans Bouma

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:16 AM

I like the price Frans, I was hoping I wouldn't be priced out of the market and this sounds more than generous. I have looked at other products from thona and co but the cost is astronomical. For a small coding shop with an even smaller budget this is ideal.

Once the "select" group has finished beta testing will there be a try before you buy?

free4all

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:25 AM

:) Yes there will be a 'demo' version available, so you can try it out. The competition costs a fortune especially when you are with 2 or more developers and they can't live up the price the ask.

Frans Bouma

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 5:58 AM

Champion I have a project waiting to go but I'm holding out so I can try your software. I'm hoping this is a cure for all my DB headaches. Can't wait to try it out!

free4all@dootdoot.co.uk

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 6:30 AM

I hope it won't dissapoint you :) If I won't make the sept 1 date, I'll mail you and you can get started with a preview version.

Frans Bouma

# Blaster worm blogging: whose fault is it?@ Friday, August 15, 2003 9:14 AM

TrackBack

# re: Sorry for the lack of updates...@ Friday, August 15, 2003 9:31 AM

Thanks Frans that would be great. I'm sure you'll not disappoint if your previous work is anything to go by!

free4all@dootdoot.co.uk

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 10:34 AM

"If you as a sysadmin did your job well" If MS did their job well, this would not have even been an issue in the first place. Do it right the first time, or not at all.

Travis

# re: Stop ranting about the blaster worm@ Friday, August 15, 2003 11:52 AM

"who needs a sysadmin with perfect software"

I'm sure a lot of sysadmins would resent that.

Without MS making the stupid and dangerous decision to have things like RPC enabled by default, sysadmins could concentrate on more important things like, well, administering the system.

Joe Grossberg

# no firewall in windows 2000?@ Monday, August 18, 2003 7:49 AM

Actually, Windows 2000 does have a free firewall. How to configure it can be read at http://support.microsoft.com/?id=309798

Stefan Mensink

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 2:28 PM

I'm sort of in the same boat. I have a project that I would love to use llblgen pro on. If there's still room in your public beta, let me know! ;-)

bonder@digitalarcana.com

Bruce Onder

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 2:35 PM

Bruce: it's a private beta, not a public beta, sorry :) At the moment the beta testing is going well, no need for extra hands, but thanks for the offer. :)

Frans Bouma

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 3:37 PM

Oops, I meant to write "Private" not "public." :) Oh well! Do you imagine the beta taking much longer than two months or so?

Bruce Onder

# re: Sorry for the lack of updates...@ Wednesday, August 20, 2003 3:43 PM

Bruce: Naah we're currently very close to release candidate quality actually :) Most big bugs are ironed out in the last couple of days. What's left is documentation and the glitches that pop up in the next couple of days. :)

Frans Bouma

# re: Sorry for the lack of updates...@ Thursday, August 21, 2003 1:37 AM

Hi Frans,
I'm planning to buy it, but what do you mean with runtime license free?
You can develop and use it for free? only if you publish it on a webserver, you've got to pay?

Stijn Gysemans

# re: Sorry for the lack of updates...@ Thursday, August 21, 2003 2:28 AM

Stijn: You have to pay for a license to use the tool, and the tool generates code which targets the runtime library that comes with the tool (a set of base classes). Some competitors also ask a fee for usage of the runtime, I don't. If you have payed for a license, you can generate as much applications as you want and you don't have to pay for a runtime license.

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 5:41 AM

ventilate my experiences with this 'competitor'

I'll proof them wrong within a few weeks time

Goosebumps all over the place... good luck during the crunching period. Sounds exciting!

Paul Gielens

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 5:42 AM

Thanks Paul! :)

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 8:33 AM

Kinda odd to call such a tool just like a tool already included in .NET...

Zef Hemel

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 9:11 AM

Kick some a**, Frans! BTW, how much is LLBLGen pro (or 2.0) gonna cost? I gotta start greasing the wheels around here.

Darrell

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 9:34 AM

Darrell: 170 EURO excl. VAT for a site/department license, so one license per team. :)

Frans Bouma

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 10:45 AM

Frans, I know my team is excited about LLBLGen Pro. We hope to see it soon.

Emmet

# re: 'nGen' is NOT related to LLBLGen or me@ Thursday, August 21, 2003 7:19 PM

Like Zef I can't belieive someone would give something the same name as a tool already in the .NET framework. Maybe I should make a webcontrol called ILDASM or something.

JosephCooney

# re: 'nGen' is NOT related to LLBLGen or me@ Saturday, August 23, 2003 8:35 PM

Am I missing something here? how does the name ngen in any way resemble LLBLGen

Steve Johnson

# More on SQL Server Auto-Updates@ Sunday, August 24, 2003 11:35 AM

TrackBack

# Small Query Blog@ Monday, August 25, 2003 6:50 AM

Small Query Blog

TrackBack

# re: LLBLGen Pro release date set@ Tuesday, August 26, 2003 9:58 AM

Yee haw! :)

Bruce Onder

# re: LLBLGen Pro release date set@ Monday, September 01, 2003 10:55 AM

So, it's the 1:st.. Where is it?! ;)

Can't Wait

# re: LLBLGen Pro release date set@ Monday, September 01, 2003 10:58 AM

On my harddisk :) It will be later this week, probably friday. Stay tuned. We're in release candidate 2 now, pretty close to the final product. :)

Frans Bouma

# re: LLBLGen Pro release date set@ Tuesday, September 02, 2003 8:31 AM

I'm just curious about the remoting support that will be available for the LLBLGen Pro. Will the generated classes be accessible by remotable functions and methods?

Wondering

# re: Get rid of the 'file' concept for sourcecode!@ Thursday, September 04, 2003 8:39 AM

.NET gives everything we need for something better: System.CodeDom. We simply have to build an IDE that will handle the object graph directly instead of relying on those damn flat files.

Jérôme Tremblay

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 4:55 PM

Congratulations!

Stefan Holdermans

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:12 PM

Thanks! :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:44 PM

Just downloaded the demo :)

After executing the prog for the first time I get:
SetupMainGui::Could not load the file: 'guistate.xml' to de-serialize the previous window state back. Reason: this is the first time you run this application or you have manually deleted this file. LLBLGen Pro will use the default window state and window positions.
SetupMainGui::Complete exception: Could not find file "C:\Program Files\Solutions Design\LLBLGen Pro Demo\guistate.xml".

Kris

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:45 PM

Pushed the button too fast.

Just wanted to say that the eagle has landed.

Kris

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 5:50 PM

That's normal behaviour, Kris :) It informs you that it couldn't load the file, and created a new one for you :)

have fun with the demo :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 07, 2003 7:13 PM

Congradulations Frans!

LLBLGen has been great for many projects and now LLBLGen Pro looks great as well! You have been an asset to all of us. Your hard work and dedication is appreciated.

Now, I have some studying to do :)

Kim (Kman)

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:12 AM

Thanks Frans! I've been waiting patiently for LLBLGen Pro, thanks for keeping the price reasonable. You have a surefire winner on your hands.

senkwe

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 4:05 AM

Well, congratulations! As soon as I start to develop in .NET; i'll start to use it ;)

Nielsz

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 4:16 AM

Heh Nielsz :) And you'll never know when that will be. PHP isn't everything you know ;)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 12:03 PM

Congratulations Frans! Been playing with the demo all day and have to say I'm impressed. Just waiting for confirmation from the boss now so I can buy the full version.

free4all@dootdoot.co.uk

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 2:10 PM

Impressive, so easy to use and most helpful documentation.

Just a quick question... what about inheriting the generated entity classes? What are you thoughts about inheritance within the generated framework?

btw nice implementation regarding lazy loading and COM+!

Paul Gielens

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 2:26 PM

thanks Paul!

Check out the two class scenario generator configurations, these will generate 2 classes (using different templates) per entity: one with the core logic (*EntityBase) and one for your code (*Entity). When you update your project, you just re-generate the base classes and keep the inherited classes. :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:12 PM

Please add a demo aspx sample that uses the demo Northwind classes. Any product that forces me to read too much docs before I can have a good feeling about it will get me to lose interest pretty quick. Put a grid that does delete, insert, edit so that in 5 minutes, I can see results and know how the product works.

I am sure others are impatient like me :)
llgl open source is a good product. Congrats.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 08, 2003 3:27 PM

Abdu: I know :) a sample app will be up in a few days with a grid, some transactions etc. All the code snippets in the docs are from a test app that will be transformed in this example btw, so you can get started pretty quick, but an example app is definitely planned, however I ran out of time to write that before the deadline. However I'll add one in the next few days.

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 5:45 AM

Congratulations Frans! If I ever get to developing using .NET I'll keep your tool in mind ;-)

Stefan Mensink

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 5:53 PM

I use LLBLGen all the time and am anxious to try this out (hopefully within the next 2 weeks). If it is as awesome as I am assuming, I will definitely be purchasing this puppy!

Thanks!

Jason Bunting

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 09, 2003 10:35 PM

How will you make money selling it so cheaply? I would think that support alone would kill you.

Billy

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 3:16 AM

Billy: I don't have to pay a large amount of developers: I wrote the complete tool myself, we funded the development ourselves, and therefore we can offer the tool for a reasonable price and still make money. :)

Jason: I'm sure it won't be a dissapointment :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 10:59 AM

I am looking forward for the sample. Please let us know here. Thanks!

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 10, 2003 11:03 AM

Abdu: okidoki :) I'll update the blog as soon as it is ready. Currently the datagrids do not co-operate as I intented ;) so it will take another day or so to get it polished :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Thursday, September 11, 2003 12:08 PM

Frans,

I'm so excited about this application, but I'm having a hard time putting it to work. I have to do a quick 1-page site to demonstrate some problem with a proxy server, so I figured it would be a perfect time to play around with the demo version while I'm waiting for my boss to buy the full version for us (which we are definitely doing, btw).

I'm trying to create a Class Library, following the directions in your help file, and the thing won't compile. I swear I'm not a complete idiot about these sorts of things, but here's what happens:
--Create new Library project in VS.NET (2002). Called it cNorthwind
--Generate code. General Config/VB.NET
--Copy all code into new project folder. Select and include all folders/files in VS.NET, so they're part of the project. Add the references that you specify. (SQLServer, ORMSupportClasses, System.EnterpriseSErvices)
--Try to compile. Boom.

The problem is that all the errors are due to missing classes that are trying to be imported, i.e. "Imports SD.NorthwindDAL.FactoryClasses", etc.

It's the classic chicken-or-egg problem... The classes won't compile if they can't reference other classes that need to be compiled, which themselves won't compile because yadda yadda yadda.

I'm sorry if I sound like a complete idiot on this, but I was able to make the last (free) version work.
:-P

Matt

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Thursday, September 11, 2003 12:15 PM

Matt: It's a faq, it's a thing with VB.NET: if you define a namespace that is different from teh name of the vs.net project, visual studio (or the vb.net compiler) will prefix each namespace name defined with the name of the vb.net project. Here's the faq on the customers area, I'll also add this one to the general faq on the site. If this doesn't help, mail me directly. :)
---
When I compile the VB.NET code I generated with LLBLGen Pro, I get all kinds of errors about missing namespaces, what's wrong?

You have specified a different name as root namespace than the name of your Visual Studio.NET VB.NET project. When this is the case, Visual Studio.NET will prefix each namespace with the VS.NET project name. See the note in the LLBLGen Pro documentation: Using the designer / Generating Code, at the bottom.
----

Frans Bouma

# re: inheritence@ Sunday, September 14, 2003 3:41 PM

Nice tool!

Does it support inheritence (with multiple tables)? for example:
Article (table Article)
ArticleExtended (table ArticleExtended, 1-1 link to table Article)

The ArticleExtended class should also be returned as Article.

Regards,

Marco

Marco

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 14, 2003 3:52 PM

Not at the moment no. The reason for this is that inheritence is not a concept that is definable in a relational model. If you have a 1:1 relation between two tables, you can also merge them to one table in theory.

We decided we should stay close to the relational theory and have created a tool that is based on the theory that is also the base of the E/R model, the base of every relational database schema, in other words: a relational model should be definable with solely DDL. Inheritence is then almost impossible to define (you need values in columns to distinguish classes in the hierarchy). We can always extend it in the (near) future.

It does generate mappings for all relations automatically, so if you have an extended article, Article.Extended for example will give you the extended info in your schema, it will traverse the 1:1 relation for you.

Frans Bouma

# re: Get rid of the 'file' concept for sourcecode!@ Monday, September 15, 2003 8:49 AM

Being a smalltalk developer, I found your comment amusing :)

I've been developing with these new age features for more than 10 years. As far as I'm concerned, Visual Studio, Intellij, Eclipse, etc. They are all a major leap backwards for me.

The ability to write code anywhere in the "IDE", select it, run it, test it, debug it, reload it, modify it, without having to stop/restart is incredibly productive.

I can't understand why more people are ignorant to smalltalk.

Take my advice. Take it for a test run. Get over the syntax hurdle and embrace the past.

James

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 15, 2003 6:21 PM

Very Nice!

Frans,
Could you explain a little how the Dynamic Query Engine works? Are you simply building a string and sending it as the text of a Command object - or is there more to it?

TIA,

DM

DM

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 16, 2003 2:44 PM

DM: It builds a string with the SQL, using the filters, relations and fields it receives. It also builds a list of parameters to pass on to the command object for the values specified as values for the query. So the SQL is build using a stringbuilder, the values are passed in parameters :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 17, 2003 12:11 PM

Excellent tool, Frans
I'll bet your wife is as happy it is finished as we are :-)

Just to keep nagging you with the same questions over and over again: I regularly develop websites for non profit orgs (in my spare time) that can't afford SQL server like my regular customers. Is there any chance you'll develop a MySql driver, using the excellent ByteFX driver for instance (http://sourceforge.net/projects/mysqlnet/)? -and if yes, is there some kind of a roadmap for future database support developments-

Dirk Devriendt

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, September 17, 2003 1:13 PM

Dirk: she is :)

Currently, Oracle driver is in development, DB2 driver is halted for now, since IBM hasn't released a solid .NET driver yet. Further databases which will get support after Oracle are: Firebird/Interbase, Postgresql (both have a driver by Carlos, which works ok) and if I can get it running, MySql 4.x. Because an important part of a schema is the set of foreign keys, it is necessary that MySql supports that. I heared that newer versions do so, so it shouldn't be a problem. However I think that with the planned support of Firebird and Postgresql you won't need MySql :)

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 8:50 AM

This is a case where you wouldn't use a break after every case if statements 1 and 2 have the same output.

for(int i = 0; i < 10; i++)
{
switch(i)
{
case 1:
case 2:
case 7:
Console.WriteLine("Hello {0}!", i);
break;
}
}
Console.Read();

Jeff Julian

# re: Useless programming language constructs@ Friday, September 19, 2003 8:51 AM

But you also have to remember that there are more options than just break (as well as the ability to specify multiple cases:

int i = 3;
switch(i)
{
case 1:
Console.WriteLine("ONE");
break;
case 2:
Console.WriteLine("TWO");
break;
case 3:
Console.WriteLine("Three alone");
goto case 4;
case 4:
case 5:
Console.WriteLine("3,4,or 5");
break;

}

Scott Watermasysk

# re: Useless programming language constructs@ Friday, September 19, 2003 8:59 AM

Multiple cases are indeed without 'break' but they share the same code block, I was refering to case statements which do have a separate code block and thus have to have a break statement too

The necessity to specify goto is the sign that the limitation of 'not having fall through' is wrong. If they just remove that limitation, it would be much better: you should specify break when you do not want fall through (and you already do so now) and you don't have to mess with goto crap when you want fall through.

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 9:03 AM

You're not 100% correct on the second issue (WithEvents in VB.NET). When you said:

"when you leave out the 'WithEvents', you can't define an event-handler."

That's not totally correct. You can define an event-handler, you just can't automatically wire it up with the "handles" statement. Instead, you must use the AddHandler statement.

So your choices are:

private withevents x as Button
and
public sub eventhandler(...) Handles x.Click

-- OR --

private x as Button
AddHandler x.Click, AddressOf eventhandler

Patrick Steele

# re: Useless programming language constructs@ Friday, September 19, 2003 9:06 AM

Ah, thanks Patrick :) I should have said 'can't define an event handler with visual studio.net'.

Frans Bouma

# re: Useless programming language constructs@ Friday, September 19, 2003 9:47 AM

I atcually think the ReadOnly/WriteOnly thing for properties is a Good Thing. It lets the compiler tell you "You wrote a property with just a Get or just a Set. Are you really sure you want to do that, or did you just forget?"

Dave Rothgery

# Useless language constructs@ Friday, September 19, 2003 2:48 PM

Why things the way they are.

TrackBack

# re: Useless programming language constructs@ Friday, September 19, 2003 5:07 PM

One reason you have to eplixitly specify a break in c# is because _a lot_ subtle coding errors in C and C++ come from the fact that you forget to say "break". This way you have to clearly state your intentions.

Fredrik Tonn

# re: Useless programming language constructs@ Saturday, September 20, 2003 7:03 AM

The mandatory overrides is IMHO good. Imagine you subclass a class and define new virtual method on it. Vendor of the subclassed class would eventually distribute new version, which has this method defined too. Than the compiler would scream, that you're trying to define new virtual method (virtual keyword) when you maybe want to do override.
This way you know, that you're doing something, that you're maybe not supposed to do (new vs. override keyword)

Jakub Skopal

# re: Useless programming language constructs@ Saturday, September 20, 2003 8:06 AM

Jakub: it's not the overrides, it's the overLOADS which is bogus. :) Overrides automatically implicitely says there is another method THUS it also overloads.

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Sunday, September 21, 2003 7:53 PM

I'm impressed; bought the Pro version and got my existing framework working in no time with the generated code (I already used a similar setup, that however cost me a LOT of codewriting). Thanks a lot for a great tool!
MySql is just very widespread as a free database solution for cheap hosting solutions. The ByteFX driver I mentioned very closely follows the standard MS driver signature, so if you can build your catalog and map the datatypes, The runtimelibraries should be rather painless. It 's far superior to other non-GNU drivers, even when it's still in beta (since they're adding a PostgreSQL driver as well)

Dirk Devriendt

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Sunday, September 21, 2003 9:57 PM

This bug was making me very upset and I could not understand why it was still happening, even though I had turned off all auto-formatting options in VS.NET. I just found out that is a well-known bug.

Not only the editor is having this irritating "I-will-do-it-for-you” behavior, but also the final "smart" formatting that is applied is (usually) completely messed up. A child programmer would have done better.

A workaround that I have been using, whenever the editor messes up the HTML code, is to copy and paste the HTML code to an blank XML file, apply the XML auto-formatting (with line breaks) and copy it back to the HTML. The XML auto-formatting feature is much more intelligent and neat than the HTML one and, usually, complies with my HTML indentation style.
I hope the hint helps someone else.

Marcos

Marcos Nowosad

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Monday, September 22, 2003 11:57 PM

LLBLGen Pro is GREAT! I just bought it and installer it and like Dirk was able to replace my Deklarit framework pretty easily.

Now if I only knew how to pronounce the name so I could sing its praises to the world! :)

--Bruce

Bruce Onder

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, September 23, 2003 3:36 AM

Great feedback, Guys! :)

Frans Bouma

# re: Stop ranting about the blaster worm@ Wednesday, September 24, 2003 9:11 AM

>If MS did their job well, this would not have even been an issue in the first place.
>Do it right the first time, or not at all.

If you could start by copy-pasting other people's quotes correctly...
And Frans is talking about those coders, haven't you just read these next few lines as well or are just just plain st*@(*d?

Dennis v/d Stelt

# I don't understand the longhorn-hype@ Monday, September 29, 2003 5:29 AM

TrackBack

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:37 AM

Agreed!

I guess the reasoning behind this is they consider that the current versions work well enough. And they want to avoid touching it because changes may be break them in unpredictable ways.
Microsoft prefers to start a new beta program with a lot of bug to fix than introduce more bugs in a deployed release.

Fabrice

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:55 AM

Alot of it, I think, is that we just simply get used to the foibles and work around them. I have one major shell complaint: when you have a large number of files in a folder,say 500-3000, not only does the shell load way too slowly(especially if they are pictures), but if you switch from Tile to List, the list view doesn't paint properly and you end up with 2 or 3 files in each column off the screen. The result of this is that I automatically hit refresh after changing the view type, because I know I'm going to have to.

Another large part is, does anyone ever complain about such things? Has it occured to anyone to email microsoft to complain about where the taskbar properties shows up? Until reading this post I hadn't even considered an issue with it, it was simply "there", and I would automatically move my mouse there, To be perfectly honest, changing it now would confuse me more than it would help, I'm far too set into that pattern. I agree it is a little bit of a strange behaviour, but it is cleanly set into my mind now.

Another piece is maybe, just maybe, most people like things the way they are in situation A, or no one can agree on what behaviour situation B should exhibit, so they do something and let it be. In any system you work with, you are going to find things that you don't like, its just a fact of life. It applies to computers, cars, tv's(takes 3 buttons to set the sleep timer, I think it should only be one), microwaves(I have to press a cook button before I can put in the time to cook. why? Its a damn microwave, I obviously usually use it to cook.), and lawnmowers(one pull ignition takes 3-5 pulls). If you move on to Linux, MacOSX, FreeBSD, whatever, I'm sure you will find things you don't like about that system too. And I'd be willing to bet that some of the things you don't like the primary developers will not change because they or a majority do, or because its minor enough that its pretty far down the list. Sure, in some of them you can go down and change it yourself, but if you have time to hack into and recompile your system code everytime you think something should be different, then I'm jealous of the amount of time you have.

Now, I agree that Microsoft does a bad job on fixes. Having to contact product support services to get a QFE to something is really silly in my opinon. Especially since half the time you don't even know a patch exists until someone tells you on the newsgroups. A granular, automated, system wide update tool is needed. By this point it should be beyond easy to be well aware of every patch Microsoft has available for windows, office, or any other microsoft software, which patches you have installed, etc.

The open source community has the luxury of releasing bug fixes every step down the line, of course, they can also release 80 minor versions a year, or even nightly builds. It is simultaenously an advantage and disadvantage. While its easy to keep your products up to date with bug fixes, etc, it is impossible to ever really be caught up or maintain feature equivilence across the board. I imagine it can make support and training a nightmare, because person 1 has 1.1.1, person 2 1.1.2, person 3 1.1.2.1b, and so on, especially if 1.1.2b adds a menu entry or changes wording slightly.

The open source and small companys have that luxury; Microsoft needs to find a way to provide equivilant fixes and feature upgrades to its users. I just don't see how they can realistically do it. With the level of security scrutiny and testing they are expected to provide, how can they? If they were to make a quick fix for something not vital and it changed something distant, something no one expected(and stuff like that happens, you know that, no matter how rarely), it is a very straight forward fact that the media and the users would roast the company for it. If Redhat did it, no one would give a damn. There is politics in this too. It is unfortunate, but sometimes it is us, the users, that make it impossible for Microsoft to provide us with the services we demand.

If you expect perfection, the only thing you will probably ever get is perfect disappointment.

I dearly hope no one really expects Longhorn, or anything else for that matter, to be perfect, it will not be, it cannot be, nothing ever is.

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 7:41 AM

I hate to say it (I am not one of those anti everything Microsoft types), but my belief is that this is the result of the dominance Microsoft has in the marketplace. In comparsion to say, the car market where there's lots of competing players around - new cars are released around once a year, if the new model isn't as good as the competition, people simply buy the other model. Both cars essentially offer the same features for around the same price and you could say that they run on the same 'platform' (ok, bad pun...it's a road...). Bugs in cars are extremely costly for the manufacturer both in terms of repair costs and in terms of future sales (would you buy a car who's gas tank explodes? Would you buy another car from the same manufacturer?). Basically if you work in the buisiness world ,you have very limited choice in the software you run, one company in essence controls the roads AND the cars.
Bugs in the products they supply don't really affect future sales - there's no real competition so the spectre of potential lost sales is very minimal - Linux and OpenOffice are not percieved as real alternatives (ask around a normal office - who's even heard of OpenOffice?).
One thing in Microsoft's defence, bugs are in general just annoying (though in terms of Security, they can prove VERY annoying) - they probably won't kill anyone. Also, the products are pretty good (I have WAY more issues with OpenOffice / Star Office than MS Office 2003).
I also don't begin to imagine that Longhorn will be perfect - but I do believe that for the ordinary user it will be WAY ahead of the competition (umm...not counting Macs here...that's a fantastic OS...they just lost the war when it comes to user base)...

Scott Galloway

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 7:57 AM

There could be a few other reasons too.

First, fixing any kind of bug increases revenue by... zero? There simply is no finanacial impetus for MS to spend any more time than absolutely necessary on things like bug-fixing. Unfortunate but true.

Second, however much one may argue MS never truely innovates, one thing they have made a name on is working feverishly to stay ahead of the curve. Focus on the future - oddly enough, the antithesis of "Where do you want to go today?" - and pour money and resources into the next product, the next release.

I've questioned time and again recently a concern that this time they may actually get hurt. Literally hundreds of bloggers are posting delerious items about this year's PDC to the point that some are even begging for donations to attend now. In the meanitme MS is not only foregoing an XP service pack for another 3 quarters, they are not working on any new versions of some of their existing products - including IE. There _are_ competitors out there making good products and supporting them. Products that run _today_ on today's PC. In the meantime MS is focusing on a killer OS that won't see the light of day for at least 2 more years and virtually no machine out there right now could even run it!

Dave

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 8:50 AM

Daniel: good solid piece of writing. Your remark "If you expect perfection, the only thing you will probably ever get is perfect disappointment. " deserves to end up in a lot of signatures :) I agree that perfection can't be achieved easily, however I get the feeling Microsoft isn't even trying: after a release there will be errors and bugs but MS refuses to patch these.

The myth about 'it might break something' is IMHO totally bogus. When a piece of code isn't working as planned, you should make it work as planned. That doesn't have to require interface (code) changes, just reimplementations of current code.

Scott: I agree, however I think Linux will be an alternative for a lot of people within a year. KDE and Gnome are really on track to become solid platforms.

Dave: Exactly. I think it is revenue driven not to patch a lot or better: to spend a lot of resources on customer support. On the other hand, they have enough revenue to get customer support on a higher level and still make money.

Frans Bouma

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 10:24 AM

My shell restarts very infrequently and when it does i always assumed this was because of a 3rd party app hanging the system. I would rather have restart called and have the OS pull out of the nose-dive as opposed to having to give a 3 finger salute and start all over possibly losing work. I never attributed the restart to a known bug in the shell that they refused to fix (maybe im wrong?). As for the other issue of the properties dialog, I cannot reproduce this on my system nor have i ever seen it on anyone elses (even on dual monitor setups). That issue not withstanding, I havent obeserved many other bugs of this nature either.

But besides the fact that i dont agree with the specific issues you raise, the overall sentiment i can agree with.. especially the one about competition. I hope OSS gains more momentum and puts more pressure on MS to start delivering better products at more competitive prices.

Ray Jezek

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 12:40 PM

I agree with your sentiments regarding the lack of bug-fixes.

But regarding your post title "I don't understand the longhorn-hype":

I think you understand the hype very well - people are excited about a new OS, and XP is old news.

Frank Showalter

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 12:50 PM

"I think you understand the hype very well - people are excited about a new OS, and XP is old news."
Well, I understand that the hype is there and what's causing it, and at the same time do not understand why the hype is there, because XP might look old news, it will still be the reality for the next 2 years to come, without a big improvement in sight (perhaps a new moviemaker, oh the joy). People should realize that hyping the next-generation OS is not what we need, we need focus on today's problems with solutions available today, not tomorrow nor next year but today.

Frans Bouma

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 1:23 PM

Amen! I agree 100% with you Frans. This is something I've blogged about before, too:

http://dotnetjunkies.com/weblog/plaudeman/posts/1811.aspx

http://dotnetjunkies.com/weblog/plaudeman/posts/1540.aspx

http://dotnetjunkies.com/weblog/plaudeman/posts/1111.aspx

Keep it coming! The more voices that speak out together give us a greater chance that we'll be heard!

Paul Laudeman

# Frans doesn't understand the Longhorn hype@ Monday, September 29, 2003 2:09 PM

TrackBack

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 4:56 PM

Another thing, after sleeping on it, one of the things I'm looking foward to in longhorn is the hope that some of the major platform issues that cause programs to break (COM plugins, etc) may be resolved as .NET style designs are used....that may still be a dream however

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 6:47 PM

Let's face it: it was hype that got people to purchase Windows XP in the first place. Windows 2000 had been out for a good 2 years when it was released. The smart consumer would have purchased Windows 2000 back in '99, skipped the incremental Windows XP release and had a solid and financially smart 6 years between OS upgrades. That is unless of course you managed to justify spending $100-$200 on a brand new skin and a new login screen with pictures. People need to start making smarter choices as consumers. You don't complain to car companies when the release a new model each and every year, do you? No, you just don't buy it. Period.

Derek Stone

# re: I don't understand the longhorn-hype@ Monday, September 29, 2003 10:51 PM

"You don't complain to car companies when the release a new model each and every year, do you? No, you just don't buy it. Period."

True, but if said car company refused to maintain their products that were over eight years old, I would complain. And, look for another car company.

I beleive that Microsoft has some really innovative products, but that their biggest product, Office, is peaked and invation saturated. How much more can you change a word processor? How many more features can you add? I agree with Fran, if you want to keep the client, fix the bugs.

I see in corporate offices the decision makers are asking why they need to spend more money on technology. How can the CIO justifiy spending more money on a tool they just bought two years ago and probably haven't even fully amortized yet. A goat takes five years to amortize, why should a word processor be any less?

If your not part of or contributing to the bottom line, you are overhead. Overhead is dispensable.

Darren Pruitt

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 7:30 AM

Now Darren, I believe I must disagree. A year ago I'd stand alongside your comment about Office and new features and changing word processors. But have you checked out those exact things in Office 2003? InfoPath and native XML come to mind immediately.

Granted, at this moment those two things are completely meaningless to 'consumers', but given a year or two of developers creating their part and, well, I find Office 2003 to be the first version with significant improvements since Office 97.

Oddly enough, MS in many ways did get it right with Office 2003. First off, the new features I just mentioned are very good reason to purchase it - reasons that didn't exist for Office 98 through XP. I realize this also means MS gets the increased revenue too, but then again... during the development/beta cycles for 2003 they also released a slew of SRs too. Something they don't seem to be doing for Windows XP.

Dave

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 9:09 AM

1995
====
Bob: Boss! There's a great new Office product to go with that new OS!

Boss: Great! Email!?! This will help productivity! Get it for every one!

1997
====
Bob: Boss, there's a new Office product out, it fixes a lot of bugs!

Boss: Great! Bugs are bad! You computer guys sure are helping out the company!

2000
====
Bob: Boss, there's a new Office product out, it is Y2K compliant.

Boss: Well, this is getting a bit expensive but corporate did just make it the standard. Make sure everyone gets a new Anti-virus too, someone out doesn't Love Me.

2002
====
Bob: Boss, there's a new Office product!

Boss: No.

Bob: It has increased security!

Boss: No.

Bob: It looks cool!

Boss: No.

Bob: There's someone fromt eh BSA at the front desk.

Boss: What! Ok, we can upgrade, but we have to lay off half the IT staff. We can outsource the help desk.

2003
====
Bob: Boss! There's a new Office product!

When will it end?

Darren Pruitt

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 9:26 AM

Dave: XML functionality is part of open office since a long time. It's nothing new. Besides that, the point is: when I start word, I want to type some texts, save it, print it whatever, but I want the tool to HELP me with the processing of the words. Now, with Word XP I still have errors in headers, bullet lists, table crap etc. No offence, but Word XP is the 2002 version, why are these simple bugs still bugging me in the year 2002, in version 11 (!) of a wordprocessor ? And! why aren't these fixed but is a NEW version released for 400$ which seems to fix these bugs (I hope)? The functionality I want/need is already in word 2000, even in word 98. I just want it to work OK, without bugs. So instead of bringing out new releases for money which have new features, it would be great if the current version is bug free. Now, when that happens, no-one will upgrade, true, but when MS is following this path of 'Flaws == revenue', more and more people will understand that f.e. Open Office is as good as MS office, if not better and costs less (0$).

For MS, they have to realize that they're at the end of the line for office: there will be less reasons to buy new versions, because people get annoyed or alternatives are as good and cost less.

For me, I'll never go back to MS Office again, because the alternatives are IMHO of better quality and cost nothing. I'm willing to pay for quality, don't get me wrong, but I also judge on quality: if the tool is not worth the money, I won't buy it. MS office is IMHO a huge pile of badly maintained software, with a lot of weirdness that is not addressed in whatever version you purchase. (Word never had a good table editor, and it will surprise me if the 2003 table editor is of the quality of open office).

So, MS should focus more on quality to KEEP existing customers: make the customer feel that they are appreciated, serve these customers with frequent updates so the customer is helped. This will cost revenue, but if they are not doing this, they will lose customers to competitors who have a better product and it takes a huge pile of effort and money to get customers back.

Frans Bouma

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 11:04 AM

Derek-the difference with car companies is that they can be forced to recall vehicles to fix problems that are wide spread-at no cost to customer. They also have the warrenty itself to cover the vehicle. There are guidlines for safety set forth by the government that they must adhere to. Would you except it if your model's A/C system failed and the dealership said wait for the '04 model it should be fixed in those-for 16,000 dollars? Microsoft has no accountability-that's the problem. Mercedes-benz had a slew of issues in the last few years with the managment of all the new electronic systems and they were forced to buy back all the e-class models that were having issues. Oes microsoft buy back copies of office-no.

ethan estes

# re: I don't understand the longhorn-hype@ Tuesday, September 30, 2003 4:55 PM

Frans, sure XML functionality has been part of 'open office' or even MS Office (in case you meant StarOffice or whatever). But _native_ XML storage of Excel spreadsheets? XSL formatting? You might as well say do your webpage development in Word and use the utterly useless "Save as HTML" feature for comparison.

I never meant to say that Office was bug-free, onl.y to say that MS never stopped publishing coherent bugfixes while developing a new version. Which is something that they are with Longhorn.

Derrick, please note I did not say Office 2003 offered _immediate_ paybacks to the 'consumer'. Only that the development features I mentioned will in time be used by the consumers in ways that will IMHO make it considered the next 'true' version since Office 97, when Outlook became an official part of the product.

Dave

# re: I don't understand the longhorn-hype@ Wednesday, October 01, 2003 4:17 AM

I have to say the XML features of Office 2003 are of great value to me. Even if open office can handle xml, not a single one of my customers uses open office. Not to mention I don't really want to maintain two code bases to handle MS Word and OO Writer interop\document generation(assuming feature parity...I imagine most of the features exist in both), same goes for Excel, etc.
At one time, during a budget crunch, I suggested using OpenOffice to a local small company to save money. The owner asked me three questions which pretty much killed the subject: 1) How much would it cost to re-write everything to work with the new suite(they use 3 apps that interact with word and\or excel) and several smart tags, 2) how likely is it that they could find, say, a new secretary that was trained and able to use it immediatly, 3) how much was it going to cost to switch back if people lost interest in OpenOffice and stopped working on it.
After sitting down and thinking about it, buying office for the new pc's was _MUCH_ cheaper. Add onto that I was never able to verify if OpenOffice could handle smart tags, which they wanted(really cuts back on the work, as they interface with the customer, employee, etc database), and the decision for OpenOffice died on the floor, MS office was just cheaper and more productive.

Point is, $0 price tag doesn't always make things cheaper.

Daniel O'Connell

# re: I don't understand the longhorn-hype@ Thursday, October 02, 2003 12:07 PM

- If you look at the reliability of Windows starting from 3.1 to 2003, the OS has been improved alot and with many new productivity features. MS could have improved 3.1 for 13 years and give us a rock solid Windows 3.1 but MS is in the business of making money and companies would have moved to Novell, Unix or Mac if Windows 3.1 stayed with its current features. MS needs to fix its security and the updates feature. I read just today that MS admits that its security update strategy is flawed and will patch it using a new method.

I like MS products and they have increased my productivity as a user and as a developer many times. My only gripe is that every new version demands more computer resources. However I don't mind upgrading my computer every 2 years. Need to do this anyhow for games too :)

If there's anything you don't like about an MS product, you need to let them know. If enough people complain, they will notice and hopefully do something. It doesn't them any good if you complain quitely.

Every product I use has annoyances and you learn to live with them or use something else. For example, my inlaws' Blazer's cupholder is the most idiotic one. It doesn't have enough depth to hold a tall cup and has no grip. I have to take easy turns to avoid spilling the cup. Can I call this a design bug?
My alarm clock off button is in an obscure place. I have to be 60% awake to find it and turn it off. Time to buy a new one. .. and so many other annoyances.

Abdu

Abdu

# Can ASPNET read the registry or not?@ Thursday, October 02, 2003 3:34 PM

TrackBack

# re: Why Edit & Continue is a bad thing@ Sunday, October 05, 2003 1:12 PM

As a VB6 programmer by trade, I prefer C# as a language ; Whenever I try VB.NET, I start to unconsciously use VB6 syntax. And since I'm still working on active bodies of VB6 code all the time, I don't really need VB.NET syntax cluttering up my head and taking over.

But I really miss Edit & Continue when I write C# code ; particularly because I'm still learning C# and the .NET class libraries. While a lot of things will be caught by the compilers, and I agree that test-driven development is the way forward, E&C really helps you learn.

I came to software development with zero professional experience from the medical profession : I was pretty much thrown staight in at the deep end and had to learn VB6 in a matter of weeks (on the redoubtable foundation of BBC and Spectrum BASICs). E&C was a great help ; when you've put a couple of parameters round the wrong way because of inexperience, it's a great boon to be able to shift the run pointer back a line and swap them round.

The other thing I miss with .NET is the ability to execute code in the immediate window without being in break mode ; the VB6 immediate window has many uses, from looking up character codes without having to trudge through the help, performing large calculations that you don't trust the default calculator with, etc.

Convenience features don't make you less of a "man". And you don't always have the luxury of well-structured code with decent testing frameworks ; very often, you're working with code that others wrote, and of questionable quality. My time maintaining our huge, ancient VB3 app has made me very, very glad of E&C.

Dr_Barnowl

# re: I don't understand the longhorn-hype@ Monday, October 06, 2003 8:20 PM

Explorer loads lots of 3.party DLLs in its process space. In fact it can host IE, Thumbnailviewers (e.g. thumbnails of .eml-files) and lots of extensions to the menus of files.

I wonder whether such a thing can ever be stable!

But you can just replace the explorer.exe-shell with cmd.exe or Cygwin Bash if you want. Or progman.exe (in XP). Just do it!

Me

# re: Eric Sink's crabbyness@ Saturday, October 11, 2003 8:21 AM

Yep, this post is really funny and worth reading ;-)

Christophe Lauer

# re: Eric Sink's crabbyness@ Saturday, October 11, 2003 8:56 AM

Not only is a good writer but he has a terrific sense of humor as well - http://notalegend.com/notalegend.html

SBC

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, October 14, 2003 11:38 AM

I hope you're working on the examples. It has been over a month since my request and I've heard nothing.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Tuesday, October 14, 2003 12:01 PM

Abdu, erm...
http://www.llblgen.com/pages/demo.aspx

the current example (VB.NET or C#). It's released on the 19th, updated on the 30th.

The blog is also updated with this. :)

Frans Bouma

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 15, 2003 3:50 PM

Ok thanks. I wasn't aware of the update.

Abdu

Abdu

# re: It's released! LLBLGen Pro is gold! The next-gen O/R mapper for .NET.@ Wednesday, October 15, 2003 3:54 PM

No problem :)

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:17 AM

Interesting read. I never thought about .NET from this point of view.

Although you are probably right about .NET the lack of support for vendors other then MS, but I would think it’s fair to say “WE” could fill in the gaps ourselves with a strong open-source initiative.

Paul Gielens

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:18 AM

Is Scott McNealy blackmailing you? :)

But seriously, I agree with most of your points, although I think stuff like MVCC and synonyms will probably reach Yukon.

I'm not sure about the rest though. Also, I must admit I've never used UDTs, but I agree that for large-scale db applications, they're probably extremely important. Also, they tie in well with the whole schema approach, that basically encourages (or rather forces, but in a good way :)) to just make a single environment housing all your data and then creating schemas for individual applications. If you use UDTs there it can save you a lot of time if you create those custom types with generalized functionality in mind for all the different applications that might have a table in their schema containing one of those UDTs. In SQLServer people often don't bother because they'll have another database for "that other" application anyway. Which in turn encourages long-term chaos.

Jeroen

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 7:31 AM

Jeroen: Larry didn't need to, he just gave away a free version of Oracle 9i for developers to download :)

You are very correct about the UDTs and the chaos and the simplicity of maintenance. It really worries me why I haven't read anything about them in the Yukon hype that is available.

Paul: The limitation is in the DataColumn type in .NET, it doesn't support custom types. That pretty much kills UDT support, unless you are using an O/R mapper with custom classes. At the moment these tools are left in the cold by both Oracle and MS because both their providers are not supporting UDTs. (Don't know about the commercial providers though, but these are extremely expensive). Nevertheless, to unleach the true power of DB2 and Oracle in an OO fashion, you have to write code in Java inside the database and call that code from .NET. You then have to be a very very pro-.NET person to pick .NET for the logic outside the database. I'd then opt for Java / J2EE also.

Frans Bouma

# re: Oracle 9i is already generations ahead and shows a .NET flaw.@ Monday, October 20, 2003 8:19 AM

Nice review, i've some thoughts also...
1) UDT is not connected directly to Java but usable in it- through very similar to strongly
typed dataset realization but support in-
DB generation of "beans"="row mappings".

2) "native" UDT language is "PL/SQL"(4GL) language written on c++, not Java
(Java VM is optional component of DB and
most DB gurus use "PL/SQL" packages/procedures
architecture in real work).

3) True power of relational data is flexibility
in operations but when you try to "enforce" some kind of "schema" on it- you lose that.
I mean, did you try to use this "wonderful"
UDT functionality in big project?
I think not, because you'll see that it's
really hard to change UDT/object schema-

Frans Bouma's blog

This Blog

Syndication

Search

Tags

News

Navigation

Archives

About me

Fun stuff I created

My work

Comments

# re: I'm alive!@ Monday, May 05, 2003 11:04 PM

# re: I'm alive!@ Monday, May 05, 2003 11:06 PM

# re: I'm alive!@ Monday, May 05, 2003 11:55 PM

# re: I'm alive!@ Tuesday, May 06, 2003 12:05 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 6:48 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 7:12 AM

# Frans Bouma's blog@ Tuesday, May 06, 2003 7:59 AM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:37 PM

# re: T-SQL Tip of the day@ Tuesday, May 06, 2003 11:44 PM

# re: I'm alive!@ Wednesday, May 07, 2003 1:59 AM

# re: I'm alive!@ Wednesday, May 07, 2003 3:19 AM

# Emitter@ Wednesday, May 07, 2003 4:03 AM

# ShowUsYour-Blog!@ Wednesday, May 07, 2003 4:28 AM

# re: It's not all bizznizz apps@ Wednesday, May 07, 2003 11:11 PM

# ISerializable@ Thursday, May 08, 2003 3:54 AM

# re: Borland's prices are too high?@ Thursday, May 08, 2003 6:31 AM

# re: Borland's prices are too high?@ Thursday, May 08, 2003 11:40 AM

# re: Relationships@ Friday, May 09, 2003 3:32 AM

# re: Relationships@ Friday, May 09, 2003 3:40 AM

# ISerializable@ Friday, May 09, 2003 6:30 AM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 4:43 AM

# re: Relationships@ Saturday, May 10, 2003 5:36 AM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 12:31 PM

# re: XPath in T-SQL?@ Saturday, May 10, 2003 8:51 PM

# re: Relationships@ Saturday, May 10, 2003 8:58 PM

# re: XPath in T-SQL?@ Monday, May 12, 2003 2:44 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:15 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:42 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 2:53 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 6:23 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 13, 2003 8:05 AM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 9:56 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:17 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 10:20 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:36 PM

# re: Stored Procedures vs. Dynamic Queries.@ Tuesday, May 13, 2003 11:47 PM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:13 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:21 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 12:27 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:27 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 1:53 AM

# Frans Bouma's blog@ Wednesday, May 14, 2003 4:24 AM

# Andres Aguiar's Weblog@ Wednesday, May 14, 2003 4:24 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 8:55 AM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:39 PM

# re: Stored Procedures vs. Dynamic Queries.@ Wednesday, May 14, 2003 7:50 PM

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003@ Thursday, May 15, 2003 12:06 AM

# re: Stored Procedures vs. Dynamic Queries.@ Thursday, May 15, 2003 1:47 AM

# Frans Bouma's blog@ Thursday, May 15, 2003 5:19 AM

# Frans Bouma's blog@ Thursday, May 15, 2003 6:01 AM

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:33 PM

# re: VS.NET 2003 isn't all that bad (sort of)@ Saturday, May 17, 2003 9:40 PM

# re: #define debugging testing@ Sunday, May 18, 2003 12:42 AM

# re: #define debugging testing@ Sunday, May 18, 2003 1:14 AM

# re: #define debugging testing@ Sunday, May 18, 2003 1:21 AM

# SBC DotNet Weblog@ Sunday, May 18, 2003 7:29 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:18 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:24 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:47 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 1:57 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:04 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:21 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:24 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 2:29 AM

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'@ Tuesday, May 20, 2003 3:29 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 4:33 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 5:17 AM

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!@ Tuesday, May 20, 2003 6:19 AM