hmm, it seems like i am falling into that category - That is if i convert my hourly rate to US$.

Believe me $ 20 per hour here is MEGGA BUGS!!

Yea, I make just barely above that, working in Indiana... Most of the .NET jobs around here that I see are hiring for $75K+ or so, and I make about 30K less than that. Really sucks to be a decent coder (at least I hope I am) and get paid at an entry-level rate. Heck, I took a C# test on Brainbench.com for the guy who introduced me to LLBLGen and scored better than 89% of the people who've taken that test. By far the highest score in Indiana, and I don't even use C#, yet I make entry-level pay. Gotta love working for a bank.

Ok, one more though occurs to me.

I had a friend who used to have me occasionally try this trick to remind me of the vast amount of learned, and now intuited, knowledge I had stored within me:

Take your mouse and turn it 90 degrees counter-clockwise. Don't turn your hand. Now do some things. Send an email, play solitaire, browse the web.

This is how a vast percentage of computer users see their machines. It's tough, and it makes you feel like a moron.

I remember an absolutely killer application I was a part of writing. It smoked. We took it up to the CEO, who installed it, tried it and sent back a note saying, "I ran it, but it didn't do anything. It just sat there looking at me."

Imagine you are a traditional ASP developer. You know recordsets, a little about the idea of datasets because you've been playing with VB.NET in your spare time. For them, the mouse is 90 degrees off from yours. Put yourself there.

Now run LLBLGenPro. What is it doing? What are you supposed to do? What does it want you to do? How will it help?

It just sits there looking at you.

The question is, do you want these (many, many, many) customers? Are they worth it? Will you cede them to Microsoft, or will you produce a product that jumps ahead of Microsoft's ability to get these people up to speed?

Ok here is a joke.

A young blonde was on vacation in the depths of Louisiana. She wanted to take home a pair of genuine alligator shoes in the worst way.... but was very reluctant to pay the high prices the local vendors were asking for the highly prized shoes.

After becoming very frustrated with the "no haggle on prices" attitude of one of the shopkeepers, the blonde shouted, "Well then, maybe I'll just go out and catch my own alligator, so I can get a pair of shoes at a decent price!"

The shopkeeper said with a sly, knowing smile, "Little lady, y'all just go and give it a try, why don'cha!"

The blonde turned on her heel and headed out toward the swamps, determined to catch herself an alligator .

Later in the day, as the shopkeeper is driving home, he pulls over to the side of the levee where he spots that same young woman standing waist deep in the murky bayou water, shotgun in hand. Just then, he spots a huge 9-foot gator swimming rapidly toward her. With lightning speed, she takes aim, kills the creature . . .and, with a great deal of effort, hauls it onto the slimy swamp bank. Lying nearby were several more of the dead creatures.

The shopkeeper stands on the bank and watches this scenario in amazed silence.

Just then, the blonde struggles and flips the gator on its back. Then, rolling her eyes heaven-ward and screaming in great frustration, she shouts out, "Darn, this one is barefoot, too!"

Definitely agree with you. Except...

swallace wrote:

The question is, do you want these (many, many, many) customers? Are they worth it? Will you cede them to Microsoft, or will you produce a product that jumps ahead of Microsoft's ability to get these people up to speed?

For these particular type of developers, I don't think marketing will work. First, they have to have a problem they need solved (data access) which they don't (VS effectively solves the problem for them with design-time databinding), and second they need to know they have a problem. At the point they realize they have a problem (the need for an abstracted data access mechanism) they've effectively removed themselves from the group of people we're talking about anyway. Now they join the target market and have moved up a tier and are no longer relevant to the conversation.

Aside from this scenario the only thing I see working is for MS to replace their current ease-of-development mechanism (GUI databinding to the data source) with an object-oriented mechanism such that it becomes the new and only way to do it. I can almost guarantee that it will be a plain-vanilla implementation that offers little in the way of features. However, it now provides the context in which LLBLGen can safely market their product; it will allow Solutions Design to now compete on features, and features the programmers can now understand.

Yes, SD will now be competing with the MS machine, but now in a market orders-of-magnitude larger than it's current market. And, it won't have to hold education as so much of a liability (which is largely out of it's hands) and can spend their time and effort in something they can control (marketing). Plus, it will be a new integration point (Microsoft will release an API here, I'm sure) with VS that SD can leverage to provide the same (witness SourceGear's Vault) level of integration that MS's own solutions provided.

And, in all of this, I'm not saying that it should happen or that it should happen this way. But, I am saying that it will happen this way (much arrogance here notwithstanding . The abstration of the data source has to happen, and it will happen, eventually. And those still in the game with all of the experience will reap the benefits, albeit in 3-5 years or more.

All this to say that it's my opinion that marketing to the so-called lower tier of programmers is wasted effort. They already have what they need in Visual Studio. Work to educate and attract the developers out there who recognize the problem - that's still a big market! - and focus the tool on those who can take advantage of it - at least until someone with the resources and the tolerance to risk (i.e., Microsoft) moves the industry to the next stage and brings the technology to the mainstream.

Jeff...

Jeff, you speak'um truth. Maybe I'm imagining an over-reach here. Hard for me to say. At this point in the argument I would review other markets and compare what's been done in those with this situation. Java, Delphi, Cobol (yes, Cobol) to see what happened, what the motivators were, who succeeded and who failed.

The Delphi example is amongst BDE replacements. The Borland BDE was terrible, and there sprang up a small market of replacements and tools to improve it, and to make ADO integration better. At first glance you'd think that Borland could have wiped them all clean by re-tooling the BDE, but they never did. I don't know what eventually happened, who won, and who the technical leaders were. It's a good study. There must be a good history to follow and learn from.

In fact, there's one building now in the UML/Case market with the release of the Team tools in VS.NET 2005. Lot's of arguments, questions about what companies will survive, who has the "pure" UML and the value of being "pure" UML. I imagine that some UML/Case tools vendors are asking themselves the question, do we re-tool to support VS.NET 2005's integrated tools in order to make them better, or do we continue to stand alone against Microsoft's integrated version?

And, wasn't that the question before Solutions Design when ObjectStore was in play?

You see, in my eyes, by the time Microsoft does it better, and raises the bar, it's too late. The window is closed, at least to reaching the twenty buck guys. At first they wouldn't go your way because your product was too hard. Now they won't because Microsoft makes it not only easier, but free. Not as fully featured, but still free. Sure, a dedicated set of professionals will still buy the best-of-class tool, but I contend that market will be smaller than it is today using today's tools, because of Microsoft integration. Again, this is where I would do a study to back up that completely bald assertion!

Facts? We don't need no stinkin' facts!

By the way, did you try the mouse thing? It's really wacky...

The management at my company are a bit worried at the momment - Will Solution Design still be around in the next 5 years? Especially that some of the other O/R Mapper Companies have folded.

Over here the clients want to know what tool you as a software house are using to develop and you have to really struggle to convince them that an non-M$ product is better.

That is because this company where i work has big corporate clients and our software is dependant on LLBLGen that makes the clients also dependant on LLBLGen. And in the corporate world everything changes slooowly. So it is possible that an exiting application can be in use and develop further with the current technology for the next 5 years. Yes i assume that you could still use the current LLBLGen in 5 years for your app but if there is no more Solution Design then there will be no more upgrades / improvements to the tool and that is what is scaring them in the long term.

wayne wrote:

The management at my company are a bit worried at the momment - Will Solution Design still be around in the next 5 years? Especially that some of the other O/R Mapper Companies have folded.

I can't answer that with any certainty of course, I can only say that with a big corp it is also not certain if your application is still around in about 5 years. Ask any VB6 developer about that.

We understand the concern companies have with this, although I sometimes find it a bit over the top: without questions they purchase and use 3rd party GUI controls but they have doubts with another 3rd party tool's continuation.

As much sourcecode as possible is opened for customers, so the vendor lock-in is minimized as much as possible. I've stated this more than once: when the time has come to let LLBLGen Pro go (i.e.: the end of life is there for the product), it will be open sourced to customers. If we go out of business (that's an 'if', and it's not very likely, but things can happen), the tool will also be open sourced to customers. This is more than you'll get with for example Microsoft: VB6 is discontinued (for 3 years already), still a lot of softwarehouses are depending on it. Do they have the soucecode? no, they have a choice to upgrade to .NET, but that takes a lot of effort and money.

Over here the clients want to know what tool you as a software house are using to develop and you have to really struggle to convince them that an non-M$ product is better.

Yeah that's true, fortunately, MS doesn't have a tool like it

That is because this company where i work has big corporate clients and our software is dependant on LLBLGen that makes the clients also dependant on LLBLGen. And in the corporate world everything changes slooowly. So it is possible that an exiting application can be in use and develop further with the current technology for the next 5 years. Yes i assume that you could still use the current LLBLGen in 5 years for your app but if there is no more Solution Design then there will be no more upgrades / improvements to the tool and that is what is scaring them in the long term.

I think they overreact a little . Here's why: one of the main problems developers have to deal with is data-access: how to embed the database seamlessly into your own code. You can solve this in various ways, one way is to use an O/R mapper. Now, data-access code is overhead, it's code you shouldn't write but you have to. To use a tool, you free yourself from doing that overhead work.

When the tool works as planned, it will solve that data-access problem for you. It will be doing that now and in the future, that doesn't change . So future upgrades are not there to make things possible which are not possible now, but are there to make life even more easier. Without upgrades, life still would be easy.

With the open architecture of the application, future databases can be supported, it's a matter of writing a driver. Also, the code generator is completely open and fully task based (like Nant) and allows you to add whatever task you want (with code you write). It is thus not as closed as it might seem and the lock-in is not that strict as some people think.

I know some big corporations are slow adopters, however some aren't. I won't say who but we have a lot of 2 and 3 chararacter .com domains among our customers, I think it's thus more about the conservative view the client has on the world than the size of the client as a company.

But concerns which live among customers or potential customers are important and have to be addressed. We toyed with the idea of allowing users to get access to the designer sourcecode as well. We held that off for now, but if a lot of customers require that, we might open that up as well, as a way to convince them they're safe, the code is accessable in the situation when they need it because it is discontinued for example.

Wayne, if your customers have any concerns, you can also send them over to me, I'll be happy to answer them.

I know that some tool companies implement some form of escrow to deal with this worry...

Jeff...

jeffreygg wrote:

Definitely agree with you. Except...

swallace wrote:

The question is, do you want these (many, many, many) customers? Are they worth it? Will you cede them to Microsoft, or will you produce a product that jumps ahead of Microsoft's ability to get these people up to speed?

For these particular type of developers, I don't think marketing will work. First, they have to have a problem they need solved (data access) which they don't (VS effectively solves the problem for them with design-time databinding)

You mean, for the 'hack-n-slash'-guys who write poor software for a low price? Ok, they will accept raw sql code in the codebehind of their webform

, and second they need to know they have a problem. At the point they realize they have a problem (the need for an abstracted data access mechanism) they've effectively removed themselves from the group of people we're talking about anyway. Now they join the target market and have moved up a tier and are no longer relevant to the conversation.

Very good thinking.

Aside from this scenario the only thing I see working is for MS to replace their current ease-of-development mechanism (GUI databinding to the data source) with an object-oriented mechanism such that it becomes the new and only way to do it. I can almost guarantee that it will be a plain-vanilla implementation that offers little in the way of features. However, it now provides the context in which LLBLGen can safely market their product; it will allow Solutions Design to now compete on features, and features the programmers can now understand.

True. With VS.NET 2005, it will be very easy to get our generated objects drag'n'dropped in gui's.

Yes, SD will now be competing with the MS machine, but now in a market orders-of-magnitude larger than it's current market. And, it won't have to hold education as so much of a liability (which is largely out of it's hands) and can spend their time and effort in something they can control (marketing). Plus, it will be a new integration point (Microsoft will release an API here, I'm sure) with VS that SD can leverage to provide the same (witness SourceGear's Vault) level of integration that MS's own solutions provided.

MS is not going anywhere with object oriented data-access though. They're completely conviced set-based data-access is the way to go. I never understood this, but apparently there are some closed minds on the buttons over there...

One of the biggest motivations they have is SOA. This is probably a bit of a theoretical discussion, and I'm not a Fowler fan per se, but SOA is in theory and on a very high level not compatible with pure, OO oriented domain model. With SOA, you orient on the service and not on the objects. Which is IMHO a good thing, but not for everything and in every layer of your application. What Microsoft now tries to do is: everything is a service. (Literarly that was what they screamed from the top of their lungs at TechEd Europe 2004). With SOA, you need a flexible, generic container in which you can drop any kind of data which is transported from and to a service. A dataset/datatable is suitable for that. No way to store any rule in there, but that's not important, you have a service for that (according to MS). Pretty weird way of thinking as the world is not that black/white, people should be more pragmatic. Only pragmatic solutions will work, as each situation asks for a tailored solution to that situation.

So from that POV, it's understandable they don't go the OO route for data-access, at least not in the higher layers of the application, which is where databinding and design time stuff comes into play. INSIDE a service, you can of course use an O/R mapper or what have you.

My feeling is that MS opts for SOA because Java is very Fowler-domain modelish. Just a hunch, but it's the only explanation I can give.

As long as I can remember, Microsoft has made mistakes in their IDE's when it comes to data-access. In crucial area's they do things wrong so it will turn away people who don't want to drag a server icon on a form, because they don't do demo work but real applications. VS.NET 2005 is a good step in the right direction, but from MS there is no OO answer to the data-access question, not in the IDE and not in the API, except for 2 small (but great) objects/interfaces which allow 3rd party developers to make sure their OO answer to data-access will work in the designer. I don't see any trouble on the horizon at all: more and more people are looking for a tool which can solve the data-access problem, and more and more people will be convinced O/R mapping is a way to deal with it.

And, in all of this, I'm not saying that it should happen or that it should happen this way. But, I am saying that it will happen this way (much arrogance here notwithstanding . The abstration of the data source has to happen, and it will happen, eventually. And those still in the game with all of the experience will reap the benefits, albeit in 3-5 years or more.

Yeah, it's a move from set-based thinking (ADO recordset objects) to object based thinking (collection of customer objects). That's a big move. Most developers moving to .NET are not OO trained, they use VB6 or ASP.

All this to say that it's my opinion that marketing to the so-called lower tier of programmers is wasted effort. They already have what they need in Visual Studio. Work to educate and attract the developers out there who recognize the problem - that's still a big market! - and focus the tool on those who can take advantage of it - at least until someone with the resources and the tolerance to risk (i.e., Microsoft) moves the industry to the next stage and brings the technology to the mainstream.

I think you're right. And if they don't have it in vs.net, they use codesmith or another freebee code generator which cranks out 10,000 procedures and classes. It's weird though, because it shouldn't matter what they use, as long as it saves them time. But O/R mapping contains a lot of new things to cope with: no procedures, objects and no sets... and last but not least the technique itself 'O/R mapping'... it's too academic:

Dev: "I have a problem: data-access" O/R mapper vendor: "Use O/R mapping" Dev: "What's O/R mapping?" O/R mapper vendor: <long academic explanation deleted> Dev: "whoa, hard to grasp, but how does it solve my data-access problem?" O/R mapper vendor: ermm... well...

that's also why I think O/R mapping is great but it's not a 'solution'. It's a technique used IN a solution. People don't use an O/R mapper because of O/R mapping, but because it solves the problem in a way they like it to be solved. The hard part for the vendors is then: how to convince the developer that the tool sold is providing the right solution. My feeling is then that by telling you're selling an O/R mapper, is not the way to go. True, you get the few O/R mapper loving customers, but once all of them are licensed customers, what then?

That's also why I think some O/R mapper vendors are doing it wrong and lose sales: they present themselves as pure O/R mapper vendors. Most developers don't even know what O/R mapping is or how it can solve their problems. Irony is that Olero had the most perfect slogan for ORM.NET: "Data-access made easy". Just perfect. I find it odd that they didn't get more sales though with a slogan like that

jeffreygg wrote:

I know that some tool companies implement some form of escrow to deal with this worry...

Yes, here in the Netherlands you drop your goods at a notary. It's just not very practical as code changes and updating that at the notary is pretty cumbersome.

jeffreygg wrote:

I know that some tool companies implement some form of escrow to deal with this worry...

Yep, all our products here are escrowed, it's a real pain though. The product i've been working on for the past 8 months is coming up to release and i'll will shortly be making a start on the escrow documentation

Wayne, if your customers have any concerns, you can also send them over to me, I'll be happy to answer them.

I think LLBLGen in our project is save at the momment - we are to far down the line to turn back now - especially with deadlines around the corner - we are to dependant on it. And Solution Design seems the best option.

Ps - not my customers - only work here

Otis wrote:

MS is not going anywhere with object oriented data-access though. They're completely conviced set-based data-access is the way to go. I never understood this, but apparently there are some closed minds on the buttons over there...

One of the biggest motivations they have is SOA. This is probably a bit of a theoretical discussion, and I'm not a Fowler fan per se, but SOA is in theory and on a very high level not compatible with pure, OO oriented domain model. With SOA, you orient on the service and not on the objects. Which is IMHO a good thing, but not for everything and in every layer of your application. What Microsoft now tries to do is: everything is a service. (Literarly that was what they screamed from the top of their lungs at TechEd Europe 2004). With SOA, you need a flexible, generic container in which you can drop any kind of data which is transported from and to a service. A dataset/datatable is suitable for that. No way to store any rule in there, but that's not important, you have a service for that (according to MS). Pretty weird way of thinking as the world is not that black/white, people should be more pragmatic. Only pragmatic solutions will work, as each situation asks for a tailored solution to that situation.

You know I never understood this either. They've got some smart people over there. I understand the impact Indigo and SOA must be having in how MS thinks about communication, but honestly! SOA and OO aren't mutually exclusive. Sure they're mutually exclusive if used in the same space, but if you're using an SOA-based design between your classes methinks you're doing something wrong! OO-based designs are the building blocks for a solid SOA architecture. We need OO, and I'm surprised MS isn't applying that truth to data access.

So from that POV, it's understandable they don't go the OO route for data-access, at least not in the higher layers of the application, which is where databinding and design time stuff comes into play. INSIDE a service, you can of course use an O/R mapper or what have you.

EXACTLY.

As long as I can remember, Microsoft has made mistakes in their IDE's when it comes to data-access. In crucial area's they do things wrong so it will turn away people who don't want to drag a server icon on a form, because they don't do demo work but real applications. VS.NET 2005 is a good step in the right direction, but from MS there is no OO answer to the data-access question, not in the IDE and not in the API, except for 2 small (but great) objects/interfaces which allow 3rd party developers to make sure their OO answer to data-access will work in the designer.

Well THAT's good

that's also why I think O/R mapping is great but it's not a 'solution'. It's a technique used IN a solution. People don't use an O/R mapper because of O/R mapping, but because it solves the problem in a way they like it to be solved. The hard part for the vendors is then: how to convince the developer that the tool sold is providing the right solution. My feeling is then that by telling you're selling an O/R mapper, is not the way to go. True, you get the few O/R mapper loving customers, but once all of them are licensed customers, what then?

I've gotta remember that. It's so easy to focus on the solution instead of the problem. Gets us in trouble, sometimes...

That's also why I think some O/R mapper vendors are doing it wrong and lose sales: they present themselves as pure O/R mapper vendors. Most developers don't even know what O/R mapping is or how it can solve their problems. Irony is that Olero had the most perfect slogan for ORM.NET: "Data-access made easy". Just perfect. I find it odd that they didn't get more sales though with a slogan like that

I noticed your slogan is "the next generation O/R Mapper". Considering a change?

Jeff...

jeffreygg wrote:

Otis wrote:

MS is not going anywhere with object oriented data-access though. They're completely conviced set-based data-access is the way to go. I never understood this, but apparently there are some closed minds on the buttons over there...

One of the biggest motivations they have is SOA. This is probably a bit of a theoretical discussion, and I'm not a Fowler fan per se, but SOA is in theory and on a very high level not compatible with pure, OO oriented domain model. With SOA, you orient on the service and not on the objects. Which is IMHO a good thing, but not for everything and in every layer of your application. What Microsoft now tries to do is: everything is a service. (Literarly that was what they screamed from the top of their lungs at TechEd Europe 2004). With SOA, you need a flexible, generic container in which you can drop any kind of data which is transported from and to a service. A dataset/datatable is suitable for that. No way to store any rule in there, but that's not important, you have a service for that (according to MS). Pretty weird way of thinking as the world is not that black/white, people should be more pragmatic. Only pragmatic solutions will work, as each situation asks for a tailored solution to that situation.

You know I never understood this either. They've got some smart people over there. I understand the impact Indigo and SOA must be having in how MS thinks about communication, but honestly! SOA and OO aren't mutually exclusive. Sure they're mutually exclusive if used in the same space, but if you're using an SOA-based design between your classes methinks you're doing something wrong! OO-based designs are the building blocks for a solid SOA architecture. We need OO, and I'm surprised MS isn't applying that truth to data access.

Yeah, but nothing is certain of course. This was posted in the private whidbey newsgroup this morning as an answer to a guy who is still waiting for objectspaces (don't these people have things to get done?)

Thank you for your interest in ObjectSpaces. We appreciate and understand your concerns. At present we are evaluating various options for meeting the object-relational mapping needs and will incorporate your feedback in our evaluation.

Thanks. (name) (ObjectSpaces/WinFS API Program Manager)

I have no clue what they're up to, but they're up to something. The problem for them is, that whatever they release as temporarily solution, winfs will be different and people will have to adopt that.

That's also why I think some O/R mapper vendors are doing it wrong and lose sales: they present themselves as pure O/R mapper vendors. Most developers don't even know what O/R mapping is or how it can solve their problems. Irony is that Olero had the most perfect slogan for ORM.NET: "Data-access made easy". Just perfect. I find it odd that they didn't get more sales though with a slogan like that

I noticed your slogan is "the next generation O/R Mapper". Considering a change?

hehe nooo not at all, as I still see our pragmatic approach as 'next-gen' . Also it's pretty weak to adopt a competitors slogan I think. For example I consider the name 'Pragmatier' also perfect: pragmatic n-tier development. Matches perfectly with what the average MS developer knows best. It's just that 'LLBLGen' is a widely known brand already, so it would be a very weird move to abandone that

I am shocked. I am in shock because I just checked back in on this thread I started and see there are 39 replies, whereas my post about the funny variable name has received no replies.

I'm also in shock because I actually considered paying $1250 for Pragmatier and now it's free. Is it too late to get my money back for your product, Frans? Ha ha, just kidding.

At the same time, I am gratified to learn that I am in the minority amongst developers and work in the top tier of development shops. Exciting!

Where has Aglaia been hiding all this time? Is that her real photo? To quote an old Clint Eastwood movie, "I gots to know".

On a serious note, I can easily see MS dropping SOA in favor of ORM one day. When will that day come? When everyone has bought into .NET/SOA. Lots of MS technologies come about because everyone has bought the old stuff and they have to come up with a better way of doing things to generate a new sales cycle. They already need something to replace Office. Who the hell is going to upgrade to Word three versions from now? I haven't even upgraded to the current one.

Who has Aglaia's phone number?

JimFoye wrote:

I am shocked. I am in shock because I just checked back in on this thread I started and see there are 39 replies, whereas my post about the funny variable name has received no replies.

that other post was quite funny indeed You should subscribe to the dailyWTF (www.thedailywtf.com )

I'm also in shock because I actually considered paying $1250 for Pragmatier and now it's free. Is it too late to get my money back for your product, Frans? Ha ha, just kidding.

hehe .

Where has Aglaia been hiding all this time? Is that her real photo? To quote an old Clint Eastwood movie, "I gots to know".

That's her real photo

On a serious note, I can easily see MS dropping SOA in favor of ORM one day. When will that day come? When everyone has bought into .NET/SOA. Lots of MS technologies come about because everyone has bought the old stuff and they have to come up with a better way of doing things to generate a new sales cycle. They already need something to replace Office. Who the hell is going to upgrade to Word three versions from now? I haven't even upgraded to the current one.

Can be indeed. However I think it is hard for them to drop SOA completely, simply because systems like Biztalk server can easily connect with services, which means more money (Biztalk server is erm... expensive )

Who has Aglaia's phone number?

I do. No I won't give it to you

That's her real photo

Best looking programmer i've ever seen.

wayne wrote:

That's her real photo

Best looking programmer i've ever seen.

she's not doing C# development, but more functional analysis.

Best looking functional analysis person that i've ever seen.

Is she working for you Otis?

I see her occupation is LLBLGen Helpdesk and i also noticed that her image is stored at the same place as your website.

Reminder to self - Ok wayne, stop now - you are a married man.

Something to chew on for VS 2005: The Custom Build Provider. In the example of this article, the author describes how to use a CBP to auto-generate an (or update an existing) DAL at compile-time.

That kind of tight integration with VS would be great!

http://www.theserverside.net/blogs/showblog.tss?id=BuildProviders

swallace wrote:

Something to chew on for VS 2005: The Custom Build Provider. In the example of this article, the author describes how to use a CBP to auto-generate an (or update an existing) DAL at compile-time.

That kind of tight integration with VS would be great!

http://www.theserverside.net/blogs/showblog.tss?id=BuildProviders

Thanks for the link! Will read

I don't get it. Why is the author of the article so thrilled about this feature? Deployment is about installing a tested version of the code, not something that has to be generated on the site. And why would you want to generate the code this way? Isn't the dal something not really connected to the gui (asp.net app) ? . Perhaps it's me, but it looks like a feature cooked up for demoing but not real life applications.

I think you're correct, that this feature doesn't present itself clearly, and the author does little to help.

I think the idea here is to add features that you would ordinarily add in an NMAKE batch. Sort of like the command line feature you just created.

I think that a feature that, in a full re-build of the solution regenerated the code, and in a simple build confirmed that no changes between the SQL and generated code existed, might be helpful to 'twenty-buck' people.

Anyway, it's clear that, by the addition of this feature, Microsoft wishes to create a tighter integration for third-party tools not just for the interface but with the compiler build tools themselves.

Hard to say where it's going.

Yeah I agree with that.