multiple versions of runtime libraries

Posts   
 
    
wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 16-Nov-2005 11:28:07   

I want to be able to develop some components that can be shared between multiple projects/applications. These components will use LLBLGen (adapter scenario) to interact with the DB. The currenct practice is, that we don't put the libraries in the GAC, but deploy them in the bin folder of the app.

The applications also use LLBLGen. However, some applications use a different version of the runtime libraries, so this can lead to versioning problems when the component uses a different version of the runtime libraries than the application itself.

Are there any best practices that support such a model of development?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 16-Nov-2005 11:47:04   

With different versions you mean, different builds of for example 1.0.2004.2, or do you mean one uses 1.0.2004.2 and the other uses 1.0.2005.1 ? Because if it's the latter you can just place them in the gac and no problems should arise.

Be aware that .NET 1.x has a bit of a problem when you use code in ONE appdomain which references libraries which reference different versions of the SAME assembly.

Frans Bouma | Lead developer LLBLGen Pro
wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 16-Nov-2005 13:02:32   

Otis wrote:

With different versions you mean, different builds of for example 1.0.2004.2, or do you mean one uses 1.0.2004.2 and the other uses 1.0.2005.1 ? Because if it's the latter you can just place them in the gac and no problems should arise.

Both situations can occur.

Be aware that .NET 1.x has a bit of a problem when you use code in ONE appdomain which references libraries which reference different versions of the SAME assembly.

We already encountered versioning problems with other 3rd party components. That is why we are spending now time, to upgrade all components and all applications to a newer version.

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 16-Nov-2005 15:16:22   

As Frans has suggested, puting different versions of the same library in the GAC will solve the problem, as each application will access the version it was meant (built) to access.

Otherwise, for each application, deploy the correct needed version of libraries in its bin folder.

wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 16-Nov-2005 16:01:15   

Walaa wrote:

Otherwise, for each application, deploy the correct needed version of libraries in its bin folder.

That won't work. I think i need to explain the situation further.

Let's say we developped component A with runtime library version 1, and component B with runtime library version 2. Now we start a new project, for a new customer, and we decide we definitely want to use the functionality in LLBLGen version 3. The components are added as file references to the project. Now, the compiler detects dependency conflicts.

Cadmium avatar
Cadmium
User
Posts: 153
Joined: 19-Sep-2003
# Posted on: 17-Nov-2005 00:03:36   

I basically support this by compiling my own version from source and avoiding the GAC altogether. The problem comes with the app itself, since it generates code based on specific builds, you might have to keep mulitple copies of ProGen around to support this.

wvnoort
User
Posts: 96
Joined: 06-Jan-2005
# Posted on: 17-Nov-2005 10:35:09   

Cadmium wrote:

I basically support this by compiling my own version from source and avoiding the GAC altogether. The problem comes with the app itself, since it generates code based on specific builds, you might have to keep mulitple copies of ProGen around to support this.

Do you mean that each time you use a component, you include its source in the solution, and compile it together with the app?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 17-Nov-2005 10:53:25   

Rule of thumb: all code written against 1.0.2004.2 should work with the latest 1.0.2004.2 templates/runtimes. The main reason we release fixes a.s.a.p. and not in roll-ups once or twice a year is to avoid having our customers program around bugs or utilize buggy behavior.

This means that if you have code written against 1.0.2004.2, it should work with 1.0.2004.2, no matter what the version is (it might be required to regenerate the code with the latest templates but that's it). This thus leads to the versioning against 1.0.2004.2 AND 1.0.2005.1. It's perfectly fine to have code working with 1.0.2004.2 together with code working with 1.0.2005.1 in the same app.

Frans Bouma | Lead developer LLBLGen Pro
Cadmium avatar
Cadmium
User
Posts: 153
Joined: 19-Sep-2003
# Posted on: 22-Nov-2005 15:49:04   

wvnoort wrote:

Cadmium wrote:

I basically support this by compiling my own version from source and avoiding the GAC altogether. The problem comes with the app itself, since it generates code based on specific builds, you might have to keep mulitple copies of ProGen around to support this.

Do you mean that each time you use a component, you include its source in the solution, and compile it together with the app?

Not the source for the core libraries, but we keep a separate custom compliled dll in source control for each project. I do compile the generated code each time, mostly do the fluid nature of our workflow (stuff changes a lot).