EDIT- an updated solution file is included in my following message

We are in the process of upgrading our projects from LL 2.0 --> 3.5. The process has worked very well so far and I've been able to update several projects to the newer version without a recompile. However, I'm having a problem with one method in one of our applications. This method calls a stored procedure and passes the dataAccessAdapter with the call. This seems to be a breaking issue in version 3x.

The structure of our solution for explanation purposes is as follows: presentation layer northwind dl layer (databasespecific) northwind dl layer

The northwind dl layer and databasespecific layer was upgraded to version 3.5. The presentation were left in tact.
The .net version number of the northwind DLLs did are hardcoded and do not change.
An assembly binding reference was added in the app.config of the presentation layer to redirect calls to SD.LLBLGen.Pro.ORMSupportClasses.NET20 v2.0 to SD.LLBLGen.Pro.ORMSupportClasses.NET20 v3.5

The problem: Calls to stored procs that pass in an adapter object are not found by the RetrievalProcedures class, while straight calls to the procedure are found without a problem.

quick illustration DataAccessAdapter adapter = new DataAccessAdapter(); DataTable dt = RetrievalProcedures.TenMostExpensiveProducts(adapter); //not found DataTable dt = RetrievalProcedures.TenMostExpensiveProducts(); //execute no problem

Could anyone tell me how to resolve this issue without recompiling the presentation layer with LL 3x dlls?

I've created a sample solution that references a stored proc on the Northwind database. The presentation project is called "NorthwindConsole" (in the NorthwindSample\NorthwindConsole directory) You can press the exe file to run the stored procedure against the 2.6 framework. There are 3 calls to the "TenMostExpensiveProducts" stored procedure. The first call is a direct call to the stored procedure within the Main method of the console app. The second call is to a method that calls the sp without a passing in the adapter object.
The third call is to a method that calls the sp and passes the adapter object.
All 3 calls execute without a problem against the 2x framework.

How to run the sample

Open NorthwindSample for the 2.6 db projects Open Northwind3.5\Northwind3.5 for the 3.5 db projects

Open NorthwindSample\NorthwindConsole for the console project Drop 2.6 db projects in bin Run You should see 3 outputs and no errors

Now drop the 3.5 DLLs into the bin folder Copy the NorthwindConsole.exe.config file in NorthwindSample\NorthwindConsole\bin\Debug\3.5 into the bin folder.
This will redirect calls to the 2.6 ORM class to the 3.5 ORM class

Run

You should see 2 outputs and 1 error

You will see that a direct call to the sp (even while passing in a DataAccessAdapter) works properly. Also, the call to the sp without passing in the DataAccessAdapter works. But the call to a method that calls the sp, while passing in the DataAccessAdapter fails everytime. The error I get is
Method not found: 'System.Data.DataTable NorthwindSample.DatabaseSpecific.RetrievalProcedures.TenMostExpensiveProducts(NorthwindSample.DatabaseSpecific.DataAccessAdapter)'.

I've also tried editing the RetrievalProcedures.cs file to include a method that contains the following signature "TenMostExpensiveProducts(NorthwindSample.DatabaseSpecific.DataAccessAdapter)", but I get a stackOverflow exception.

The call I attempted to create to do this was public static DataTable TenMostExpensiveProducts(DataAccessAdapter dataAccessProvider) { using (DataAccessAdapter newDa = new DataAccessAdapter()) { return TenMostExpensiveProducts(newDa); } }

Please let me know if there is anything you need from me. I will be checking my email all night as this is a very important wrinkle in our deployment. Thank you in advance.

You have posted your question more than once. I've closed the other thread: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=21116

You can attach a zipped package of your solution, remove any binaries, only code files.

Please ignore the attachment in the first post. The new one is posted here.

How to run the sample

Open NorthwindSample for the 2.6 db projects Open Northwind3.5\Northwind3.5 for the 3.5 db projects

Open NorthwindSample\NorthwindConsole for the console project Drop 2.6 db projects in bin Run You should see 3 outputs and no errors

Now drop the 3.5 DLLs into the bin folder Copy the NorthwindConsole.exe.config file in NorthwindSample\NorthwindConsole\bin\Debug\3.5 into the bin folder. This will redirect calls to the 2.6 ORM class to the 3.5 ORM class

Run

You should see 2 outputs and 1 error

Now for procedure calls the IDataAccessCore is passed, which is used by all templates (adapter, DaoBase). The recommendation is to recompile your GUI. You just have to re-add the references and recompile. Any reason you don't want to do that?

As this is a .Net framework situation where it can't find the right method signature, there is nothing we can do about that. You can't even cast the DataAccessAdapter in your GUI because you don't have the right reference and also because you don't want to compile your GUI. At the end of the day you will have to recompile it, it's part of the migration

Thanks cor the response. We didn't want to rollback and recompile the presentation layer because of the extra testing cycles involved in doing so.

The interesting thing is that the datacessadapter being passed is being casted into an idatacore if the call to the procedure is made directly. But this cast isn't happening when calling a method that calls the procedure. It's like something is being is being lost in the hop.

Compiling the presentation layer with the 3.5 LL dll must affect the way the procedure call is written in the IL code, or there is a bug within the DLL redirect method in the .net framework and compiling the code erases the need for the call to the redirect. I've not analyzed the IL in both conditions (compiling code with LL 2.6 vs 3.5), but Im guessing that it simply negates the need to the redirect.

Is there a way that I can modify the contents of the procedure definition within the retrievals class to accept a datacessadapter in the definition? This is a very attractive path considering there are only 2 offending stored procedures definitions (all other sp calls are made without declaring a dataccessadapter).

Thanks again.

Did you recompile/rebuild as David suggested?

Walaa wrote:

Did you recompile/rebuild as David suggested?

Yes, the application was recompiled this morning. Everything is working well. I was hoping to avoid this path, but everything turned out ok. Thanks for your help.