DerivedTableDefinition / IDynamicRelation could not be found

Posts   
 
    
sekorev
User
Posts: 11
Joined: 16-May-2008
# Posted on: 09-Jun-2008 18:46:53   

Hello,

I have compiled my existing v2.5. llblgen project using v.2.6. And now the project gives


C:\Projects\Codes-devexpress-llblgen\lightbll\RelationClasses\DynamicRelation.cs(24,33): error CS0246: The type or namespace name 'DynamicRelationBase' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1820,32): error CS0246: The type or namespace name 'ElementCreatorBase' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1820,52): error CS0246: The type or namespace name 'IElementCreator' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\RelationClasses\DynamicRelation.cs(30,26): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\RelationClasses\DynamicRelation.cs(42,26): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\RelationClasses\DynamicRelation.cs(42,81): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\RelationClasses\DynamicRelation.cs(53,26): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1856,58): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1856,19): error CS0246: The type or namespace name 'IDynamicRelation' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1867,58): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1867,113): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1867,19): error CS0246: The type or namespace name 'IDynamicRelation' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1879,58): error CS0246: The type or namespace name 'DerivedTableDefinition' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1879,19): error CS0246: The type or namespace name 'IDynamicRelation' could not be found (are you missing a using directive or an assembly reference?)
C:\Projects\Codes-devexpress-llblgen\lightbll\FactoryClasses\EntityFactories.cs(1892,19): error CS0246: The type or namespace name 'IDynamicRelation' could not be found (are you missing a using directive or an assembly reference?)


i have both v2.5 and v2.6 installed on my computer, i checked the "v2.6 beta feedback" forum but i could not find any related topic. What mistake have i done?

Thanks in advance

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 09-Jun-2008 19:03:22   

Please click the 'show all files' in VS.NET's solution explorer and go to 'RelationClasses' and add the 'DynamicRelation.cs' file which is there.

You likely have switched off CleanUpVsNetProject in the project properties of the llblgen pro project so new files aren't added automatically. Switching this on will fix it as well (and regenerate of course)

Frans Bouma | Lead developer LLBLGen Pro
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Jun-2008 08:20:26   

Otis wrote:

Please click the 'show all files' in VS.NET's solution explorer and go to 'RelationClasses' and add the 'DynamicRelation.cs' file which is there.

You likely have switched off CleanUpVsNetProject in the project properties of the llblgen pro project so new files aren't added automatically. Switching this on will fix it as well (and regenerate of course)

I have exactly the same issue and have CleanUpVsNetProject switched on. Also the file DynamicRelation.cs was correctly added to the project under RelationClasses. If you look at the errors of sekorev, you'll see he also has DynamicRelation.cs correctly added to the project as it also gives a compiler error on that file (and thus it is being compiled).

The real error is that when generating code, the references are not updated. So the project still has references to 2.5 libraries and not to the updated 2.6 libraries. Also it misses the reference to the LinqSupportClasses library. When manually changing the references to the correct assemblies, it compiles correctly.

sekorev
User
Posts: 11
Joined: 16-May-2008
# Posted on: 10-Jun-2008 08:58:13   

Hi to all,

PatrickD is totally right about the assembly thing. after uninstalling v 2.5 and then regenerating with v 2.6 solves the problem.

thanks all

PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Jun-2008 09:01:51   

sekorev wrote:

Hi to all,

PatrickD is totally right about the assembly thing. after uninstalling v 2.5 and then regenerating with v 2.6 solves the problem.

thanks all

So it seems to be a side-by-side thing. I am not in the luxurious position of discarding 2.5, so I hope this can be fixed.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 10-Jun-2008 09:25:11   

Thanks Patrick for this analysis, you're totally right!

Unfortunately, these references can't be updated by the code generator. The thing is that references always should be changed by the user, because we don't know where the assemblies are located. For example, if the app has a local folder 'Libs' where the assemblies are located and should be referenced from, the code generator doesn't know this.

I'll add a note to the documentation's migrating your code so this is noticed by upgraders.

So to all who run into this same issue and this is the first time you upgrade an LLBLGen Pro version: you've to manually update the references to the runtime libs to the new v2.6 versions, as these aren't updated.

Patrick, you don't have to drop v2.5: once you've manually changed the references in an upgraded project, they'll stay that way. New code is also automatically using v2.6's references.

Frans Bouma | Lead developer LLBLGen Pro
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Jun-2008 09:33:29   

Otis wrote:

Thanks Patrick for this analysis, you're totally right!

Unfortunately, these references can't be updated by the code generator. The thing is that references always should be changed by the user, because we don't know where the assemblies are located. For example, if the app has a local folder 'Libs' where the assemblies are located and should be referenced from, the code generator doesn't know this.

I'll add a note to the documentation's migrating your code so this is noticed by upgraders.

So to all who run into this same issue and this is the first time you upgrade an LLBLGen Pro version: you've to manually update the references to the runtime libs to the new v2.6 versions, as these aren't updated.

Patrick, you don't have to drop v2.5: once you've manually changed the references in an upgraded project, they'll stay that way. New code is also automatically using v2.6's references.

I do not understand. The LLBLGen pro assemblies are referenced from path C:\Program Files\Solutions Design\LLBLGen Pro v2.6\RuntimeLibraries\DotNet20 and not from a user defined folder. On top of that, when uninstalling 2.5 the generator knows where to get the new libraries from, so why would it not know when 2.5 is still installed? I understand that the generator can not update references of user created assemblies that make use of the generated DAL. But references of the generated DAL project (which is completely generated by LLBLGen) could be updated IMHO.

BTW, I can not recall that I had this issue when migrating from 2.0 to 2.5. I only had to update the references of my 'own' assemblies, not of the DAL.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 10-Jun-2008 09:55:41   

PatrickD wrote:

Otis wrote:

Thanks Patrick for this analysis, you're totally right!

Unfortunately, these references can't be updated by the code generator. The thing is that references always should be changed by the user, because we don't know where the assemblies are located. For example, if the app has a local folder 'Libs' where the assemblies are located and should be referenced from, the code generator doesn't know this.

I'll add a note to the documentation's migrating your code so this is noticed by upgraders.

So to all who run into this same issue and this is the first time you upgrade an LLBLGen Pro version: you've to manually update the references to the runtime libs to the new v2.6 versions, as these aren't updated.

Patrick, you don't have to drop v2.5: once you've manually changed the references in an upgraded project, they'll stay that way. New code is also automatically using v2.6's references.

I do not understand. The LLBLGen pro assemblies are referenced from path C:\Program Files\Solutions Design\LLBLGen Pro v2.6\RuntimeLibraries\DotNet20 and not from a user defined folder.

That's the initial situation, but many people have a separate folder in the application where they place the assemblies to reference and reference the assemblies in the various projects from there.

It's also not a given that llblgen pro is installed in that folder, the installer allows you to install the designer anywhere you like.

On top of that, when uninstalling 2.5 the generator knows where to get the new libraries from, so why would it not know when 2.5 is still installed?

That's what it looks like, but the generator doesn't set references at all. simple_smile . What it does is this: - in NEW projects, so there's no cs/vbproj file, it uses the cs/vbproj template and generates hintpaths. These hint paths are obtained from the registry, from the same key as where vs.net looks for hint paths for the 'add reference' dialog (which isn't populated from teh GAC as some might think). - in EXISTING projects, so there is a cs/vbproj file, it doesn't do anything.

You then load the cs/vbproj file into vs.net and vs.net is going to check whether it can resolve the references. If you have a reference to a 2.5 assembly and it's not there, vs.net will check if it can find a file with the same filename in the folders specified in the registry key for the assemblies (the keys which are also used to populate the 'add reference dialog'.) If you have v2.0 installed, it will change the reference to v2.0! If you have v2.6 installed, it will change the reference to v2.6's.

That's what happens.

I understand that the generator can not update references of user created assemblies that make use of the generated DAL. But references of the generated DAL project (which is completely generated by LLBLGen) could be updated IMHO.

The pattern to match the reference with in the project file XML is already unclear: what if the user has build his own ormsupportclasses dll?

BTW, I can not recall that I had this issue when migrating from 2.0 to 2.5. I only had to update the references of my 'own' assemblies, not of the DAL.

I think this is because initially in v2.0, the references weren't set as 'specific version==true'. This means that when you upgraded, vs.net simply would pick the latest version. However NOT having specific version == true, would give problems in NEW projects because when generating a new project could lead to a project referencing older versions as well (as vs.net picked the first filename it found, yes it's a bit of a mess these references in vs.net).

However, projects now have <specificversion>true</specificversion> on the reference, so when you upgrade, this reference will stick to the version it is set to.

We overlooked this in the migrating your code section, as it's the first time this occurs.

Frans Bouma | Lead developer LLBLGen Pro
PatrickD
User
Posts: 65
Joined: 05-Sep-2006
# Posted on: 10-Jun-2008 10:02:36   

OK, now I understand. Thanks for the explanation.