I've just migrated my project to v2 and corrected all the compilation error and compiled my program, when I try to run it, it threw the following exception when it create DataAccessAdapter. I don't know what's wrong.

public DataAccessAdapter(string connectionString) : base(PersistenceInfoProviderSingleton.GetInstance())

Exception:
The type initializer for 'Test.DatabaseSpecific.PersistenceInfoProviderSingleton' threw an exception.
at Test.DatabaseSpecific.PersistenceInfoProviderSingleton.GetInstance()
at Test.DatabaseSpecific.DataAccessAdapter..ctor(String connectionString)
at Test.DataAccessAdapter..ctor(String connectionString)

InnerException:
Common Language Runtime detected an invalid program.
at Test.DatabaseSpecific.PersistenceInfoProviderCore.Init()
at Test.DatabaseSpecific.PersistenceInfoProviderCore..ctor()
at Test.DatabaseSpecific.PersistenceInfoProviderSingleton..cctor()

I have no idea what's wrong, as that just calls into the runtime lib which his managed code.

Is this on win2k3 and are there restrictions set or something?...

Could you try on the command line: vsvars32.bat peverify sd.llblgen.pro.ormsupportclasses.net20.dll

?

I get 4 warnings there, but for .NET 2.0 on 32bit it's ok. The warnings are garbage to me, as the compiler compiles without warnings (just warnings about comments).

Also check if you're using the FINAL version of .NET 2.0, and not a CTP or beta.

Otis wrote:

I have no idea what's wrong, as that just calls into the runtime lib which his managed code.

Is this on win2k3 and are there restrictions set or something?...

yes, it is a win2k3, both x86 and x64 I think no restrictions set, i did not set anything before...

Otis wrote:

I have no idea what's wrong, as that just calls into the runtime lib which his managed code.

Is this on win2k3 and are there restrictions set or something?...

Could you try on the command line: vsvars32.bat peverify sd.llblgen.pro.ormsupportclasses.net20.dll

?

I get 4 warnings there, but for .NET 2.0 on 32bit it's ok. The warnings are garbage to me, as the compiler compiles without warnings (just warnings about comments).

Also check if you're using the FINAL version of .NET 2.0, and not a CTP or beta.

I also got 4 warnings both on 32bit and 64bit.

I've changed the compile option from "x86" to "Any CPU", it can run on 64bit windows now, but not 32bit windows.

And it is very slow, at least 20 times slower compared with v1. I place a break point at DataAccessAdapter constructor, it take around 5 seconds to wait to move to the next line of code, I do not know what's doing at PersistenceInfoProviderSingleton.GetInstance(), it take so much time to process everytime I create the DataAccessAdapter.

That's run once, it's a singleton.

I've looked at this KB article: http://support.microsoft.com/kb/312544/en-us

The exception you run into suggest a C# compiler bug. Not what I wanted to hear...

The warnings don't tell me anything though. What's odd also is that I build the runtime libs with the same script as I did in v1, with the same compiler.

Btw, you rebuild the runtime libs yourself, and it didn't work properly? If you rebuild the source with target x64, does it work then? (modify makefile_20 to add the flag /platform:x64 to the csc call)

Otis wrote:

That's run once, it's a singleton.

I've looked at this KB article: http://support.microsoft.com/kb/312544/en-us

The exception you run into suggest a C# compiler bug. Not what I wanted to hear...

The warnings don't tell me anything though. What's odd also is that I build the runtime libs with the same script as I did in v1, with the same compiler.

yes, it's singleton, the delay only occur the first times I create DataAccessAdapter.

I copied my project to a 32bit win2k3 to compile it and test.

I've tried both "Any CPU" and "x86" compile option, both cannot run, and having the same exception.

Only "Any CPU" or "x64" option compiled on 64bit win2k3, and can be run on 64bit windows only now.

I'm confused now. Please help me here, as I don't have 64bit hardware to test it on, and this error is not making me very happy.

The RUNTIME libraries are build with ANYCPU. When a call to the runtime libs is made in YOUR program, it's apparently an illegal program. This exception occurs if the IL is bad according to the JIT.

Here I've never seen this exception, on 32bit hardware. So it works on 32bit hardware, I need your help with the 64bit part.

So, if you compile YOUR program with different flags, that's not going to matter, the 64bit JIT thinks the runtime libraries aren't OK, IL wise.

I had the idea you recompiled the runtime libraries with x64 target, hence my question.

I'll mail you a x64 target build. Please let me know if that one indeed works as expected on 64bit hardware.

i've just tested your x64 dlls. It can run on 64bit windows without the excepton, but it still have a long delay when I create DataAccessAdapter.

It delay around 10 seconds for both original dlls and x64 dlls, I see the task manager, it consume cpu resource 50% continously on my dual core cpu (100% on single core), and it is eating my memory continously too, it used 4xxMB at maximum and drop to 2xxMB when my program is finally started. Compared with v1, it only consume around 70MB at program start. Very strange.

How many entities do you have in your project? It builds a cache for the field infos for all entities and all fields. In v1, this was done every time you created an entity which was slow. In v2, this is done in a cache upfront.

190 at this moment, some entities have over 200 fields.

Barry wrote:

190 at this moment, some entities have over 200 fields.

Very strange. If I create a project on adventureworks, with 90 entities, it can create an adapter in 0.17 seconds, and eats barely memory (4MB complete, including dll memory etc.).

That's on 32bit. Perhaps with a 1000 entities it will take a second or so, but not that much more, so it's beyond me why it's so slow on your machine. You compiled your own code with x64 target as well?

I've tested 3 options compiled my machine.

On 64bit machine, "All CPU" and "x64": long delay on start up and consumed lots of memory "x86": type initializer exception on startup up

On 32bit machine, "All CPU" and "x86": type initializer exception on startup up

I trace it in debug mode, I put a break point at DataAccessAdapter constructor, and it start to busy at this line

public DataAccessAdapter(string connectionString) : base(PersistenceInfoProviderSingleton.GetInstance())

and I step into it to see what it do, I press F11 to step into it, it start to consume memory and cpu, I waited for around 10 seconds, and then it jump to this line.

public static IPersistenceInfoProvider GetInstance()

for the following calls at DataAccessAdapter constructor, it does not have delay, and it run smoothly.

Hmm. Another customer tested the code on WinXP 64bit without a problem... very strange. Also, that you run into the problem on a 32bit machine, I haven't seen that problem here...

Do you run .NET 2.0 final or an earlier build? Or a later build with hotfixes?

Very strange, I copied the project to another 32bit machine and compile it, it has the same problem too.

It's final, v8.0.50727.42 (RTM.50727-4200) no hotfix installed, only installed SQL Server 2005 SP1, but I think it is not related.

Barry wrote:

Very strange, I copied the project to another 32bit machine and compile it, it has the same problem too.

It's final, v8.0.50727.42 (RTM.50727-4200) no hotfix installed, only installed SQL Server 2005 SP1, but I think it is not related.

I've exact the same version on my system, so that's not it. SP1 isn't installed here, but that indeed shouldn't be a problem.

Now, if PEVerify would only give some info about what exactly was wrong with the IL we could fix it, probably by swapping some statements around... however I can't reproduce it here .

I'll see if I can find more info about those wacky warnings given my peverify...

In debug mode, I see it loaaded TypeConvertor dll between DataAccessAdapter constructor and PersistenceInfoProviderSingleton.GetInstance(). Then I rename my TypeConvertor dll, and try to run it. It threw type initializer exception too.

Will the TypeConvertor have chance to cause problems to this issue?!

I've no ideas on this problem, I haven't seen it before....

Did you reference the .net 1.1 version? Or the .net 2.0 version of the type converter? If this is your own type converter, did you rebuild it on .NET 2.0?

I'm sorry you run into these problems, Barry. I wished I could reproduce some of it so I could fix them properly...

Otis wrote:

Did you reference the .net 1.1 version? Or the .net 2.0 version of the type converter? If this is your own type converter, did you rebuild it on .NET 2.0?

I'm sorry you run into these problems, Barry. I wished I could reproduce some of it so I could fix them properly...

I've mailed you a sample project which can duplciate the problem, please check it if you have time. Thank you very much!

I received it. I'll check it out. I only have 32bit hardware at my disposal, but as you got the problems on 32bit hardware as well, I'll try to reproduce it here as well.

Well, you're not going to believe it, but I found the cause!

The Init method contains the initialisation code of ALL the entities and ALL the fields. In your project this is a big fat 6200 lines of code, in one method.

The poor method is simply way too big. Which causes the bad IL.

I'll generate the method differently now: per entity an initialization method, which should make the code smaller and faster. Reflector also can't cope with the dll, so it's definitely not the right way to do things.

Problem is fixed, great job!!!

I compile my program with x86 flag now, it run much faster now, and even faster than v1, and it consume less memory too.

However, it still has a strange problem, the performance in 64bit mode is not good, it is several times slower than 32bit and consume much more memory.

My program is a remoting console, it would retrieve some data from database on startup. Therefore, slow startup would be caused by LLBLGen possibly. And it only have very little difference when I run it with v1 library.

Startup time v1 x86(32 bit): 3 sec All Cpu(64 bit): 3 sec v2 x86(32 bit): 3 sec All Cpu(64 bit): 15 sec

Peak memory consumed v1 x86(32 bit): 42 MB All Cpu(64 bit): 61 MB v2 x86(32 bit): 44 MB All Cpu(64 bit): 220 MB

Memory consumed after program is started v1 x86(32 bit): 42 MB All Cpu(64 bit): 61 MB v2 x86(32 bit): 44 MB All Cpu(64 bit): 120 MB

do you have any ideas about it? or any methods can help to trace which part running slow in 64bit?

Other customers on x64 have also reported slowdowns, but that also happens with native x64 build assemblies, so I think it's something with .NET on x64. I also think that All CPU builds put the mode of the proc in emu mode (not sure, can't test here) which is much slower. If you try a native x64 build, does that help?

x64 build also have the same result.

It is strange that it is several times slower than x86 build, and but it does not have big difference in v1. Did the .net 2.0 dll from v1 compiled with "All CPU" or "x86" flag?!

All CPU flag. Though the v1 .NET 2.0 library didn't contain any generics code. Perhaps that's the problem.