How do I absorb the dll version difference between development and server environments?
Asked 1 years ago, Updated 1 years ago, 147 viewsThe environment is divided into several dlls, and I would like to replace only the dlls that were fixed, but when I deployed the dlls that I created in the server environment, the following error occurred:
The file or assembly 'Oracle.DataAccess, Version=2.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies could not be read.The specified file could not be found.
I believe that the reason is that there was a difference between the version of Oracle.DataAccess used in the development environment and the version of the server environment.
First of all, I think it would be better to understand the version of the running environment and build the version in the development environment... but I am worried that if the version is no longer provided...
So, I have a question, is it possible to prevent errors during execution even if the version of Oracle.DataAccess is different between the development environment and the execution environment?
I don't think it's acceptable to change the server environment, so I was wondering if the development environment could do something about it.
I've been looking into it for a while, but I don't know how to deal with it, so I can't find a solution.
I would appreciate it if you could provide any information.Thank you for your cooperation.
Server Environment
·Windows Server 2008R2
·IIS7
·ASP.NET.NET Framework 3.5
Development Environment
·Windows 7 Professional (64bit environment)
·Visual Studio 2008 Professional
·IIS Express
·ASP.NET.NET Framework 3.5
3 Answers
Delay binding?
Reference URL:
http://urashita.com/archives/1760#C
http://ufcpp.net/study/csharp/sp4_dynamic.html#late_binding
When working with Excel in WinForms, I tried to support multiple versions of Excel.
I have used delayed bindings.
I think it can be used with ASP.NET.
However, IntelliSence will not work on Visual Studio if the binding is delayed, so
It's a little hard to develop.
I understand that you are using 2.112.3 in your development environment and 2.112.1 in your execution environment. Does the new feature being modified depend on 2.112.3 (Clearly 2.112.1 won't work)?
If not, expand the Browse node for the project in question in Visual Studio's Solution Explorer, select Oracle.DataAccess, and set the "specific version" displayed in the properties grid to False (I think Oracle.DataAccess is True by default).
As the image shows that the PC you have does not have Visual Studio 2008 and Oracle DAC, you should be able to do exactly the same for Oracle.DataAccess on Visual Studio 2015 as shown in the System.Core configuration on Visual Studio 2015.
This is a pattern in which the application being modified matches the old DLL and should not cause any inconvenience to the existing set of applications in the running environment.
If the application being modified depends on 2.112.3, and the existing application group and the application being modified are not located in the same bin folder, try keeping the previous "specific version" True and "copy locally" True
..NET applications check for matches in their bin folder when resolving references to external assemblies, so it may be possible to include (or "copy locally") a different version of the assembly in their bin folder than the one in the GAC.
Even if you shared a bin folder with an existing application, I think you could have changed the search method for external assemblies in config. (I remember it vaguely, and I've never tried it before), so please use probe/probing as the keyword.
There is a function called version redirect, so I think it can work with it.
https://msdn.microsoft.com/ja-jp/library/7wd6ex19(v=vs.110).aspx
If you have any answers or tips
© 2024 OneMinuteCode. All rights reserved.