All--

Please help.

I am getting an error when I try to ReadXml into an EntityCollection after a web service call.

Here are the details...

--A ClientApp makes a call to a WebServiceApp.

--The WebServiceApp creates an EntityCollection, uses EntityCollection.WriteXml(), puts the Xml into an OutputString, and sends the OutputString back to the ClientApp.

--The ClientApp catches the OutputString from the WebServiceApp, creates a new EntityCollection, calls EntityCollection.ReadXml() to read the OutputString into the EntityCollection.

--A RTE of NullReferenceException occurs. (See the complete message below.)

Note that the ClientApp and the WebServiceApp both use file-references pointing to the exact same DLLs....

FMGlobal.Research.RulesEngine.BusinessObjects.dll FMGlobal.Research.RulesEngine.BusinessObjectsDBSpecific.dll SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll

...which exist in a common "SharedReferences" folder.

Note that for testing I write the XML OutputString to a file in the WebServiceApp before sending it back to the ClientApp. I also write the XML to a file in the ClientApp before calling ReadXml. According to >SourceSafe, >Tools, >ShowDifferences, the files written are identical, (with or without IgnoreWhitespace turned on).

Note that for testing, in the WebServiceApp, after the call to WriteXml, if I immediately make another EntityCollection and try to ReadXml back into it, it works fine.

Note that the WebServiceApp is DotNet 2.0 and the ClientApp is DotNet 1.1.

Note that I am using this overload... public void WriteXml(out string); ...for writing the XML to the OutputString in WebServiceApp.

Note that I am using this overload... public void ReadXml(string); ...for reading the XML OutputString back into an EntityCollection in the ClientApp.

Note that the OutputXml, as written to a file in the WebServiceApp, can be opened in IE6 just fine.

Note that the OutputXml, as written to a file in the ClientApp, can be opened in IE6 just fine.

Note that the DLLs that contain the LLBLGen entities were created for DotNet 1.1, which is the way it must be in order for those DLLs to be referenced in both a DotNet 1.1 project and DotNet 2.0 project.

So, something strange is happening, I think.

What do you think?

Do you have any suggestions?

Please advise.

(FYI, we are using LLBLGen, ASP.NET, VS.NET 2003, VB.NET, .NET 1.1, the Adapter templates, SQL Server 2000, web services, SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll Version 1.0.20051.51207, SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll Version 1.0.20051.51214, Windows XP Pro, IIS 5.1, and so on.)

Thank you.

--Mark Kamoski

[FMGlobal.Research.RulesEngine.AdminClient.Windows]

System.NullReferenceException: Object reference not set to an instance of an object.

at SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2.Xml2EntityCollection(XmlNode node, Hashtable processedObjectIDs, ArrayList nodeEntityReferences)

at SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.Xml2Entity(XmlNode node, Hashtable processedObjectIDs, ArrayList nodeEntityReferences)

at SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2.Xml2EntityCollection(XmlNode node, Hashtable processedObjectIDs, ArrayList nodeEntityReferences)

at SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2.ReadXml(XmlNode node)

at SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase2.ReadXml(String xmlData)

at FMGlobal.Research.RulesEngine.AdminClient.Windows.Common.DataHelper.GetEntityCollection(Type entityType) in C:\projects\Shared\RulesEngine\RulesEngine.AdminClient.Windows\Common\DataHelper.vb:line 97

at FMGlobal.Research.RulesEngine.AdminClient.Windows.MetaDataManagerMainForm.GetAllAssemblyInfoButton_Click(Object sender, EventArgs e) in C:\projects\Shared\RulesEngine\RulesEngine.AdminClient.Windows\MetaDataManagerMainForm.vb:line 292

OK

If you are calling the webservice from a different machine: Could you check the runtime build version on both machines? You can request that in code: string build = RuntimeLibraryVersion.Build;

Walaa wrote:

If you are calling the webservice from a different machine: Could you check the runtime build version on both machines? You can request that in code: string build = RuntimeLibraryVersion.Build;

That's a good idea.

However, this is in development and therefore all on the same machine for now; so, that does not really apply to my case.

Unless...

Note that in my explanation above I state that...

The ClientApp is DotNet 1.1.

The WebServiceApp is DotNet 2.0.

...so, the underlying assumption is that when I pass a String from DotNet 2.0 to DotNet 1.1 there is nothing different about that String, especially given that it is passed via a web service where the type management should be handled AOK by the inner-working of the web service infrastructure. However, maybe this does matter?

Please let me know if more ideas come up.

Thank you.

--Mark Kamoski

All--

FYI, here is an update on the issue that I note above.

I made a simple sample application using Northwind, SQL Server 2000, VS.NET 2003, and VS.NET 2005, and so on.

Testing Goal -- Simplify the problem and see if the same error occurs when the code is very simple.

Testing Result -- The same error occurs.

If you are interested and can help, the sample projects are posted for download here...

http://www.weblogicarts.com/Llblgentest1.aspx

...so please help if you can because this is a show-stopper and so far we have no workaround.

Thank you.

--Mark Kamoski

All--

FYI, here is an update on my testing of this issue.

Testing Goal -- Create the same test as above in a VS.NET 2005 WindowsForm client app and test the same web service and see if the VS.NET 2005 client app behaves any better than the VS.NET 2003 client app.

Testing Result -- The VS.NET 2005 client app works and the VS.NET 2003 client app does not work, despite the fact that both apps reference the same web service and the same entity object DLLs and the same LLBLGen core DLLs.

Very strange.

Here are some details....

I created a VS.NET 2005 WindowsForms client app using the same internal code as the VS.NET 2003 WindowsForms client app.

I used the exsting VS.NET 2005 WebService app.

I tested the WebService with the WindowsForm VS.NET 2005 app and it ran just fine.

Strange!!!???!!!

So, bascially, this implies that the core LLBLGen DLLs and/or the LLBLGen-generated entity object DLLs behave differently when calling EntityCollection.ReadXml() depending upon whether they are running in VS.NET 2003 or in VS.NET 2005?

I find that odd.

I have updated the download to include the LLBLGen project, the new VS.NET 2005 WindowsForms client app, all the generated code, and so on. It can be downloaded here...

http://www.weblogicarts.com/Llblgentest1.aspx

Therefore, this would not be a problem if the client app were a VS.NET 2005 app; however, unfortunately, the current requirements are such that the client app (for now) is gonig to to be VS.NET 2003.

Next Test -- Create a proxy VS.NET 2003 web service that acts as a (temporary) pass-through, which sits between the VS.NET 2003 WindowsForms client app and the VS.NET 2005 WebService app.

This is getting worse by the minute; so, any help at all is appreciated. Guesses, speculations, hints, and all comments are welcome.

What do you think?

Please advise.

Thank you.

--Mark Kamosk

All--

Here is an update to my testing.

Test -- Created a VS.NET 2003 web service that acts as a proxy, sitting between a VS.NET 2003 WindowsForms client app and the VS.NET web service app, and see if the behaviour is differenct.

Result -- No change. Same result. The XML is returned but calling EntityCollection.ReadXml in the client app does not work.

Ug.

The code can be found here...

http://www.weblogicarts.com/Llblgentest1.aspx

Next Test -- Build a VS.NET 2003 client app and a VS.NET 2003 web service app and test.

Any help is appreciated.

Thank you.

--Mark Kamoski

All--

FYI, here is an update on the issue that I have been working on, as detailed above.

Test --

Well, in this latest round of testing I created a VS.NET 2003 WindowsForms client app and a VS.NET 2003 web service app.

As usual, both use file references to the exact same DLLs for the LLBLGen core libraries and the LLBLGen-generated business objects.

In the web service app, I use EntityCollection.WriteXml and return the String.

In the client app, I catch the String returned and try to use EntityCollection.ReadXml to build an EntityCollection object.

Result --

It does not work. The String returned is the same as the one that that left the web service. But, the ReadXml call fails.

Conclusion --

(A) Either the testing is flawed.

...OR...

(B) The EntityCollection.ReadXml LLBLGen is wonky and/or does-not-support this type of use.

...OR...

(C) Both (A) and (B).

This is a real show-stopper because we did not want to have to make our own DTOs, we cannot use the Templates With Web Service Support, we have to use VS.NET 2003 to build the client app, and so on, as noted above.

I am not sure what the next step is. I was very confident that this latest round of testing would work. I am really puzzled as to why it does not. It is VERY strange. I suppose that I will go back and triple-check this latest round of testing-- but, it is very simple and if I find no error then we will really be stuck.

Update 2006-Jun-22-Th 15:40 GMT-0500: FYI, I triple-checked the code for this latest round of testing and I am as certain as I can be that it is AOK. I re-checked all the references. I re-checked all of the code, what little there is. I re-ran the tests. The upshot is that the ReadXml call still fails. At this point, I am leaning towards Conclusion (B), as stated above.

FWIW, all of the files for the projects can be found here for download...

http://www.WebLogicArts.com/Llblgentest1.aspx

As always, any help is appreciated.

Thank you.

--Mark Kamoski

Please update your runtime libraries, they're outdated. Then re-test. You use libraries from december 2005.

Also, with distributed applications: always keep client and server at the same version, both .net and your own code. I don't understand a requirement where your webservice is .net 2.0 and your clients are not. However in this case it shouldn't be a problem that much.

However your posts are so massive, I'm now confused what worked and what not. I also conclude you're using the .NET 11 runtime libs on the server with the .net 2.0 app?

Mark, you also should know that if you're really looking into a deadline and with these kind of exceptions, might be handy if you build your testapp against a debug build of the runtime libs sourcecode (latest) and see where it crashes. I'll test your app shortly.

Ok I've tested your code, and the problem is this:

In .NET 2.0, the base class of EntityCollectionBase2, CollectionBase (which is a .NET class) has more public properties than in .NET 1.1. So at the service, a property exists called 'Capacity'. This is serialized into the code, as it's a base class property and that's unknown to the code. At the client however this property is unknown and the code dies.

This is the kind of crap that you get when you use different versions of .NET and other differences in versions at both sides of a webservice.

I could fix it with a workaround inside the code where the code checks if the property exists and then sets it if it does. I'll make that change now, and mail you an updated dll.

However, PLEASE, reconsider your design. If you have .NET 1.1 clients, build your webservice in .NET 1.1. Using .NET 2.0 for that is asking for problems sooner or later.

(edit): dlls mailed (file is a zip file, rename zzz to zip)

Otis wrote:

Please update your runtime libraries, they're outdated. Then re-test. You use libraries from december 2005.

OK. I will update these and retest.

Otis wrote:

Also, with distributed applications: always keep client and server at the same version, both .net and your own code. I don't understand a requirement where your webservice is .net 2.0 and your clients are not. However in this case it shouldn't be a problem that much.

While I agree with you (for the most part) and I have been pushing for moving everything to DotNet 2.0. Unfortunately, as a contractor, I am sometimes at the control of whimsical and less-than-reasonable requirements. Then again, I must say, that I should not expect to be able to "level the playing field" everytime I cannot get something to work. As such, I am a bit less categorical than you on the matter of same version for the client and server when it comes to web services. That is, one of primary motivating forces behind web services is the idea of inter-operability of disparate systems. I mean, if everything has to be the same version, why stop there? Why not everything on the same OS? The same version of the same OS? The same SP of the same version of the same OS? And so on. That's the DCOM/COM+ trap; so, I certainly hope that we can avoid it. I agree that there is a point to be made about "what should work" and "what does work". Web Services V1 largely missed the mark and dissapointed-- it was not all it was cracked up to be. But, it has been some time since then. Therefore, I am thinking that in the case of using web services (at least) that "it shouldn't be a problem that much".

Otis wrote:

However your posts are so massive, I'm now confused what worked and what not. I also conclude you're using the .NET 11 runtime libs on the server with the .net 2.0 app?

Yes, massive, I know. Heaven knows I wish I could have avoided all that testing. Ug. Anyway, there are several tests in the zip file. I explain the details are in the "ReadMe" file in the root of the zip package.

However, note in particular the following...

(1) I tested DotNet 1.1 client and DotNet 2.0 web-service >>> it did not work.

...BUT...

(2) I also tested DotNet 1.1 client and DotNet 1.1 web service >>> It did not work.

I perhaps can understand why (2) did not work-- but, I simply cannot understand why (1) did not work.

Otis wrote:

Mark, you also should know that if you're really looking into a deadline and with these kind of exceptions, might be handy if you build your testapp against a debug build of the runtime libs sourcecode (latest) and see where it crashes.

Oh. I am sorry; but, I did not even know that was possible. That is, I thought you had just released the DLLs to paying customers-- not the source code or a debug build. I will make a note of this and do it for the future. It is good to know and it is kind and thoughtful of you to make such access available.

Now, I will go on to more testing.

Thank you for you help thus far.

--Mark Kamoski

Otis wrote:

Ok I've tested your code, and the problem is this:

In .NET 2.0, the base class of EntityCollectionBase2, CollectionBase (which is a .NET class) has more public properties than in .NET 1.1. So at the service, a property exists called 'Capacity'. This is serialized into the code, as it's a base class property and that's unknown to the code. At the client however this property is unknown and the code dies.

This is the kind of crap that you get when you use different versions of .NET and other differences in versions at both sides of a webservice.

I could fix it with a workaround inside the code where the code checks if the property exists and then sets it if it does. I'll make that change now, and mail you an updated dll.

OK. That makes some sense; but, questions remain. DotNet version mixing may be a factor for the tests where the client is DotNet 1.1 and the web service is DotNet 2.0. However, for all tests, note that the LLBLGen runtime DLLs are DotNet 1.1 and the LLBLGen-generated entity DLLs are DotNet 1.1. So why would EntityCollection.ReadXml/WriteXml (coming from a DotNet 1.1 library) behave differently whether it is called from a DotNet 2.0 or a DotNet 1.1 Assembly?

There is something else that still is unexplained. In one of the tests there is a DotNet 1.1 client and a DotNet 1.1 web service. ReadXml did not work. Therefore, I cannot see how this particular case can be related to the version of DotNet because everything uses the same version of DotNet.

Otis wrote:

However, PLEASE, reconsider your design. If you have .NET 1.1 clients, build your webservice in .NET 1.1. Using .NET 2.0 for that is asking for problems sooner or later.

I am reconsidering. I may not have the luxury to downcast everything to DotNet 1.1 in this case. Still, I think that it should not matter in the case of passing a String over a web service, for the reasons that I noted above. Regardless, I will try to move everything to DotNet 1.1 just to eliminate a variable from the equation, against my better judgment.

Otis wrote:

(edit): dlls mailed (file is a zip file, rename zzz to zip)

That is appreciated very much. I will not be able to pick up that email address's mail until I am home (due to corporate lockdown on personal email). If you have a minute, if you would be so kind as to send to Mark.Kamoski AT FMGlobal.com which is where my contract is located, that would help a lot. Regardless, I will try them ASAP, one way or another.

For now, I plan to update my LLBLGen runtime DLLs and then retest the DotNet 1.1 client with the DotNet 1.1 web service. I will report back ASAP.

Thank you.

--Mark Kamoski

You don't have to test anything, don't waste time on that. I know what the cause is: .NET 2.0's version of CollectionBase has more public properties than .NET 1.x version. This causes more properties to be serialized into the XML. As the code assumes both versions of the TYPES are the same, it didn't check if a property was there, as that was a given.

However in your situation it's not the case, some xml for property 'Capacity' arrives at the client and this thus fails. This is caused by mixing .NET versions in a distributed application. I'll send the same email to your other emailaddress, that will fix THIS problem, though it might be you will run into others later on: keep .NET versions the same if you're serializing TYPES across a service, which you're doing.

If you manually fabricate the XML, as with a message, you won't run into this of course, but with TYPES you will.

Otis wrote:

...I know what the cause is: .NET 2.0's version of CollectionBase has more public properties than .NET 1.x version. This causes more properties to be serialized into the XML. As the code assumes both versions of the TYPES are the same, it didn't check if a property was there, as that was a given.

However in your situation it's not the case, some xml for property 'Capacity' arrives at the client and this thus fails. This is caused by mixing .NET versions in a distributed application...

Unfortunately, that does not seem to apply to my situation because I am now using DotNet 1.1 everywhere.

Test --

Tear down everything DotNet 2.0, find and delete all DLLs of that kind.

Convert everything to DotNet 1.1.

Get the latest version of the LLBLGen Runtime DLLs, via http://www.llblgen.com/pages/secure/upgrades.aspx which yields...

LLBLGen Pro full installer v1.0.2005.1 download
Release date: 21-jun-2006. Version: 1.0.2005

Regenerate the business entities.

Double-check all file reference to be sure they point to the latest LLBLGen Runtime DLLs and the regenerated business entities.

Connect the DotNet 1.1 client to the DotNet 1.1 web service.

Call myEntityColelction.WriteXml(theString) in the web service and return the theString to the client and call myEntityCollection.ReadXml(theString) in the client.

Result --

Error. The code breaks on the myEntityCollection.ReadXml(theString) call, as before.

FWIW, the test code is here...

http://www.WebLogicArts.com/LlblgenTest2.aspx

Otis wrote:

...I'll send the same email to your other emailaddress...

Great. I appreciate that.

The short story is that I have not been able to try that new hot-fixed set of DLLs.

Why? Well, the long story is that, unfortunately, as it turns out, I will proably still have to wait until after the weekend to pick it up at home and bring it in manually. The corporate security filter grabs emails with attachments (sometimes) and holds them for scanning and (maybe) will release them "at a later date". I was hoping this time it would miss it and let the email thought. As my luck would have it, it grabbed the email in this case, (apparently because I have not yet seen it in my InBox. So, that's what it seems to have happened this time. I cannot fight it because I am contractor and this is the client's corportate policy. Oh well.

Otis wrote:

...that will fix THIS problem, though it might be you will run into others later on: keep .NET versions the same if you're serializing TYPES across a service, which you're doing.

Well, I have converted everything to DotNet 1.1 so DotNet versions will not be a factor anymore.

Therefore, unfortunately, the problem remains.

Questions...

(1) Are you saying that if everything is DotNet 1.1 then I still MUST have that hot-fixed set of DLLs that sent? Or are you saying something else?

(2) I am under the impression that I need the hot-fixed set of DLLs IFF I am trying to use a DotNet 1.1 client and a DotNet 2.0 web service. But, I am not trying to do that now. Right now, I am now using just a DotNet 1.1 client and DotNet 1.1 web service which, as I understand it, should simply work with the latest LLBLGen Full Version Release date: 21-jun-2006 and its containted Runtime Library DLLs. Right?

Please advise.

Thank you.

-- Mark Kamoski

Please, could you formulate the problem more erm... compact

I tested your code you had up on your site. The problem was the 'Capacity' property. it wasn't found in the set of properties, yet the code assumed it was, null was returned from the hashtable, etc. crash.

By checking for that, and ignoring the properties not in the type to fill with data, it worked, I could run your test app.

Now, please inform me: why did your testapp work here, and why shouldn't it work over there? Did you apply the libraries I mailed you and do they still crash?

I mailed you fixes, those aren't up on the website yet, so you should use the runtime libs I mailed you (to two email addresses). Please, use THESE in your tests. Also, it might sound blunt and arrogant, but I'm not interested in things which work, I'm interested in things which don't work, AND which apply to your situation. So let's fix this step by step. You are writing an application, you want to use a webservice and a client. You write the code the way you think it should be written.

It crashes in the ReadXml routine.

I then mail you a fix. You should use the runtimes I mailed you in the app you're working on. If it still crashes, it's a different problem, and not related to the problem earlier simply because your repro program which crashed on the ReadXml bug did work with the dlls I mailed you this morning.

It's likely a misunderstanding between you and me that you thought to use the runtimes on the website, while I mailed you the ones you should use. Use the ones I mailed you, in the app you're writing.

Otis wrote:

Please, could you formulate the problem more erm... compact

EntityCollection.WriteXml and EntityCollection.ReadXml do NOT work. Period.

I've tried to be more kind out of courtesey-- but, basically the serialization is broken in LLBLGen.

The code I posted proves it.

That's about as compact as I can be.

(Sorry.)

Otis wrote:

I tested your code you had up on your site. The problem was the 'Capacity' property. it wasn't found in the set of properties, yet the code assumed it was, null was returned from the hashtable, etc. crash.

Nope. It still did not work with a DotNet 1.1 client and DotNet 1.1 web service.

Otis wrote:

Now, please inform me: why did your testapp work here, and why shouldn't it work over there? Did you apply the libraries I mailed you and do they still crash?

I mailed you fixes, those aren't up on the website yet, so you should use the runtime libs I mailed you (to two email addresses). Please, use THESE in your tests. Also, it might sound blunt and arrogant, but I'm not interested in things which work, I'm interested in things which don't work, AND which apply to your situation. So let's fix this step by step. You are writing an application, you want to use a webservice and a client. You write the code the way you think it should be written.

As I said, above, I cannot get the email due to client corporate email filtering. Not something I can workaround at the moment.

As it is, I used the latest Full Product download with a DotNet 1.1 client and DotNet 1.1 web service.

ReadXml is broken. It does not work. See...

http://www.WebLogicArts.com/LlblgenTest2.aspx

Otis wrote:

Also, it might sound blunt and arrogant, but I'm not interested in things which work, I'm interested in things which don't work, AND which apply to your situation.

No problem. I can handle directness. I, on the other hand, must concern myself with things that do work.

Unfortunately, LLBLGen Full Product Release date: 21-jun-2006 does not work.

I am trying hard not to bash your product here, Otis. Edit this post if you like. But, the fact is that, as I thought I made clear (gently) before--- LLBLGen Full Product Release date: 21-jun-2006 does not work with EntityCollection.WriteXml and EntityCollection.ReadXml do not work with a DotNet 1.1 client and DotNet 1.1 web service. It is broken. It has a bug. That is proven in the code that I link here...

http://www.WebLogicArts.com/LlblgenTest2.aspx

I don't know about the hotfix. Maybe that works, maybe it doesn't. As I said before, I will try the fix that you sent ASAP. But, I cannot do that right now. I mention that above.

I respect the fact that you are busy and want brief posts. But, the posts are long because they contain information that should be read. We are all busy. But, it is also a waste of time to repeat oneself after having already provided the details. I mentioned the reasons why I could not use the hot-fix right now because it is out of my hands.

As it is, I updated the LLBLGen Version (as you recommened) and it does not work. That's it. I had to do that testing because I cannot simply stand still and do nothing.

BTW, I am also reluctant to use the hot-fix that you sent because it would mean integrating a hot-fix set of DLLs into an entire enterprise application structure. Mine is not the only LLBLGen-driven sub-system. So, the tech-lead on the project will decide that. I was hoping that the LLBLGen Full Product Release date: 21-jun-2006 would work; but, it doesn't.

Anyway, I really appreciate your help. I like the product. You are great. Et cetera. I will try the hot-fix ASAP. At this point, I see that you are agreeing (directly or indirertly) that LLBLGen Full Product Release date: 21-jun-2006 has a bug WRT WriteXml and ReadXml and that the hot-fix is needed. That's fine and I understand it and will do my best.

Please send along any more help that you may have.

Thank you.

--Mark Kamoski

let it be clear that whatever you can download from our website does not contain the fix I sent you. If you run any of those dlls, you will run into the same problem.

I sent you a fix which I wrote early this morning as soon as I saw you postings, so you could start using it and move on when you arrived at work.

I stated as my first remark, before I wrote my second post where I acknowledged the error, that you should run the latest runtimes. I did that to be sure it's not something that was fixed already. That's all.

As I sent you dlls which should fix the problem, we can all spend days and days on running other code to see if that works, but that's not going to work. You sent me a testapp, I pressume that app represents hte way you consume the webservice. If that app works with the new dlls at your site, I can roll out an official build so your manager can agree on using that one.

All I want to be sure of is that no time is wasted on testing code with code which doesn't contain the fix. OK?

I understand you don't bash the product, that's not the issue here, Mark. I just want to move forward so you can move forward and you won't waste your time on things which won't lead to any progress on your side. As you sounded you needed the fix fast I made the fix before I did anything else this morning. I understand it can be complicated to put a fix into a big system, though there's no alternative: if you want to use code which works, and it's in a patch, you have to use the patched version, or deal with the bug, and that's in this case rather hard to do, as it gives a cold exception.

I hope you'll get the oppertunity to run the updated runtimes a.s.a.p. so you can move on with your work.

What I don't understand is that if the types are the same (.net 1.1 both) it also doesn't work as I've several unittests which simply do nothing other than fetch graphs, alter data, serialize to XML, and read it back.

FYI: the app you posted above as the latest testapp simply works here with the builds I sent you.

I pulled down your latest example and since I don't have the northwind installed I switched it to a test database on my machine with the May 2nd version and it ran fine.

Otis wrote:

FYI: the app you posted above as the latest testapp simply works here with the builds I sent you.

That is good news.

I have more good news too-- the hotfix "RuntimeLibraries_06232006.zip" has fixed the issue at this end too.

FWIW, my tests are posted here...

http://www.WebLogicArts.com/LLBLGenTest5.aspx

...and all looks good.

I really appreciate your usual quick attention to this matter. My boss appreciates it too. I am very sorry if I upset you or your team in any way or did anything else unkind. That was never my intention. As always, I really like LLBLGen, I use LLBLGen a lot, and I recommend LLBLGen whenever I can. You and your team are doing a great job-- keep up the good work.

Thank you.

--Mark Kamoski

bclubb wrote:

I pulled down your latest example and since I don't have the northwind installed I switched it to a test database on my machine with the May 2nd version and it ran fine.

This is good news.

It is nice to have corroboration from multiple sources.

As a side note, I was very surprised to hear that you did not have Northwind installed. It is a good thing to have around for testing. It allows (somewhat) uniform testing across multiple machines without having to distribute a schema with the tests. On the otherhand, adding more dimensions to the test can increase the test's coverage; so, it is also a good thing that you tested this with a different schema. IMHO.

Thank you.

-- Mark Kamoski

Glad it's solved Mark!

Otis wrote:

Glad it's solved Mark!

...BTW, just so you know I wasn't being a jerk...

...below is a copy of the "heavy duty" anti-spam message that I received...

...it wouldn't be a bad progarm IF it weren't for the one day delay...

...BTW, that is too bad about Netherland's loss... they deserved to win that game... many more good shots on goal... much more quality ball possession... better attacks... cleaner playing style... and so on... oh well... c'est la vie... next time maybe...

-----Original Message----- From: FM Global Anti-Spam Team Sent: Saturday, June 24, 2006 00:14 To: Kamoski, Mark Subject: E-mail Quarantine Release Notification - Sat, 24 Jun 2006 00:13:31 -0400

The anti-spam solution has blocked at least one e-mail that was sent to you today from outside FM Global. Spam e-mails may be offensive or violate the Acceptable Use Policy for Electronic Mail.

No further action is required if you want the anti-spam solution to automatically delete your blocked e-mails after 14 days. You can review, release, or manually delete any blocked e-mails by clicking the following Web link:

https: //johncqsp02.corp.fmglobal.com:443/urq/urqMailList.do?method=processMail&a5a533d8fb50016ce79beed088c2cd3a5673ef1400000000000003689261

Caution:When you release a blocked e-mail that has multiple recipients, you also release the e-mail to the other recipients. Please release only valid business e-mails.

UPDATED ==> The following documents provide more information on using the anti-spam solution: • Anti-spam Solution Quick Steps show you how to review, release, or manually delete your blocked e-mails.

• Anti-spam Solution Frequently Asked Questions answer questions you may have about your blocked e-mails.

Please be aware that replies to this mailbox are not actively monitored. To log a support call, please contact one of the following:

• Your local information specialist • Corporate Help Desk in Johnston, RI, USA at 401 <<< DELETED >>> • International Help Desk in Windsor, UK at +44 (0) 1753 <<< DELETED >>>

Thank you.

mkamoski wrote:

Otis wrote:

Glad it's solved Mark!

...BTW, just so you know I wasn't being a jerk... ...below is a copy of the "heavy duty" anti-spam message that I received... ...it wouldn't be a bad progarm IF it weren't for the one day delay...

Hmm, that indeed sounds awful and as a perfect explanation why it took so long to get the dlls to you.

...BTW, that is too bad about Netherland's loss... they deserved to win that game... many more good shots on goal... much more quality ball possession... better attacks... cleaner playing style... and so on... oh well... c'est la vie... next time maybe...

Yeah I guess what counts nowadays is: - getting friends with the referee so he lets you score from offside position, give you a penalty kick in the last minute etc. - defend defend defend and hope for an error of the other team. - as soon as the other team crosses the middle line, make a small foul, so the referee has to stop the game but you won't get a card.