In general the DataSource smart tag works fine.

However, here is how to break it...

With your project open (I am doing WebForms), open LLBLGen GUI.

Add a few tables to the existing project, for which you have already generated code. Regenerate, flip back to visual studio.

Do a rebuild/rebuild all or whatever you want.

Now when using the DataSource, the drop down list of Entity Collection WILL show your new Entity Collections (that you just added).

Select one of the new Entity Collections - you will notice that 'EntityCollectionTypeName' will be set to BLANK! Open the smarttag again - and select an EntityCollection that existed when you first opened the project - it WILL correctly set the EntityCollectionTypeName. No matter what you do, it will NOT correctly set the TypeName.

I then closed and restarted Visual Studio (might could have just closed and re-opened the project) and it all worked fine.

Let me know if anyone else experiences this...

WayneBrantley wrote:

In general the DataSource smart tag works fine.

However, here is how to break it...

With your project open (I am doing WebForms), open LLBLGen GUI.

Add a few tables to the existing project, for which you have already generated code. Regenerate, flip back to visual studio.

Do a rebuild/rebuild all or whatever you want.

Now when using the DataSource, the drop down list of Entity Collection WILL show your new Entity Collections (that you just added).

Select one of the new Entity Collections - you will notice that 'EntityCollectionTypeName' will be set to BLANK! Open the smarttag again - and select an EntityCollection that existed when you first opened the project - it WILL correctly set the EntityCollectionTypeName. No matter what you do, it will NOT correctly set the TypeName.

True. VS.NET 2005 issue. I talked with Scott Guthrie about this when he was in holland and he said they also had the same problem when testing the controls for asp.net 2.0: VS.NET loads one version for a dll in the designer space, when another build is available it won't always refresh it. Tiresome, I know. I spend WEEKS trying to hunt down why it would break. The blank list is due to the fact that it can't find ANY type, using the type discovery service of vs.net.

Other people who have written own datasourcecontrols, like Llotka for CSLA 2.0 had the same problems. No-one found a fix.

Very frustrating, I know that myself as I ran into it a couple of times when programming the new backend for our website. What was so stupid was that when I closed the form, opened it again in markup then showed it in design view it sometimes got fixed.

What saddens me is that the asp.net team also suffered from this and even then they didn't fix it. What other big motivator do they need to fix this...

Least I am not crazy!

Should post this in known problems I guess (assuming it is not already there)...

I ran across another 'breaking change' that was not listed in your documentation.

The methods OnRemoveComplete and OnInsertComplete are no longer around to override in Collection classes. Easy fix, just replace them with overrides of OnEntityAdded and OnEntityRemoved. Just thought I would mention it.

WayneBrantley wrote:

Least I am not crazy!

Should post this in known problems I guess (assuming it is not already there)...

Will do

I ran across another 'breaking change' that was not listed in your documentation.

The methods OnRemoveComplete and OnInsertComplete are no longer around to override in Collection classes. Easy fix, just replace them with overrides of OnEntityAdded and OnEntityRemoved. Just thought I would mention it.

Thanks! I'll make a notion of this in the docs!

Otis, It appears that Rocky has a hack solution to this problem - a hack, but a solution - would beat restarting VS every time a new item is added to LLBLGEN..

do think I have a solution though (but it is a bit of a hack). The shadow directory names follow a very consistent pattern, and given one you can find the others - then use a DirectoryInfo object to determine the newest shadow directory and load the business assembly from that directory. Ugly, but I have it (mostly) working...

http://www.lhotka.net/WeBlog/CommentView,guid,dfb83e92-c297-4fc8-9c36-27dbb33201ef.aspx

(I see Frans had commented here about it being a known problem - before he came up with his workaround)

I could only find "it doesn't work"-kind of messages in that blogpost, not something like "do this and it works", simply because there's no real solution which always works (which is my understanding of it)

I could only find "it doesn't work"-kind of messages in that blogpost, not something like "do this and it works", simply because there's no real solution which always works (which is my understanding of it)

Nothing is that simple - or you would already have it!

I quoted the message I was referring to. As you know ASP.NET uses temporary directories to shadow the assembiles as it loads them. The problem is they assembly that is loaded (incorrectly) for you is NOT the latest one. So, if you knew the latest shadow directory you could load the assembly yourself and work around the bug completley!!

On that blog page I linked above - it describes (and has code) for the temporary loading of the assembly yourself to get the metadata. However, it is still the WRONG metadata because it comes from the wrong shadow directory.

The solution (hack) is - you KNOW the first shadow directory name and they are named in a consistent pattern - so you can find all the shadow directories. You can then use a DirectoryInfo object to determine the latest one - then manually load from that folder. It is ugly but evidently works..

But I ask vs.net to give me the types, I don't do that myself. that's what's going wrong. I also can't do that myself, as more projects could be referenced in hte solution, all having potential types to be used.

But I ask vs.net to give me the types, I don't do that myself. that's what's going wrong. I also can't do that myself, as more projects could be referenced in hte solution, all having potential types to be used.

Yes, I know - that is why you have to load the types up yourself! The code on his blog does just that- manually load the types (from the correct shadow directory) and just bypass the vs.net issue all together.

But then I run the risk that the code doesn't work when I use a debugger attached to vs.net as rocky also mentions.

It's clearly an issue in vs.net, and people should bug MS about this, as they have to fix it in the first place. I can add hacks and whatever goo to get this working somewhat and failing in other areas, but I feel that that's not the way to go.

but I feel that that's not the way to go

Fair enough.

Is the only way around this to restart Visual Studio? That is all I have found. Closing the solution, pages, etc does not seem to help.

WayneBrantley wrote:

but I feel that that's not the way to go

Fair enough. Is the only way around this to restart Visual Studio? That is all I have found. Closing the solution, pages, etc does not seem to help.

going to HTML view, close the page, build, open the page again in HTML, switch to design seems to work.

yesterday I read on rocky's blog that his initial approach didn't work in all cases, he now seems to have found a workaround hack.

I'll mail Scott Guthrie about this, he said to me I could mail him when I had a question about datasource controls, Let's see if he or his team has tips what to do.