LinqPad 6 doesn't load my local dll referenced in the script
I reference my local dll in the script. However, the linqpad 6 doesn't load the dll from the folder I specify, instead, it load it from my nuget folder, which is a different version.
For example: in my script, I reference the Microsoft.COmmerce.Model.Contract.dll in folder d:\Code\Git\COST\Catalog\Commerce.Catalog\bin\Debug
In the VS Modules windows, I can see the script is actually loading the dll from my nuget folder. 
My Linqpad version and environment
Comments
This can happen when the DLL that you're referencing (Microsoft.Commerce.Model.Contract.dll in this case) also exists in a NuGet package that you're referencing (or in any of its dependent packages).
When this occurs, LINQPad compares the assemblies' version numbers and uses the assembly with the highest version. This is to minimize the chance of CS1705 and MissingMethodException errors.
LINQPad determines the assembly version number as follows:
If you are able to set your local build's DLL to have a higher version that the DLL in the NuGet package, your local file should win.
P.S. If it helps, the latest beta has a "Show Assembly Resolution Log" button in the Advanced tab of the Query Properties dialog.
Seems it's not the case you mentioned.
I have a project A which generate A.dll and it reference B.dll (V.1.0.0) in the project setting.
In my linqpad6 script, it include both A.dll and B.dll (V1.0.1) locally.
When the script run, it always use the B.dll (V.1.0.0) in my NuGet repository, instead of the v.1.0.1 that I explicitly reference in the script
Try the latest beta (6.15.9):
https://www.linqpad.net/linqpad6.aspx#beta
Go to Query Properties (F4), Advanced, and click 'Show assembly resolution log'. Can you please post or send me the HTML file that it produces.
Thanks for the advice, I have sent out the log in the message box
Microsoft.Commerce.Model.Contract.dll in your local folder (C:\Code\COST\Catalog\Commerce.Catalog\bin\Debug):
AssemblyVersion=2.9.0.0; FileVersion=2.9.2108.43417.
Microsoft.Commerce.Model.Contract.dll in your NuGet folder (packages\Microsoft.Commerce.Model.Contract\2.9.459\lib\netstandard2.0):
AssemblyVersion=2.9.0.0; FileVersion=2.9.2109.14201.
The NuGet version is higher, so it wins. To make the local version win, you need to set its version number higher. Note that I've updated LINQPad in the latest beta so that it compares the FileVersion when the AssemblyVersion is the same, so you don't need to change the AssemblyVersion (which could be a breaking change). Just set the FileVersion to something like 2.9.2110.
Thanks for your update! Could you take a look at dll: Microsoft.Commerce.Ingestion.Converter.BigCat.Contract.dll
In the log, we can see the local one is 3.9.2109.24257, while the nuget one is 2.9.2109.20218. But the script is using the nuget one. Looks like the reason is Microsoft.Commerce.Catalog.deps.json is referencing 2.9.630 (2.9.2109.20218).
Are you certain? According to the log, LINQPad is using Microsoft.Commerce.Ingestion.Converter.BigCat.Contract.dll from C:\Code\COST\Catalog\Commerce.Catalog\bin\Debug.
If you reset your process (Shift+F5) and evaluate
Assembly.Load("Microsoft.Commerce.Ingestion.Converter.BigCat.Contract").Location, what does it display?Interesting... just checked that the same script running in Linqpad 6 is using NuGet dll while running in Linqpad 6 beta is using local dll.
Dll path in Linqpad 6 beta(v6.15.9):
C:\Users\zhijli\AppData\Local\Temp\LINQPad6_clnzjtrc\shadow-1\Microsoft.Commerce.Ingestion.Converter.BigCat.Contract.dll
Dll path in Linqpad 6 (v6.14.10):
C:\Users\zhijli\.nuget\packages\Microsoft.Commerce.Ingestion.Converter.BigCat.Contract\2.9.633\lib\netstandard2.0\Microsoft.Commerce.Ingestion.Converter.BigCat.Contract.dll
Yes - that will be because of the update I just described - the LINQPad beta now compares the FileVersion when the AssemblyVersion is the same.