Your thoughts on whether a new project should based on Adapter or SelfServicing in preparation for .NET 2.0? Which will allow me to take better advantage of the features in the 2.0 framework? I realize you are planning on moving both to the new framework - I'm just looking for opinions before I make my decision. A distributed App may be in the works but I don't want that to force your opinion. Your thoughts on the future are greatly appreciated - Adapter or SelfServicing?

Chris

HaulMark wrote:

Your thoughts on whether a new project should based on Adapter or SelfServicing in preparation for .NET 2.0? Which will allow me to take better advantage of the features in the 2.0 framework? I realize you are planning on moving both to the new framework - I'm just looking for opinions before I make my decision. A distributed App may be in the works but I don't want that to force your opinion. Your thoughts on the future are greatly appreciated - Adapter or SelfServicing? Chris

I think you should focus on what you need now. .NET 2.0 is far away, at least not before september 2005.

It doesn't matter what you pick now for the .NET 2.0 version as the .NET 2.0 version will be a rewritten API. It will have the same characteristics as the current version, as in: there will be a selfservicing and an adapter version, but I'm not going to bring a lot of the legacy limits of the current codebase to the .NET 2.0 version if I can solve these problems with .NET 2.0 features like generics and partial classes.

The .NET 1.1 version will be supported in LLBLGen Pro v2.0, as it will be the codebase for the current version which is kept in the support cycle. This is done because not everyone switches over to .NET 2.0 when it comes out, far from it. We still support .NET 1.0 at the moment and there are still people using that today. So don't be afraid you have to pick something which will be cut off in the near future, because that's not the case.

The .NET 2.0 version of LLBLGen Pro will use the same designer (with perhaps some upgrades) and the same code generator (with just .lpt templates) and a complete new API, templates and runtimes. The core will be adapter, and selfservicing will be an extension of Adapter. This will make life easier, as the codebase will then share more code. This however means that both will be fully supported and will have the same functionality: if you like selfservicing more, you will be able to write code in the selfservicing style. For adapter this is also the case.

But please, base your decisions today on the technology of today. Considering your possible requirement of a distributed exponent in your project, I'd recommend adapter, as you will then avoid the problems you might face when you use selfservicing now.

jsut outta curiosity, but will LLBLGen 2.0 be a free upgrade?

Answer wrote:

jsut outta curiosity, but will LLBLGen 2.0 be a free upgrade?

No, it will a new product, but current customers get a discount on the price of course (new as in: not a different product, but the next version)

Otis wrote:

I think you should focus on what you need now. .NET 2.0 is far away, at least not before september 2005.

Over here, it's not far away, it's on top of us. Some of us don't have the luxury of waiting until Fall to figure these things out.

grant wrote:

Otis wrote:

I think you should focus on what you need now. .NET 2.0 is far away, at least not before september 2005.

Over here, it's not far away, it's on top of us. Some of us don't have the luxury of waiting until Fall to figure these things out.

I'm not sure if I understand you correctly. .NET 2.0 beta 1 can't be used for commercial apps, beta 2 will, which will not arrive before april. The past has learned that developing software using Microsoft beta's is a real pain at best.

So I really don't understand the rush towards .NET 2.0 usage. Sure, it solves a lot of problems, but it's IMHO not necessary for writing applications today. But then again, if you have a management which forces you to use bleeding edge technology, just to be able to say you do so, then you're out of options of course

No, it will a new product, but current customers get a discount on the price of course (new as in: not a different product, but the next version)

You might want to considering changing (rewording) whats on your website

Free updates and upgrades Buying LLBLGen Pro gives you the right to free updates and upgrades

becuase i was under the impression that its basically a one time purchase. Maybe i was nieve or just dont understand english Becuase according to the wording above, the next "version" should be a free upgrade.

Next, let me say that i am NOT complaining. You deserve the right to make money and quite frankly i have never seen anyone add so many features and not call it a "new product" and i thank you for that I just felt i should bring it to your attention that it is somewhat misleading.

I used to be in retail, and let me tell you, mislead customers were a royal pain in the arse!

Answer wrote:

No, it will a new product, but current customers get a discount on the price of course (new as in: not a different product, but the next version)

You might want to considering changing (rewording) whats on your website

Free updates and upgrades Buying LLBLGen Pro gives you the right to free updates and upgrades

becuase i was under the impression that its basically a one time purchase. Maybe i was nieve or just dont understand english Becuase according to the wording above, the next "version" should be a free upgrade.

Good catch! We recently decided what to do with v2.0 so it's pretty fresh and we didn't update the website with marketing goo. It's updated now

Next, let me say that i am NOT complaining. You deserve the right to make money and quite frankly i have never seen anyone add so many features and not call it a "new product" and i thank you for that I just felt i should bring it to your attention that it is somewhat misleading.

Well personally I hate the model component vendors like Infragistics use: 4 times a year a new version and if you don't buy a subscription you won't get updates, even if the code is buggy because of a design flaw so you are entitled to a bugfix which means a new version. And it's a real maintenance problem if you have to maintain a lot of versions, keep track of which customer is on which version etc. etc. ... I find it often look like some sort of scam. "Buy our product!" "ok" "oh, and now you have it, you'll need to pay a lot more to get benefits you even get with every 2nd hand car".

I like the model we have now: it's almost open source development, customers feel very attached to the product because the lines between developer and customer are very short. To illustrate the contrast: I wanted to report a bug in .NET 1.1 SP1 to Microsoft. I have to PAY to get access to the online support team. To report a freaking bug!

I used to be in retail, and let me tell you, mislead customers were a royal pain in the arse!

I can imagine

So, this next version, is it going to have a bit better support for Webservices?

Also, when is compact framework support going to happen for the current version?

Answer wrote:

So, this next version, is it going to have a bit better support for Webservices?

Microsoft made IXmlSerializable public in .NET 2.0 so yes.

Also, when is compact framework support going to happen for the current version?

That's planned for the upgrade for april/may

Otis wrote:

I'm not sure if I understand you correctly. .NET 2.0 beta 1 can't be used for commercial apps, beta 2 will, which will not arrive before april. The past has learned that developing software using Microsoft beta's is a real pain at best.

Didn't say we were building an application that will be deployed in production app prior to B2, April. That said, we didn't have major headaches deploying prior to RTM under Go Live for 1.0. When it's stable, it's stable. (Which is a wholly different question for 2.0 right now, and not really the heart of the matter.)

Otis wrote:

So I really don't understand the rush towards .NET 2.0 usage.

You say "rush". I say "tactically plan aggressively with a horizon further than a couple months". I would be happier knowing where things were going and when for all the technologies we leverage.

We have our mandates, and I don't have substantive problems with them, I understand the motives and drivers behind them. As a result, I can tell you, my planning horizon considers 2.0 relevant and there are concrete reasons for that.

Otis wrote:

Sure, it solves a lot of problems, but it's IMHO not necessary for writing applications today.

Necessary is a funny word, I'm sure there are a few COM, COBOL or Assembler fans out there that could make similar args. Necessary isn't really the point--if someone else's calculus nets them the conclusion that they're going to be starting a 2.0 app this summer, then I'm really not personally omniscient enough to tell them that's a good, bad or middling idea. (Moreover, it's not really even my place to be telling them these kinds of things.)

Otis wrote:

But then again, if you have a management which forces you to use bleeding edge technology, just to be able to say you do so, then you're out of options of course

Actually, it's just an inevitability. So if, say, I'm looking out into the future, I'd rather plan for it accordingly, rather than just ignore it until RTM.

I'd love to see the roadmap and dates for LLBLGen milestones corresponding to 2.0, that's information that I'd find interesting and useful. I'd love to see the things I can expect to change dramatically with LLBLGen, so things I build today will be easy to port forward in a few months--I'd love to have a good idea of what these changes are going to be as soon as I can, so I can plan my own internal migration from LLBLGen version to version.

Call me crazy Nonetheless, two other third-party .NET tool/component vendors I license from are actively working on Whidbey-compatible betas of their products. The fact that they're working on that openly while still maintaining their 1.0/1.1 products seems like a good thing, not a bad one to me.

grant wrote:

Otis wrote:

So I really don't understand the rush towards .NET 2.0 usage.

You say "rush". I say "tactically plan aggressively with a horizon further than a couple months". I would be happier knowing where things were going and when for all the technologies we leverage.

I understand. There are always early adopters, laggers and mainstream buyers.

We have our mandates, and I don't have substantive problems with them, I understand the motives and drivers behind them. As a result, I can tell you, my planning horizon considers 2.0 relevant and there are concrete reasons for that.

Oh, that's also true here, don't get me wrong. I'd love to drop .NET 1.x for 2.0. The thing is though that a lot of developers are currently working on .NET 1.x stuff and can't switch over to 2.0 mid-project. Furthermore, early-adopters are not the main group of users. This means that having a 2.0 product ready by teh time .NET 2.0 hits RC state in september is perhaps good for marketing but it won't bring a lot of sales to the table: .NET 2.0 will not be used on a wide scale before 2006. That's why .NET 1.x is relevant and will stay relevant for some time. There are even people developing on .NET 1.0 today.

Otis wrote:

Sure, it solves a lot of problems, but it's IMHO not necessary for writing applications today.

Necessary is a funny word, I'm sure there are a few COM, COBOL or Assembler fans out there that could make similar args. Necessary isn't really the point--if someone else's calculus nets them the conclusion that they're going to be starting a 2.0 app this summer, then I'm really not personally omniscient enough to tell them that's a good, bad or middling idea. (Moreover, it's not really even my place to be telling them these kinds of things.)

I was more talking about "Do I need .NET 2.0 to write an app?". The answer can only be: "No". It's great to have .NET 2.0, but you can do without it. My point with this is: if you have to start an app today, use tech that works TODAY, not beta stuff that will work 'on a day in the future'.

Sure, if the go-live license is there, you have another option, but trust me, beta2 is not release quality material. You will run into a lot of problems. It's of course up to you if you want to deal with that .

I don't really see what assembler-fetisjists have to do with this, as I don't see why .NET 1.x is to .NET 2.0 as assembler is to .NET 1.x. Furthermore, and this might come as a shock: the majority of developers on windows are still writing COM/VB6/C++/win32 stuff. Not .NET.

For me it's important that developers who want to use LLBLGen Pro can do so. This means that if .NET 2.0 is there, .NET 2.0 support has to be available. However if they want to use .NET 1.1, this also has to be possible. I do find it a bit useless to support betas though, especially microsoft's betas. The main part is that these are a moving target in a lot of cases and aren't qualified as 'beta' for nothing.

Otis wrote:

But then again, if you have a management which forces you to use bleeding edge technology, just to be able to say you do so, then you're out of options of course

Actually, it's just an inevitability. So if, say, I'm looking out into the future, I'd rather plan for it accordingly, rather than just ignore it until RTM.

I understand that, and I hope I can help you with that .

I'd love to see the roadmap and dates for LLBLGen milestones corresponding to 2.0, that's information that I'd find interesting and useful. I'd love to see the things I can expect to change dramatically with LLBLGen, so things I build today will be easy to port forward in a few months--I'd love to have a good idea of what these changes are going to be as soon as I can, so I can plan my own internal migration from LLBLGen version to version.

Well, the 'roadmap' is as follows: - designer/codegenerator/runtimelib/driver upgrade (now in development), which should go beta in february - designer/codegenerator/runtimelib/driver upgrade (ce support, inheritance etc. )which should go beta in may - drivers for sybase and perhaps another database in may/june - HQL / OQL query language parser in june - development for .NET 2.0 starts in may-june: this will be LLBLGen Pro v2.0. This has to be finished before .NET 2.0 goes RTM.

We will keep on supporting the 1.0 code with bugfixes but no new code. v2.0 will have the same designer (with some extra features perhaps) and a new runtime lib / templateset. The runtime lib / template set will be build with generics and will have adapter as core and selfservicing as adapter-wrapper. V2.0 of LLBLGen Pro will have support for .NET 1.x as well.

The 2.0 runtimelib/templates will be different from the 1.0 versions, because they're build with generics and partial classes and other .NET 2.0 goodies. There will be a conversion necessary, how big that will be is uncertain at this moment.

.NET 2.0 will go RC in mid-september, which means an RTM in november at the earliest. I hope to be done with the 2.0 code by then.

Call me crazy Nonetheless, two other third-party .NET tool/component vendors I license from are actively working on Whidbey-compatible betas of their products. The fact that they're working on that openly while still maintaining their 1.0/1.1 products seems like a good thing, not a bad one to me.

I really wonder how they develop the 2.0 code as VS.NET 2005 is not that erm... stable, and you can't do a lot with it, looking at the license.

Don't be afraid we'll not support .NET 2.0, we will support .NET 2.0. However moving the codebase to 2.0 is easier if the vast majority of features I want to have in 2.0 is already implemented, which will be around june.

Otis wrote:

Oh, that's also true here, don't get me wrong. I'd love to drop .NET 1.x for 2.0. The thing is though that a lot of developers are currently working on .NET 1.x stuff and can't switch over to 2.0 mid-project. Furthermore, early-adopters are not the main group of users. This means that having a 2.0 product ready by teh time .NET 2.0 hits RC state in september is perhaps good for marketing but it won't bring a lot of sales to the table: .NET 2.0 will not be used on a wide scale before 2006. That's why .NET 1.x is relevant and will stay relevant for some time. There are even people developing on .NET 1.0 today.

It may help to understand that we're supporting 1.0 apps and developing on 1.1 and will be doing both into the foreseeable future. They're not mutually exclusive to our planning for the next wave.

The sales aspect is wholly relevant, I can appreciate that.

Regarding the old technologies, my point was only that there are some COBOL stallwarts out there (et al) who believe nothing after COBOL, CICS, etc. is really necessary.

Otis wrote:

Well, the 'roadmap' is as follows: - designer/codegenerator/runtimelib/driver upgrade (now in development), which should go beta in february - designer/codegenerator/runtimelib/driver upgrade (ce support, inheritance etc. )which should go beta in may - drivers for sybase and perhaps another database in may/june - HQL / OQL query language parser in june - development for .NET 2.0 starts in may-june: this will be LLBLGen Pro v2.0. This has to be finished before .NET 2.0 goes RTM.

We will keep on supporting the 1.0 code with bugfixes but no new code. v2.0 will have the same designer (with some extra features perhaps) and a new runtime lib / templateset. The runtime lib / template set will be build with generics and will have adapter as core and selfservicing as adapter-wrapper. V2.0 of LLBLGen Pro will have support for .NET 1.x as well.

The 2.0 runtimelib/templates will be different from the 1.0 versions, because they're build with generics and partial classes and other .NET 2.0 goodies. There will be a conversion necessary, how big that will be is uncertain at this moment.

.NET 2.0 will go RC in mid-september, which means an RTM in november at the earliest. I hope to be done with the 2.0 code by then.

That's exactly the type of information that helps me (and I appreciate you taking the time to talk to the people running around with scissors).

The new 2.0 runtime/templates are the big interest, looking forward to seeing those down the road... back to writing some turbo pascal

grant wrote:

Otis wrote:

(roadmap)

That's exactly the type of information that helps me (and I appreciate you taking the time to talk to the people running around with scissors).

No problem, in your shoes I'd want to know the same things

Frans, are there going to be many issues compiling LLBLGen v1 under .NET 2.0. Have you tried yet?

Marcus

Marcus wrote:

Frans, are there going to be many issues compiling LLBLGen v1 under .NET 2.0. Have you tried yet?

Marcus

I have tried it once, but that was an early build of .NET 2.0. Normally it should work for 100% with here and there some quirck which might have changed (like the migration from 1.0 to 1.1). .NET 2.0 can also run .NET 1.1 compiled assemblies without problems, so they say.