Upgrading Project file from old CslaGen to CslaGenFork

May 1, 2012 at 4:17 PM

Hi Tiago,

 

I was considering seeing if I can somewhat update the VB templates, but my ultimate goal in doing so was to bring a project that I had using the old CSLAGen into CslaGenFork and upgrading it to generate CSLA 4.0 objects.  I was able to open the project file within CslaGenFork and it can generate 2.0 and 3.5 ojects, but when I change to 4.0, I'm getting validation errors from many of my objects:

Object <objectName> Value Property <propertyname>: DB Bind Column not found

Now many of the objects I created back then were created from existing stored procedures and not directly from the database tables.  Is there an easy way to rectify this problem, other than to rebind each property (within over 500 objects)?

Thanks,

Mike

Coordinator
May 2, 2012 at 9:32 PM
Edited May 2, 2012 at 9:35 PM

Hi Mike,

There is no easy way to change your project from using stored procedures data sources to table data sources. This is on the to do list. On the othe rhand, one of the problems is that I have no samples to test the template corrections.

You mention validation errors but I know that in some places the SP data sources will crash the code generator or will be ignored altogether.

Whta I have to propose is for you to send me:

  • project file
  • database schema

So I can have a look and start changing things around. At this point I can't quantify the amount of work need to fix this issue.

Regards,

Tiago Freitas Leal

<edit>

By the way, in a first moment I can't compromise of fixing anything but the encapsulated implementation model (plain old CslaGen generation mode).

</edit>

May 3, 2012 at 9:02 PM

Hi Tiago,

So here's some more info.  My original project file that I was trying to pull into cslagenfork was very old, which I think was missing a lot of new tags.  So what I did was I pulled that into an original CslaGen build from 1/12/2010 and saved the project file.  I then pulled that updated file into cslagenfork and a number of the bind column issues went away.  I think some tags for the binding were changed from the original into the more recent build that your version recognizes.

That being said I still had some issues. First, before I wasn't using namespaces in any of my objects so they were all left blank, which appears to be ok in targets 2.0 and 3.5, but 4.0 required a base namespace, a utility namespace, and object namespaces. I would think that if all of them were left blank, then couldn't it just not generate any namespaces like the old version?  Anyway, that was a minor thing, as I was able to do a find and replace of the xml file to create the object name spaces.

So now the issue is with my read-only collection object that was originally generated from an existing stored procedure. When I generate it, it said:

Criteria <collection name>.Criteria: property <parameter name> is missing DB Bind Column. 

However, that property is actually just a parameter used by the stored procedure and doesn't actually bind to any particular column.  I would think that it shouldn't be a requirement for the criteria properties to be bound to a DB column just for that reason.

Can you let me know your email address and I will email you a sample project that includes an object that is bound to a table and then another that is bound to a stored procedure.  I will also include a script file to build the sample DB.

Finally, in regards to the vb templating stuff, I have a question. In your code there is a templates folder that contains a vbCslaTemplateHelper class that appears to be already set up to output VB code, and then you have another folder called CodeGen folder with a CslaTemplateHelperVB class that is essentially empty.  I noticed in looking at the editableroot.cst file that there is a refererence the C# CodeGen folder version - CslaTemplateHelperCS, and not the class in the templates folder.  Does this mean that code needs to be written for the Vb class in the CodeGen folder, or is something out of whack in the template file and it should be pointing to the VB class in the Templates folder? 

Thanks,

Mike


Coordinator
May 4, 2012 at 11:13 PM

Hi Mike,

1) Namespaces

CSLA40 templates assume there is a name space. Presuming you are using the same namespace for all classes, you didn't need to find/replace the XML file:

[TIP]

  1. Select all objects and only the common properties show up in Csla Object Info
  2. Change the Object Namespace property and it will be changed for all selected objects

2) Views and Sprocs as source for ReadOnly objects

This is something that must be corrected. Email address sent to your codeplex contact.

3) Two generations of template helpers and VB templates

The classes in the Templates folder are the old ones, used by targets CSLA20 to CSLA35. At some point, keep CSLA40 new features compatible with old versions was completely impossible. Refactoring took the form of an interface implemented by both the old classes (Templates folder) and by the new classes (CodeGen folder). The old classes were restored exactly as Andreas left them on CslaGen and the new ones support a lot of features, most of them I can't remember exactly (must read all the release notes) but DAL support is the most important for sure. This way CslaGenFork is as compatible as it can with old versions and we are free to implement all the new features we want and don't care a bit about backwards compatibility.

Bill Larman suggested he could write the VB templates but he would rather do them in C#, VBfying only the output. He argued that it was easier to port new features and template changes this way. If one is at ease with both languages, this might be a smart and easier approach. I guess he could find the time to do it. On the other hand, CslaGenFork changed at a very fast rate and keeping pace with this fast changing isn't easy. Furthermore, the VB support class is empty. So whoever grabs the VB flag must start by writing this class, taking the C# counter part as a model.

Having no VB templates, I was left with two options:

  • block VB generation altogether
  • faking VB generation

The fact that you ask for VB and are served with C# doesn't matter as there is an alert concerning the "no VB" issue at the topo of the CslaGenFork home page. Keeping the VB generation enabled and active is a statement saying I feel this is a missing feature (and a very important one).

I wonder whether you are willing to take charge of writing the VB templates.

 

Regards,

Tiago Freitas Leal

 

Coordinator
May 13, 2012 at 9:56 PM

Mike,

I've sent corrections to you. Please report results here so others can follow this issue.

Tiago Freitas Leal

May 17, 2012 at 6:27 PM

Hi Tiago,

1. That corrected template file did fix that error and made it a warning, but then another error had popped up in it's place. I found the issue, and fixed it in the copy of the code I am playing with.  In the GetCommand function of the CslaTemplateHelperCS.cs file is a check:  

if (info.Parent.GenerationParams.GenerateQueriesWithSchema)

which I changed to:

if (info.Parent.GenerationParams.GenerateQueriesWithSchema && tables.Count > 0)

Because the stored procedures didn't have any tables in that collection, it was throwing a null reference exception when trying to prepend the object schema to the name (If you had the Use Schema On Queries option checked)

 

2. I've actually been working on the VB templates, at least enough to assist me with the project I'm working on.  At this point I've converted the CslaTemplateHelperVB.cs file, EditableRoot, ReadOnlyCollection and ReadOnly objects.  I hope to try to get to them all, but at this point due to my workload I'm only working on the ones that directly impact me getting my project done, but at least it will be a starting point for someone to take over if I can't get to them all.

3. It doesn't look like there is a UseSingleCriteria toggling option from within the UI, so I had to change it in the underlying xml of the project file.  Is it truly missing or did I just miss where that option is available in the UI

4. There is an option to "Use String with TypeConversion to DateTime or SmartDate for date properties" in the UI, but it appears to only function if you select it before adding any of your value properties.  So my existing smart date properties which used to automatically do the type conversion in the old versions, no longer do so, because of the new property Type, DeclarationMode and Backing Field Type combination was not in place within the old project file.  Is there some way to create a routine that when checking the option (or even a new menu item or something) that would go through the existing value properties for all of the objects and change them accordingly for datetimes and smartdates?

Thanks,

Mike

Coordinator
May 26, 2012 at 4:52 PM
mtavares wrote:

3. It doesn't look like there is a UseSingleCriteria toggling option from within the UI, so I had to change it in the underlying xml of the project file.  Is it truly missing or did I just miss where that option is available in the UI

4. There is an option to "Use String with TypeConversion to DateTime or SmartDate for date properties" in the UI, but it appears to only function if you select it before adding any of your value properties.  So my existing smart date properties which used to automatically do the type conversion in the old versions, no longer do so, because of the new property Type, DeclarationMode and Backing Field Type combination was not in place within the old project file.  Is there some way to create a routine that when checking the option (or even a new menu item or something) that would go through the existing value properties for all of the objects and change them accordingly for datetimes and smartdates?

Hi Mike,

UseSingleCriteria

It didn't exist on old CslaGen so it was introduced by CslaGenFork. I can't remember whether there was a UI setting at some time. Anyway sinve Csla 4.0 there is no need to use SingleCriteria provided your criteria parameter is a primitive type. SingleCriteria existed as a serialization helper but changes in Csla rendered it unneeded. Lately I had some requests to force the use of a named criteria when one wants to pass different criteria of the same type, say fecth customers by CellPhoneNumber or by FixedPhoneNumber both being strings. On this scenario, there is no way to tell both use cases apart, except if you provide named criteria (CellPhoneNumberCriteria and FixedPhoneNumberCriteria) both with a single property of string type. My suggestion was to use a single criteria and use CellPhoneNumber and FixedPhoneNumber as string properties of the criteria, passing one of them as null or Empty.

Concerning generator support for UseSingleCriteria, right now it is unssupported and is set to false when you change the TargetFramework to CSLA4 or CSLA4DAL. Since there is no way to set it to true, it is used as a legacy setting.

The point is: are you generating for Csla 4.x.x? Why do you need SingleCriteria?

Use String with TypeConversion to DateTime or SmartDate for date properties

That's right, this setting is in the Creation - General Defaults and as explained on the form "These settings only affect how new objects are created." Your point is that old CslaGen used to generated automatic backing field of string type for SmartDate properties. I can see this is an interesting migration feature nut it must be made active or inactive by a UI setting. As a quick fix, edit BusinessProps.asp and around line 20 where it reads

foreach (ValueProperty prop in Info.AllValueProperties)
{
    if (isUndeletable == false && prop.DbBindColumn != null)
(...)

replace it by

foreach (ValueProperty prop in Info.AllValueProperties)
{
    // always force backing field of SmartDate to string
    if (prop.PropertyType == TypeCodeEx.SmartDate)
        prop.BackingFieldType == TypeCodeEx.String;

    if (isUndeletable == false && prop.DbBindColumn != null)
(...)

I'm adding this feature to the issue tracker.

Regards,

Tiago Freitas Leal

Sep 19, 2013 at 9:34 AM
Is there any progress on the conversion of c# templates to vb?
Coordinator
Sep 19, 2013 at 9:15 PM
No progress. Are you a candidate to the task? I'd appreciate!
Sep 20, 2013 at 7:20 PM
Maybe you can send him the templates that I converted and sent back in April. I never got a chance to finish them 100%, but they do cover Editable Root, Editable Child Collection, Editable Child, Readonly Root, Readonly Collection, Readonly Child for both dataset and data reader loading. They are based on your release from 3/2012 and have not tried them against your RC release.
Sep 21, 2013 at 6:00 AM
First of all Tiago i have to say that i am a big fan of your work. I am astounded by the amount of work you put on the project and your dedication to it. I would be happy to help translate the existing c# templates into VB (and partially test them). I already started doing the work. I first used some internet sites to convert all the files to VB, then i manually audited the files to see if everything was ok. Of course it wasnt and it needs lots of work.

I am currently learning how to detect errors that come up from CSLAGENFORK so i can fix the errors in my files.

this is one of the first files i started working with. Could you guide me to understand my errors so i can follow the same pattern on all the other files? Or at least find the best way to debug them. As soon as i get the hang of it i can fix them all.

ProjectValidate_Business.cst

i will of course send you all the converted files when i manage to get them to work.
Developer
Sep 21, 2013 at 5:54 PM
I have some thoughts on the VB.Net conversion and have started a new discussion: VB.Net Output