Version 2.0.1 beta available

Old forum URL: forums.lhotka.net/forums/t/151.aspx

RockfordLhotka posted on Friday, May 19, 2006

A beta release of version 2.0.1 is now available at www.lhotka.net/cslanet/download.aspx.

This is primarily a bug fix release to fix the various errata that people have submitted thus far. It does include some code changes to improve functionality in some areas, again based on reader feedback. You can find a change log from the download page.

The biggest, and most in-need-of-testing change is to the CslaDataSource web data control. I enhanced the VS 2005 designer support in this control so it detects and reloads your business object's metadata when you rebuild the solution - without the need for closing the designer window or VS 2005 itself. This was a very big change and I really don't know if my solution will work in all VS configurations, so if you get a chance to test this I'd really appreciate it!

skagen00 replied on Friday, May 19, 2006

Hello Rocky,

Thanks for issuing a .0.1 release. I have downloaded it (really to try to CslaDataSource).

To me, it's not too horrendous to exit and come back in, but it didn't work for me without doing so. I'm probably a fringe case.

I use the CslaDataSource with my "NameValuePairs" replacement which I call CodeType.

My base class is:

public abstract class CodeType<CT, K, V, S> : ReadOnlyBase<CodeType<CT, K, V, S>> where S : IComparable

Within CodeType is the ability to get various "depth level" CodeOptionTrees, which are:

public class CodeOptionTree : ReadOnlyBindingList<CodeOption>, IHierarchicalDataSource

And a CodeOptionTree is a list of CodeOption (similar to a name value pair but with parentkey and sortvalue). CodeOptionTree is what I bind to. It is within CodeOption that I attempted to add a value called "TestKey" to go along with "Key", "Value", "Extended Value", ..etc... It is this value that didn't show up until I exited and reentered VS 2005. (Tried rebuilding solution, refreshing schema, etc.)

Now my concrete code type classes are as such:

[Serializable()]

public class Prefix : StandardCodeTypeBase<Prefix>

{

private Prefix(): base()

{

_codeTypeID = 3;

}

// Simply provide a signature that can be used by the CSLA Data Source

private class Options : CodeOptionTree { }

}

Where the majority of the guts of most CodeTypes (standard code types) are in StandardCodeTypeBase (which is an abstract class that inherits from CodeType).

One other thing is that I find I have to declare a "signature" class in my concrete classes as you see above, nothing major. Otherwise I can't seem to get the CSLA Data Source to recognize my class.

My CSLA data sources tend to look like this:

ID: ContactTypeDataSource

TypeAssemblyName: Prototype.Library

TypeName: Prototype.Library.Prefix+Options

(My CodeTypes, or NameValuePairs, maintain a list of "CodeOptionTrees", one list for each "depth" level of coding).

So obviously I'm probably a fringe case and I'm not too concerned about exiting and reentering but I thought I'd let you know it is still an issue for me.

RockfordLhotka replied on Friday, May 19, 2006

One thing to keep in mind is that you may have been using the old CslaDataSource control.

The only way I have found to upgrade a control (once the designer has been loaded) is to do this:

1) Open your solution in VS

2) Close all designers and code windows

3) Close VS

4) Open your solution in VS (now with no windows open)

5) Do a complete solution rebuild - thus ensuring that the new Csla.dll is loaded into all projects

6) Close VS

7) Open your solution in VS and work with it - you should now be running the new Csla.dll

Rocky

xal replied on Friday, May 19, 2006

Or get the best companion for a crashing ide (really a very handy tool!) and...
1-Close all designers (Optional, but once you rebuild you'll need to close-reopen them).
2-Close VS
3-Run Clean sources in your solution's folder.
4-Reopen VS.
5-Rebuild Solution.

That's it!

It helped a lot when working on those pesky attributes to get generic / abstract forms working on the ide.

Andrés

RockfordLhotka replied on Wednesday, May 24, 2006

I have refreshed the beta of 2.0.1 to fix a couple reported issues - and to add a couple new changes.

The big one is to address the need to support polymorphic child objects in a BusinessListBase collection. Given that the code still passes all the old unit tests I don't think my change broke anything in the framework, and it should allow you to create a non-generic interface that all your child classes can implement.

And of course the really big change is to CslaDataSource as noted earlier.

If you get a chance to try using 2.0.1 over the next few days I would appreciate it. I would very much like to release this update, because it does include a number of important bug fixes. You can get it from www.lhotka.net/cslanet/download.aspx.

Thank you!

niros replied on Friday, May 19, 2006

Where is the updated Project Tracker?

RockfordLhotka replied on Friday, May 19, 2006

I'll get there, I'll get there :)

(I knew I'd forget something...)

Rocky

Where is the updated Project Tracker?

RockfordLhotka replied on Friday, May 19, 2006

The zip files have now been updated to contain the ProjectTracker sample app as well as the framework code. If you downloaded them earlier today, please download them again to get the full deal.

Rocky

RockfordLhotka replied on Thursday, May 25, 2006

OK, this is the final beta of 2.0.1. Barring any negative feedback from you I'll release it next week. So you can either test it now, while I can still react to issue, or test it after I release Big Smile [:D]

.

At the rate I'm going with changes, I'll never get it out if I don't do a firm cut-off, so this is it. No more changes other than bug fixes until 2.0.1 is out. Thanks!

ajj3085 replied on Thursday, May 25, 2006

Hi Rocky,

The errata says that the ClientContext has the threading issuse discussed in this thread addressed, but I don't see the files that would contain the update in the zip file.

Andy

RockfordLhotka replied on Thursday, May 25, 2006

The change is to the ApplicationContext.(vb/cs) file under DataPortal.

Make sure the zip file you downloaded is csla20XX-2.0.1-060525.zip - specifically note the date, which should be 060525.

ajj3085 replied on Friday, May 26, 2006

Ok, must have used files from an older folder I extracted.

Thanks.

Mark replied on Friday, May 26, 2006

Just downloaded the latest beta w/the changes to ClientContext.

I noticed that the entire call to GetClientContext/SetClientContext is locked. Since the lock is only necessary if you're accessing ClientContext via the AppDomain, couldn't you rewrite GetClientContext as...

internal static HybridDictionary GetClientContext()
{
   if (HttpContext.Current == null)
   {
      if (ApplicationContext.ExecutionLocation == ExecutionLocations.Client)
      {
         lock (_syncClientContext)
         {
            return (HybridDictionary)AppDomain.CurrentDomain.GetData(_clientContextName);
         }
      }
      else
      {
         LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_clientContextName);
         return (HybridDictionary)Thread.GetData(slot);
      }
   }
   else
      return (HybridDictionary) HttpContext.Current.Items[_clientContextName];
}

That would avoid the overhead (however slight it may be) for those that don't need it. SetClientContext would be modified similiarly, of course.

RockfordLhotka replied on Friday, May 26, 2006

If you look further you'll see that the call to GetClientContext is wrapped within the ClientContext property - and that property is locked in its entirety (it has to be because it potentially does 2 different operations with the value).

The Get/SetClientContext methods are only called by the data portal, or by the ClientContext property.

So I think you are right - I can optimize the Get/Set methods, which would be highly beneficial on the server - but won't actually impact client usage at all.

Thanks for that! Rocky

xal replied on Friday, May 26, 2006

Rocky,
I recall you once agreed to integrating the possibility for the dataportal fetch method to be more "GenericType Aware". Mainly because of the cases where you have things to fetch that don't really need criteria.

I was hoping you could integrate that to 2.0.1. The changes would be fairly simple and they wouldn't break any existing code... It would look similar to this:

Public Function Fetch(Of T)(ByVal criteria As Object) As T
    Return DirectCast(Fetch(criteria, GetType(T)), T)
End Function

Public Function Fetch(ByVal criteria As Object) As Object
    Return Fetch(criteria, MethodCaller.GetObjectType(criteria))
End Function

   'this doesn't really need to be public,
   'but making it protected might help those who extend the dataportal (like AO!)
Protected Function Fetch(ByVal criteria As Object, ByVal t As Type) As Object

...
    Dim method As MethodInfo = _
      MethodCaller.GetMethod( _
        t, "DataPortal_Fetch", criteria) 'Note that I'm using t here as a param!

....

Would you please please please integrate that to 2.0.1?

Andrés

xal replied on Friday, May 26, 2006

Ok, maybe it involves a little more than that...

Public Function Fetch( _
ByVal criteria As Object, _
ByVal context As Server.DataPortalContext)

Which exists in Server.DataPortal and implements IDataPortalServer does the same assumption about the criteria.

So, I figure that one way of solving this is adding an overload to IDataPortalServer that accepts type.
This still doesn't break existing code, but it's not as simple as 4 lines of code anymore.
I'm working on it, do you think that you might integrate it if I send you a patch?

Andrés

RockfordLhotka replied on Friday, May 26, 2006

You are right, it is a bit more complex than 4 lines of code, because it means changing the whole flow of the type through the data portal.

I may do this for next next release, but not for 2.0.1. If I keep adding stuff to 2.0.1 it will never come out, and there are a couple key changes in there that are required for some of the upcoming code generation templates. I don't want to delay other people's work by indefinitely delaying 2.0.1.

Changing the Fetch behavior isn't terribly hard. It is merely a matter of making it mirror the Create behavior - and then possibly refactoring the solution to combine any overlapping behaviors between Create and Fetch. However, it does mean touching several of the data portal classes from client through to server to provide the complete flow - and that means relatively complex testing due to the various proxy/host combinations as well as local vs remote in general.

Rocky

DansDreams replied on Friday, May 26, 2006

I downloaded the update and tried to rebuild the ProjectTracker solution.

I am getting an error "could not create type 'PTService'" which takes me here when I double-click:

<%@ WebService Language="C#" CodeBehind="~/App_Code/PTService.cs" Class="PTService" %>

Building just the web service project I get "Error 1 Cannot convert type 'ProjectTracker.Library.ProjectInfo' to 'ProjectInfo'"

When I open the ProjectInfo.cs in that PTWebService\App_Code folder I note it does not have a namespace. The one in the ProjectTracker.Library does.

Did the previous version not include a namespace? (I don't see that in the change log.)

Would you expect to have to manually replace those App_Code files?

RockfordLhotka replied on Friday, May 26, 2006

Hmm. At a late point in writing the book I renamed all the ___Info classes to ___Data inside the PTService project - specifically to avoid using the same names as the classes in ProjectTracker.Library (because it was way to confusing in the prose of Chapter 11 to have the same class names for both purposes).

Perhaps something has gotten messed up in the code in cvs so it doesn't reflect the correct naming - I'll have to look at this.

Rocky

From: DansDreams [mailto:cslanet@lhotka.net]

I downloaded the update and tried to rebuild the ProjectTracker solution.

I am getting an error "could not create type 'PTService'" which takes me here when I double-click:

<%@ WebService Language="C#" CodeBehind="~/App_Code/PTService.cs" Class="PTService" %>

Building just the web service project I get "Error 1 Cannot convert type 'ProjectTracker.Library.ProjectInfo' to 'ProjectInfo'"

When I open the ProjectInfo.cs in that PTWebService\App_Code folder I note it does not have a namespace. The one in the ProjectTracker.Library does.

Did the previous version not include a namespace? (I don't see that in the change log.)

Would you expect to have to manually replace those App_Code files?

RockfordLhotka replied on Friday, May 26, 2006

Dan, is it possible that you have some old files in your App_Code directory? If you just unzipped over that directory, and had some pre-RTM code there somehow, you might still have the ProjectInfo.cs file - which is no longer valid. The only files in App_Code should be the ones listed in cvs (http://www.lhotka.net/cslacvs/viewcvs.cgi/ProjectTracker20cs/www/PTWebService/App_Code/).

Rocky

DansDreams replied on Friday, May 26, 2006

Yes, I did (unzip and have some old files). :) Cleaning that up seems to have fixed it.

My "real" app that has a couple of CslaDataSources on a web form I'm playing with is still working fine.

xal replied on Friday, May 26, 2006

Rocky,
I've implemented these changes and I've tested them succesfully in local mode and with remoting.
I'm sure more testing is required but at least it's a step forward. Maybe it'll be in for 1.0.2 ?

I attached a diff file with the changes. (BTW, the forum won't let you attach files with the diff ext. I had to rename it to txt)

Andrés

tymberwyld replied on Tuesday, August 08, 2006

Can someone please explain this to me? I'm having trouble grasping when the "ExecutionLocation" would actually be "Client" vs "Server". Isn't the ApplicationContext only residing on the Client? I don't recall the ApplicationContext being passed between layers, but then again I haven't had a chance to memorize your book yet Stick out tongue [:P]

.

internal static HybridDictionary GetClientContext()
{
   if (HttpContext.Current == null)
   {
      if (ApplicationContext.ExecutionLocation == ExecutionLocations.Client)
      {
         lock (_syncClientContext)
         {
            return (HybridDictionary)AppDomain.CurrentDomain.GetData(_clientContextName);
         }
      }
      else
      {
         LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_clientContextName);
         return (HybridDictionary)Thread.GetData(slot);
      }
   }
   else
      return (HybridDictionary) HttpContext.Current.Items[_clientContextName];
}

RockfordLhotka replied on Tuesday, August 08, 2006

ExecutionLocation is discussed in Chapter 4, and it is managed by the data portal itself so it doesn't need to be passed across the network. In general terms, the data portal knows where it is running and is able to set the location value accordingly.

Rocky

Can someone please explain this to me? I'm having trouble grasping when the "ExecutionLocation" would actually be "Client" vs "Server". Isn't the ApplicationContext only residing on the Client? I don't recall the ApplicationContext being passed between layers, but then again I haven't had a chance to memorize your book yet " src="/emoticons/emotion-4.gif">.