Hi guys,

I'm desperately looking for arguments to convince my manager in upgrading to the latest version of LLBL. Unfortunately we are still working with version 2.0. My boss is not very eager to start an upgrade path. His main reasons are: - Code won't compile anymore. It is going to take time and money to fix this (duh) - Uncertain if the application is going to behave in the same way as it does now. So we have to do extensive testing which is costing time and money.

My main reasons to start an upgrade path are: - New language features. - Speed - Lower memory footprint - Increased stability

Can anybody give my some numbers in speed comparison between version 2.0 and 3.5 (4.0), hard numbers or other arguments to convince my boss to start an upgrade path.

Thanks in advance.

For us Legacy support is the main reason to upgrade Model only relationships Stored procedures support Table valued functions ?... and the feeling of working with a bug free core app.

How many salary hours is worth a license? Do you save them avoiding just a single workaround? PS. Im the IT manager, 80 people. Now we use Office 2010, but last year version was 2002 (XP), just because there was no business case to change. We, at the financial sector still use fixed width text files instead of SOA. IMMO this is not the same.

Maybe the v4 (beta) feature's list would help: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=21739

CowHills wrote:

Hi guys, I'm desperately looking for arguments to convince my manager in upgrading to the latest version of LLBL. Unfortunately we are still working with version 2.0. My boss is not very eager to start an upgrade path. His main reasons are: - Code won't compile anymore. It is going to take time and money to fix this (duh) - Uncertain if the application is going to behave in the same way as it does now. So we have to do extensive testing which is costing time and money.

v2.0 is pretty old (it's from 2007). I understand the 'if it ain't broke, don't fix it' mantra, it's however also a technical debt, in case you want to include modern technology like linq-aware services using e.g. WebAPI with OData, or utilize other technologies we support today but not in 2.0.

We almost never change functionality aspects of our code, as that would be too much of a burden for users who migrate code. There have been breaking changes since 2.0, which we all documented in the runtime documentation: http://www.llblgen.com/documentation/3.5/LLBLGen%20Pro%20RTF/hh_goto.htm#migratingcode.htm

(you should start with breaking changes v2.5, as you're already on v2.0). Most changes won't affect you, some might.

Your manager has the responsibility for the progress of your project, so if he won't take the risk of upgrading because what's currently in use 'works', that's his good right of course. The main reasons for upgrading should be that you want to use features you currently don't have or need features you don't have today, or run into problems which we addressed later on.

My main reasons to start an upgrade path are: - New language features. - Speed - Lower memory footprint - Increased stability

Can anybody give my some numbers in speed comparison between version 2.0 and 3.5 (4.0), hard numbers or other arguments to convince my boss to start an upgrade path. Thanks in advance.

we always optimize the runtime with each version. In v2.6 for example we lowered the memory footprint a lot (see; http://www.llblgen.com/documentation/2.6/hh_goto.htm#whatsnew.htm), and in v2.5 we introduced fast serialization (binary) for adapter, which is very very fast compared to normal binary formatter serialization (300% or more). While you might not use remoting, you might use datasource controls in webforms. If you do, (and adapter), you will use serialization, so fast serialization will speed things up a lot.

In 3.1 we optimized things further: http://www.llblgen.com/documentation/3.1/LLBLGen%20Pro%20RTF/hh_goto.htm#whatsnew.htm

and the upcoming v4.0 has a very fast entity fetch pipeline: http://pastebin.com/AdsKitr3

But it comes down to this: - what are the future plans of your current code base. If you want to move the code base to a new .NET version, want to use Linq and the like, you have to move to at least v2.6 (which is free for you). If there are no plans but it's also not going to be killed as e.g. the code base is essential for the company, make sure your manager understands this: it's not the current version, which works fine, it's the changes which have to be made e.g. next year which are important: will they be possible on the current code base, if e.g. the new features require e.g. IQueryable<T>? - try a test migration of your code base on a copy of your code: with the trial of v3.5 and a separate v2.6 install (to migrate your lgp file to v3's format) you can generate code with v3.5 on top of the copy of your code base. This will show the amount of breaking changes. You can then realistically see what's the work to be done.

We almost never make functionality changes, i.e. when a method does X in v2.x, it will do X in v4. The only thing we did add which might affect you is auto-validation. But you can switch it off if you don't want it (e.g. your code will fail if you leave it on). Autovalidation is logic which rejects a value for a field if it doesn't match the format. E.g. you set a decimal (4, 2) to the value 10000.3422

So although you want to focus on speed, memory footprint and the like, and we got you covered there, it's more important to focus on what do you want to do with the code base, which functionality will be added in the future which likely relies on functionality in e.g. .NET which you currently can't use because you're stuck in 2007. Being stuck in 2007 isn't bad, it still works and will likely to work for the next 10 years. But being able to move on to today is a valuable asset to have if the code base has to stay for a while and has to be adjusted in the future.

To note: if you upgrade to v3.5 before v4 RTMs, you get v4 for free.