cultofluna:
So I tried the ReadOnlyBase class used by the ReadOnlyBaseList and that did the magic trick. I was suprised to see the datalist immediately showed the ReadOnlyBaseList items! How does the list or the datasource know to use the list, even when specifying the items class??
![Big Smile [:D]](/emoticons/emotion-2.gif)
Sorry for the lateness of this post, but I just ran into the same problem and found this thread while searching for an answer. However, I'm not finding one. I did re-read chapters 5 and 10 and do not see anything that mentions the behavior that I am seeing and was reported earlier in this thread.
I created a web page yesterday with an Infragistics' UltraWebGrid. I added the CslaDataSource to the page and setup the TypeAssemblyName and TypeName properties along with the OnSelectObject event handler. Everything worked great, as promised and I was thrilled and showing off just how quickly and easily this was accomplished. I was able to go right into the UltraWebGrid designer and setup the column order, etc. and within 5 minutes had the page up and running. This was great!
Today I attempted to setup a second such page. This time I quickly added the controls manually in the Source View following the same pattern as the previous page. When I switched to the Design View so that I could use the UltraWebGrid designer, the CslaDataSource control failed, reporting that the TypeName property could not be set.
I tried deleting the control and adding it anew. Same problem.
So, just for kicks - and comparison - I opened up the page that I had created yesterday (the one that worked great!) and it had the same error message!
To further troubleshoot the problem, I ran the app so that I could see if the pages would come up and they both came up fine. This tells me we are dealing with strictly a design-time problem. However, because I could not get the schema setup, the second UltraWebGrid had its default settings (column order, etc).
That brought me here. I read this thread and discovered that I could eliminate the error by removing the TypeName and TypeAssemblyName values in Source View, switch back to the Design View, set the properties in the Properties Grid and click the Refresh Schema link as described above. This worked, the error went away, the UltraGrid updated to reflect the schema and I was able to use the UltraWebGrid designer to setup the columns as desired.
Unfortunately, when I went back to the original page (the one I set up yesterday) and followed the same steps, the UltraWebGrid was restored to its default settings and I had to go through and re-order all the columns, etc. again. I imagine this is by design as the grid probably doesn't know that the schema is just a refreshed version of the same - I'm sure it assumes nothing. So, the fact that this happened isn't so much a problem other than the need to do so.
When I come in tomorrow will I have to go through all of my pages and redo all of these steps again?!?!? In an application where I will have no less than 20 such views, this will get ridiculous fast.
So, can you tell me specifically why this error is occurring and what can be done to fix it short of following these steps for each and every instance in the application?
Thanks.
I don't know why this is happening, and I've been unable to replicate the issue, so debugging is challenging...
If you can reliably replicate the behavior you could help me out - though it is a bit complex.
What you need to do is
As you can see, without a failing project, this is impossible to debug - but if you can follow these steps it may give us a valuable clue as to why it occurs and then I can try and resolve it.
Okay, now I'm stumped.
Worked on 5 different pages with 5 different grids and 5 different data sources and all of them were repeatable and consistent in their failure. I couldn't even switch from Design view to Source view and back without them failing.
Shut everything down & came home. Powered up just now and walked through the steps Rocky suggested and all of them are working perfectly fine! No error messages. Data sources and grid come up as expected!?!
So, now I'm stumped. I'll have to wait and see if I can get it to fail then try this again. If so, I'll post the results.
On the brighter side, was actually worth the time to walk through how the control is setup and see the objects interact. Thanks for the insight on how to debug design-time behavior - that will come in handy in the future, I'm sure.
I'll let you know if I get it to fail again.
![Confused [*-)]](/emoticons/emotion-42.gif)
There's a slightly easier way, as long as you have the pdb files available for all your assemblies (including Csla).
From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Thursday, December 07, 2006 3:59 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] SOLVED?? Re: CslaDataSource TypeAssembyName & TypeName could not be set?
Run the program in question. Then goto the Debug menu, Windows, Modules. Find yoru assemblies, and right clilck on them. Choose the option to load symbols. It will ask you where to find the pdb. Locate it. It will also ask you to locate the source code.. locate that as well. You can then step through, all in one IDE session.
HTH
Andy
Got it to repeat!
Stepped through debugging as suggested and the code broke in the CslaDataSource class TypeName property setter on the statement:
((CslaDataSourceView)this.GetView("Default")).TypeName = value;
The error message was:
"Unable to cast object of type 'Csla.Web.CslaDataSourceView' to type 'Csla.Web.CslaDataSourceView'."
Stepping into the code, the view is returned from the GetView method and (obviously) failing on the cast.
I had to manually remove the TypeName and TypeAssemblyName attributes from the control in the web page, switch back to Design View and enter them into the Properties window to restore the control.
Any ideas?
I can tell you that this occurred after a rebuild of the complete solution - including the Csla assembly.
SonOfPirate:
"Unable to cast object of type 'Csla.Web.CslaDataSourceView' to type 'Csla.Web.CslaDataSourceView'."
I can tell you that this occurred after a rebuild of the complete solution - including the Csla assembly.
So do you have the Csla project as part of your business solution?
That's not a supported scenario, and may not be something we can fix. The IDE loads a version of Csla.dll into the AppDomain owned by the IDE and you are stuck with that version. But since I do dynamic loading of assemblies into a temporary AppDomain to reflect against your business assembly, it could be loading a different version of Csla.dll at that point - which would cause no end of confusion...
It is not supported to have the Csla project and your business/UI projects in the same solution in VS.
The source was added to simply debug and testing and toying with changes/customization/tweaks. but, this makes sense. I believe that it occurred after I recompiled the source assembly the last time as well. It is understandable that the versions are out-of-whack then, which would obviously lead to the casting error.
I will have the assembly removed from the solution. I think our understanding is thorough enough at this point that there's no benefit versus a reference any longer.
Thanks for the help understanding what has happened.
A little late in my response here, but I encountered the same issue just now. This was caused by having a web app running in 1.5 and then attempting to run another one (the one that failed) in 2.0.
I shut down the 1.5 application and the issue was resolved.
Copyright (c) Marimer LLC