Log in


   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Management of References in Visual Studio and multiple versions

Pages: 1
LLBLGen Pro Runtime Framework
Management of References in Visual Studio and multiple versions

  Print all messages in this thread  
Poster Message

Camberley, United Kingdom
Joined on:
27-Mar-2006 16:16:06
83 posts
# Posted on: 29-Sep-2009 09:07:58.  
I have a number of ASP.NET VB/Oracle applications that I have created with various versions of LLBLGenPro. In each of the applications I have references to the required LLBLGenPro runtimes, typically: SD.LLBLGen.Pro.ORMSupportClasses.NET20 and SD.LLBLGEN.Pro.DQE.Oracle.NET20 in my case. Then the enivitable happened and I was given a fresh PC. I installed the latest version of LLBLGenPro, but of course now when I open up the older applications the references are broken as I no longer have the older versions installed. "C:\Program Files\Solutions Design\LLBLGen Pro v2.5\RuntimeLibraries\DotNET20" etc.     This "problem" is, of course, exactly the same for the other runtimes I have referenced including: AjaxControlToolkit, Telerik Controls, CrystalDecisions.CrystalReports.Engine, Oracle.DataAccess etc.

I could:

1. Create a "Runtime Libraries" folder in my Visual Studio Solution and copy all of the runtimes I have used to this, so that I've always got a copy of the runtimes even if the original version of the application is no longer installed.

2. If I open an "old" application and find broken references, just update them to point to the runtimes of the latest version.

What do people think is the best practice here? What works best? Any comments gratefully received!


LLBLGenPro v2.6 | Visual Studio 2008 | VB | ASP.NET 3.5 SP1 | Oracle 9.2
Support Team


Joined on:
21-Aug-2005 16:03:48
14639 posts
# Posted on: 29-Sep-2009 11:39:39.  
Per Solution: copy the old RTLs to a folder within the solution.

Better than handling migration issues for multiple projects. (If it ain't broke don't fix it).


London by day, Milton Keynes by night.
Joined on:
08-Oct-2008 17:55:47
1461 posts
# Posted on: 29-Sep-2009 17:39:39.  
I'll second what Walaa has said - and even extend it. All of the libraries that your code references should go into a folder local to the solution, AND this folder should be stored in your source control system.

It should be possible to do a get latest of the top level folder and be able to open the solution in visual studio with all of the references working correctly - without having to have any of you dependencies actually installed on your machine...

This makes setting up new machines/new developers/build machines etc much simpler.

Pages: 1  

Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.