re: No nullable types in VB.NET 2.0 ?

# re: I'm alive!

Monday, May 05, 2003 11:04 PM by Greg Robinson

welcome!

# re: I'm alive!

Monday, May 05, 2003 11:06 PM by Frans Bouma

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

# re: I'm alive!

Monday, May 05, 2003 11:55 PM by Paul

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

# re: I'm alive!

Tuesday, May 06, 2003 12:05 AM by Frans Bouma

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

# re: T-SQL Tip of the day

Tuesday, May 06, 2003 6:48 AM by Paul Gielens

This would be a nice LLBLGen 1 addition!

# re: T-SQL Tip of the day

Tuesday, May 06, 2003 7:12 AM by Frans Bouma

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's blog

Tuesday, May 06, 2003 7:59 AM by TrackBack

Frans Bouma's blog

# re: T-SQL Tip of the day

Tuesday, May 06, 2003 11:37 PM by Paul

Any movent in the LLBLGen workspace?

# re: T-SQL Tip of the day

Tuesday, May 06, 2003 11:44 PM by Frans Bouma

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.

# re: I'm alive!

Wednesday, May 07, 2003 1:59 AM by Eric J. Smith

Hey Frans! Welcome!

# re: I'm alive!

Wednesday, May 07, 2003 3:19 AM by Frans Bouma

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

# Emitter

Wednesday, May 07, 2003 4:03 AM by TrackBack

Emitter

# ShowUsYour-Blog!

Wednesday, May 07, 2003 4:28 AM by TrackBack

ShowUsYour-Blog!

# re: It's not all bizznizz apps

Wednesday, May 07, 2003 11:11 PM by Ridge

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.

# ISerializable

Thursday, May 08, 2003 3:54 AM by TrackBack

ISerializable

# re: Borland's prices are too high?

Thursday, May 08, 2003 6:31 AM by randy

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.

# re: Borland's prices are too high?

Thursday, May 08, 2003 11:40 AM by Ron Green

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

# re: Relationships

Friday, May 09, 2003 3:32 AM by Eric J. Smith

That's a big post Frans! :-)

# re: Relationships

Friday, May 09, 2003 3:40 AM by Frans Bouma

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. :)

# ISerializable

Friday, May 09, 2003 6:30 AM by TrackBack

ISerializable

# re: XPath in T-SQL?

Saturday, May 10, 2003 4:43 AM by Jon Galloway

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.

# re: Relationships

Saturday, May 10, 2003 5:36 AM by Eli Robillard

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

# re: XPath in T-SQL?

Saturday, May 10, 2003 12:31 PM by Jesse Ezell

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.

# re: XPath in T-SQL?

Saturday, May 10, 2003 8:51 PM by Frans Bouma

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.

# re: Relationships

Saturday, May 10, 2003 8:58 PM by Frans Bouma

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.

# re: XPath in T-SQL?

Monday, May 12, 2003 2:44 AM by Teun Duynstee

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.

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 13, 2003 2:15 AM by Jesse Ezell

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).

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 13, 2003 2:42 AM by Andres Aguiar

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...

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 13, 2003 2:53 AM by Frans Bouma

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.

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 13, 2003 6:23 AM by Paul Gielens

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.

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 13, 2003 8:05 AM by Andres Aguiar

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.

# re: Stored Procedures vs. Dynamic Queries.

Tuesday, May 13, 2003 9:56 PM by Paul Wilson

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.

# re: Stored Procedures vs. Dynamic Queries.

Tuesday, May 13, 2003 10:17 PM by Frans Bouma

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

# re: Stored Procedures vs. Dynamic Queries.

Tuesday, May 13, 2003 10:20 PM by Frans Bouma

(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.

# re: Stored Procedures vs. Dynamic Queries.

Tuesday, May 13, 2003 11:36 PM by Paul Wilson

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.

# re: Stored Procedures vs. Dynamic Queries.

Tuesday, May 13, 2003 11:47 PM by Frans Bouma

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.

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 12:13 AM by Jimmy

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
###

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 12:21 AM by Frans Bouma

:) 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.

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 12:27 AM by Jimmy

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
###

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 1:27 AM by Paul Schaeflein

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...

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 1:53 AM by Frans Bouma

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's blog

Wednesday, May 14, 2003 4:24 AM by TrackBack

Frans Bouma's blog

# Andres Aguiar's Weblog

Wednesday, May 14, 2003 4:24 AM by TrackBack

Andres Aguiar's Weblog

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 8:55 AM by JimS

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...

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 7:39 PM by Mike Woodhouse

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.

# re: Stored Procedures vs. Dynamic Queries.

Wednesday, May 14, 2003 7:50 PM by Frans Bouma

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.

# re: Serious ASP.NET Editor flaw lives on in VS.NET 2003

Thursday, May 15, 2003 12:06 AM by Ron Green

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

# re: Stored Procedures vs. Dynamic Queries.

Thursday, May 15, 2003 1:47 AM by Richard Tallent

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

# Frans Bouma's blog

Thursday, May 15, 2003 5:19 AM by TrackBack

Frans Bouma's blog

# Frans Bouma's blog

Thursday, May 15, 2003 6:01 AM by TrackBack

Frans Bouma's blog

# re: VS.NET 2003 isn't all that bad (sort of)

Saturday, May 17, 2003 9:33 PM by Zef Hemel

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.

# re: VS.NET 2003 isn't all that bad (sort of)

Saturday, May 17, 2003 9:40 PM by Frans Bouma

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.

# re: #define debugging testing

Sunday, May 18, 2003 12:42 AM by SBC

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

# re: #define debugging testing

Sunday, May 18, 2003 1:14 AM by Simon Mourier

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.

# re: #define debugging testing

Sunday, May 18, 2003 1:21 AM by Frans Bouma

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.

# SBC DotNet Weblog

Sunday, May 18, 2003 7:29 AM by TrackBack

SBC DotNet Weblog

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 1:18 AM by Jesse Ezell

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 1:24 AM by Frans Bouma

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 1:47 AM by Frans Bouma

*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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 1:57 AM by Paul Schaeflein

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 2:04 AM by Frans Bouma

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 2:21 AM by Thomas Freudenberg

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 2:24 AM by Jack

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

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 2:29 AM by Frans Bouma

[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.

# re: 'You want a Dataset with that DAL, sir?' 'No, thank you.'

Tuesday, May 20, 2003 3:29 AM by Sasha

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 4:33 AM by JimS

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)...

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 5:17 AM by Frans Bouma

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 6:19 AM by Phil Weber

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:01 AM by Sam Gentile

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).

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:08 AM by Stephen Fulcher

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?

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:11 AM by Frans Bouma

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:12 AM by Sam Gentile

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

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:18 AM by Frans Bouma

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:19 AM by Sam Gentile

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.

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:31 AM by Frans Bouma

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".

# re: ISV's: do NOT upgrade to Visual Studio.NET 2003!

Tuesday, May 20, 2003 8:59 AM by Sam Gentile

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.