Hi,

I have sucessfully migrated my .NET1.1 code to LLBLGen 2.0.0 and everything works fine.

Now I am trying to migrate from .NET1.1 to .NET2.0

I have already

• converted my application to VS2005

• Updated all the references so that I am now using the SD.LLBLGen.Pro.ORMSupportClasses.NET20 library as opposed to SD.LLBLGen.Pro.ORMSupportClasses.NET11

• Deleted completely the DBSepcific and DBGeneric projects and regenrated them using the General preset (with PredicateFactory and SortClauseFactory enabled) for VS2005/NET2.0

• I have also regenerated my BusinessObjects library (which is based loosely on the Manager classes available on SVN)

Now when I compile the code I hundreds of the following error types:

C:\Data\NET2Final\SABER6\SABER.Engine\BusinessObjects\ManagerBaseClasses\L3UserManagerBase.cs(93,34): error CS0029: Cannot implicitly convert type 'SABER.Engine.HelperClasses.EntityCollection<SABER.Engine.EntityClasses.CubeActivityUserEntity>' to 'SABER.Engine.HelperClasses.EntityCollection'

This is as a result of the ManagerBaseClasses for each entity. The code in this case that is causing the problem is

    public static EntityCollection FetchCubeActivityUserCollection( L3UserEntity l3User, IDataAccessAdapter adapter )
        {
            EntityCollection collection = l3User.CubeActivityUser;
            return FetchCollection( collection, l3User.GetRelationInfoCubeActivityUser(), 0, defaultSorter, adapter );
        }       

and in particular the line

EntityCollection collection = l3User.CubeActivityUser;

I assume that this has something to go with "generics" however I have not got my head around what that means yet, so I was hoping that it was not going to be a problem becase the user guide states

.NET 2.0 specific: generics LLBLGen Pro v2.0 supports both .NET 1.x and .NET 2.0. For .NET 2.0, there is both the non-generic EntityCollection class, as known from the generated code for .NET 1.x, and a generic EntityCollection class: EntityCollection(Of TEntity), where TEntity is a class which both implements IEntity2 and derives (indirectly) from EntityBase2, the base class of all adapter Entity classes. The non-generic variant is used for backwards compatibility. The entities themselves use the generic variant, so CustomerEntity.Orders will be of type EntityCollection(Of OrderEntity). In this documentation, the VB.NET way of specifying generics is used, to simplify typing the documentation and to avoid needing to formulate everything twice, plus it's more describing of what it means. So for the people who are unfamiliar with the VB.NET way of defining generics: EntityCollection<B> == EntityCollection(Of B).

and so I was hoping to use the non-generic variant.

Is there an easy fix to this code that will get it working again... I can then fix the template and all these errors will disappear (I hope)

Many thanks

Huw

change EntityCollection into IEntityCollection in that line.

Also, there are manager templates available now for .NET 2.0 and v2.0, perhaps these will make life more easier for you Check the customer area v2.0's 3rd party section.

Thanks,

The new manager classes REALLY helped!!!

I have now nearly fixed everything but I just the answer to a simple question on Nullable Types:

In my code (to be fixed) I make some use of the fact that LLBL generated code for NET1.1 set a default value for nullable fields. Iam now obviously getting many cast errors because this is no longer allowed.

Therefore the code

if (myDeal.L2UseWFactor && myDeal.L3IsForecast)
                        {
                            myDeal.L2Weighting = myDeal.L3Weighting * myDeal.L2WFactor;
                        }

causes an error because myDeal.L2UseWFactor and myDeal.L3IsForecast are now type bool? not bool

Am I correct in saying that if I adjust the code thus:

if (myDeal.L2UseWFactor.GetValueOrDefault() && myDeal.L3IsForecast.GetValueOrDefault())
                        {
                            myDeal.L2Weighting = myDeal.L3Weighting * myDeal.L2WFactor;
                        }

then I should get the same result as I did before?

Furthermore, I assume that using SetNewFieldValue to set a field to null is no longer necessary and also TestCurrentFieldValueForNull is also no longer required..... are these going to be made obsolete or can I leave the code alone?

Many thanks as always

then I should get the same result as I did before?

Yes I guess.

Furthermore, I assume that using SetNewFieldValue to set a field to null is no longer necessary and also TestCurrentFieldValueForNull is also no longer required..... are these going to be made obsolete or can I leave the code alone?

Please refer to: Entities, NULL values and defaults in the manual: "using the generated code -> SelfServicing/Adapter -> Using the entity classes"