As LLBLGen Pro 3.0 will arrive in May, not in April, we decided to add .NET 4.0 /VS.NET 2010 templates to LLBLGen Pro 2.6, so the happy few of you who are allowed to work with the latest and greatest of Microsoft's dev tools can now do that with v2.6. The new build uploaded this morning contains the new templates.

Of course, you're encouraged to try out the beta of v3.0 which already supported .NET 4.0 / VS.NET 2010

Great!

Just yesterday I was thinking about converting my project to .NET 4.0 & VS 2010 until I realized there were no templates available.

Good to know LLBLGen Pro staff keeps things up-to-date.

Edit: Could it be that the Linq Template Binding hasn't been updated yet?

I manually added a .NET 4 platform tag in the SD.TemplateBindings.Linq.templatebindings file. I'm not sure this is the proper way to do it, but this way it'll generate the LinqMetaData.cs file.

Thanks for the update.

Thanks for updating version 2.6 with the .NET 4.0 Templates.

T0M wrote:

Great!

Just yesterday I was thinking about converting my project to .NET 4.0 & VS 2010 until I realized there were no templates available.

Good to know LLBLGen Pro staff keeps things up-to-date.

Edit: Could it be that the Linq Template Binding hasn't been updated yet?

I manually added a .NET 4 platform tag in the SD.TemplateBindings.Linq.templatebindings file. I'm not sure this is the proper way to do it, but this way it'll generate the LinqMetaData.cs file.

oops! I'll correct that right away!

Indeed by adding the 4.0 platform to the list should fix it.

(edit) uploaded again. Sorry for this inconvenience! If you already had downloaded the bits, just open the linq template bindings file in notepad and add a <platform name=".NET 4.0" /> line below the 3.5 platform specification.

Hey Otis.

Will there be new Runtime Libraries for .NET 4.0. I only see the ones for .NET 1.x, 2.0, and 3.5?

These of the runtimes I am using SD.LLGLGen.Pro.DQE.Access.NET20 SD.LLGLGen.Pro.LinqSupportClasses.NET35 SD.LLGLGen.Pro.ORMSupportClasses.NET20

I guess I was expecting the ones for .NET 4.0 to have these names SD.LLGLGen.Pro.DQE.Access.NET40 SD.LLGLGen.Pro.LinqSupportClasses.NET40 SD.LLGLGen.Pro.ORMSupportClasses.NET40

I know you added the 4.0 Templates, but I guess I expected it to use 4.0 Runtimes.

Thanks,

Charlie J.

cjbiggs wrote:

Hey Otis.

Will there be new Runtime Libraries for .NET 4.0. I only see the ones for .NET 1.x, 2.0, and 3.5?

These of the runtimes I am using SD.LLGLGen.Pro.DQE.Access.NET20 SD.LLGLGen.Pro.LinqSupportClasses.NET35 SD.LLGLGen.Pro.ORMSupportClasses.NET20

I guess I was expecting the ones for .NET 4.0 to have these names SD.LLGLGen.Pro.DQE.Access.NET40 SD.LLGLGen.Pro.LinqSupportClasses.NET40 SD.LLGLGen.Pro.ORMSupportClasses.NET40

I know you added the 4.0 Templates, but I guess I expected it to use 4.0 Runtimes.

Thanks,

Charlie J.

No, there won't be any .net 4.0 specific builds, because no code has changed (as in: we don't use any 4.0 specific code)

Thanks Otis. I see and I understand. That is what I figured.

Will this be the case for LLBLGEN 3.0 as well for the Runtime Libraries as well?

Thanks,

Charlie J.

cjbiggs wrote:

Will this be the case for LLBLGEN 3.0 as well for the Runtime Libraries as well?

Thanks,

Charlie J.

Yes, as v3.0 focuses mainly on the designer (we always do that: update designer, next verion update runtime etc.) and not the runtime (although we made some changes and optimized a lot of code in the DQEs for example). We don't use .NET 4.0 specific code yet. The main reason we want to keep 1 code base is to have less code to maintain. v2.6 has also 2 code bases (.net 1.x and .net 2.0+) and it's not easy to maintain it. In 3.0 we drop .net 1.x, but want to stay on .net 2.0 specific code for a while, as there's no real necessity for using .net 4.0 specific code in the runtime at this point.

Hello, I installed the new version 2.6 with support for vs2010. When I use the designer to create the new DAL, everything works fine. When I use CliGenerator to generate, it produces a porjectfile that still requires conversion in visual studio 2010. Any ideas on that? I recompiled cligenerator.exe using reference to the updated dlls. Paul

Pablo wrote:

Hello, I installed the new version 2.6 with support for vs2010. When I use the designer to create the new DAL, everything works fine. When I use CliGenerator to generate, it produces a porjectfile that still requires conversion in visual studio 2010. Any ideas on that? I recompiled cligenerator.exe using reference to the updated dlls. Paul

cligenerator uses the settings inside the project file for .net version etc. So if you have a .lpg file which was used to generate .NET 3.5 code, then use the cligenerator, it won't generate .net 4.0 code for you. You have to first generate code for .net 4.0 (and use the 4.0 preset) in the designer, save the project afterwards, and then use the cligenerator. Did you use that process? Also, if you use the command line parameter format where you specify the preset etc., you have to make sure you use the 2010 preset.

Thanks for your reply. I did not see the 2010 preset, since I kept my target platform 3.5.

The thing is, I don't want to target platform 4.0 (i suppose). My hosting company did not upgrade to 4.0 yet. However, I do want to use VS2010, targeting 3.5.

Does that make sense? Paul

ps. sofar i did not change the commandline of cligenerator.exe ...

I changed the preset on the commandline to 2010. This works. No more conversion required.

Strange enough though ... it also makes VS2010 not notify me of a new version of the dal project available (asking me to reload etc..) I think that's not a problem.

Paul

ps. after using this a couple of times now. It seems to work fine, and the missing Reload dialog actually is a blessing.

Pablo wrote:

I changed the preset on the commandline to 2010. This works. No more conversion required.

Strange enough though ... it also makes VS2010 not notify me of a new version of the dal project available (asking me to reload etc..) I think that's not a problem.

Paul

ps. after using this a couple of times now. It seems to work fine, and the missing Reload dialog actually is a blessing.

The re-load happens if you have the project open in vs.net and it gets overwritten and you have 'CleanUpVsNetProjects' set to true in the project properties inside llblgen pro.

To use vs.net 2010, you have to select .net 4 indeed.

I've been running my app now more than a week using 4.0 framework and working with vs2010. It has been a rough week, with lots of 'new' problems. I have the feeling (dificult to measure) that this setup uses some more memory, since my application pool gets recycled a lot, since working with this version. My hoster provides 200MB internal ram, and when the app actually uses that memory(with some delay) it recycles the pool. Normally this is not a problem, say 2 times a day, but every 5 minutes is really no fun.

So actually I would like to go back to 3.5 ... (not vs2008 though), or ... another option is to move forward, and go to Azure.

I've done some preliminary testing and investigating in Azure ... it seems to support only 3.5.

Either way, I think I need to be able to target .net framework 3.5 using Vs2010.

Any thoughts on this? Paul

Pablo wrote:

I've been running my app now more than a week using 4.0 framework and working with vs2010. It has been a rough week, with lots of 'new' problems. I have the feeling (dificult to measure) that this setup uses some more memory, since my application pool gets recycled a lot, since working with this version. My hoster provides 200MB internal ram, and when the app actually uses that memory(with some delay) it recycles the pool. Normally this is not a problem, say 2 times a day, but every 5 minutes is really no fun.

So actually I would like to go back to 3.5 ... (not vs2008 though), or ... another option is to move forward, and go to Azure.

I've done some preliminary testing and investigating in Azure ... it seems to support only 3.5.

Either way, I think I need to be able to target .net framework 3.5 using Vs2010.

Any thoughts on this? Paul

First, please open a new thread if you run into problems, this is an announcement thread, not a support thread.

Second, locally do memory profiling: run the application you wrote and profile the memory consumed. This might take a while, i.e. you've to do more than clicking a single link. Memory profilers are for example Ants from red gate or dottrace from jetbrains. With the memory profiling you can discover what's been kept in memory. This might be caused by asp.net 4.0 which for example caches way more data now than before.

thanks. I'll open new thread.