SpecificVersion false 导致编译错误
我有一个使用 Oracle ODP.NET 的非常大的项目。现在它是针对版本 10.1.0.401 构建的(目前这是一个相当旧的版本)。这在我的开发机器和构建机器上都有效。生成计算机未安装 Visual Studio,而是直接针对解决方案文件使用 MSBuild。
我正在尝试在我的开发计算机上安装新版本的 ODP。但是,我不想影响其他开发人员或构建机器。我希望允许人们在不同的时间升级版本,并且在我们的网络服务器升级之前我无法升级构建机器(企业环境 - 这将需要几个月的时间)。
现在,在源代码管理中,*.csproj 文件中的 Oracle.DataAccess 引用如下所示:
<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342" />
因此 SpecificVersion 设置为 true,并且 10.1.0.401 位于构建计算机上的 GAC 中。这构建得很好。所以我想我只需将 SpecificVersion 的引用更改为 false,然后提交即可。在我的计算机上,引用将解析为新版本,而在构建计算机上,它将继续解析为 10.1.0.401。因此,我对文件进行了如下所示的更改:
<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342">
<SpecificVersion>False</SpecificVersion>
</Reference>
不知何故,这会导致生成服务器上的 MSBuild 执行出现编译失败。错误是:
"C:\path\to\MySolution.sln" (Rebuild target) (1) ->
"C:\path\to\my\project.csproj" (Rebuild target) (2) ->
(CoreCompile target) ->
My\ClassFile.cs(241,67): error CS1061: 'Oracle.DataAccess.Client.OracleConnection' does not contain a definition for 'EnlistDistributedTransaction' and no extension method 'EnlistDistributedTransaction' accepting a first argument of type 'Oracle.DataAccess.Client.OracleConnection' could be found (are you missing a using directive or an assembly reference?) [C:\path\to\my\project.csproj]
如果根本找不到 Oracle.DataAccess 对我来说是有意义的,但是我如何得到有关缺少 API 的编译错误?请注意,该 API 存在于 ODP 10.1.0.401 中,因此据我所知,这不是一个合法错误。
更新:
这在某种程度上与 GAC 中的 DLL 有关。如果我在本地有 DLL 并更改引用,使其包含该本地文件的 HintPath,那么编译就可以正常。将 SpecificVersion = False 与 GACed 程序集结合起来是否不合适?
I have a very large project that uses Oracle ODP.NET. Right now it is building against version 10.1.0.401 (which is a pretty old version at this point). This is working on my dev machine as well as the build machine. The build machine does not have Visual Studio installed but rather uses MSBuild directly against the solution file.
I'm trying to install a new version of ODP on my developer machine. However, I don't want to impact other developers, or the build machine. I want to allow people to upgrade versions at different times, and I can't upgrade the build machine until our web servers are upgraded (corporate environment - this will take months).
Right now, in source control, the Oracle.DataAccess reference in the *.csproj file looks like this:
<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342" />
So SpecificVersion is set to true, and 10.1.0.401 is in the GAC on the build machine. This builds fine. So I figure that I'll just change the reference to SpecificVersion false, and commit it. On my machine, the reference will resolve to the new version, and on the build machine it will continue to resolve to 10.1.0.401. So I commit a change to the file that looks like this:
<Reference Include="Oracle.DataAccess, Version=10.1.0.401, Culture=neutral, PublicKeyToken=89b483f429c47342">
<SpecificVersion>False</SpecificVersion>
</Reference>
Somehow, this causes the MSBuild execution on the build server to have a compilation failure. The error is:
"C:\path\to\MySolution.sln" (Rebuild target) (1) ->
"C:\path\to\my\project.csproj" (Rebuild target) (2) ->
(CoreCompile target) ->
My\ClassFile.cs(241,67): error CS1061: 'Oracle.DataAccess.Client.OracleConnection' does not contain a definition for 'EnlistDistributedTransaction' and no extension method 'EnlistDistributedTransaction' accepting a first argument of type 'Oracle.DataAccess.Client.OracleConnection' could be found (are you missing a using directive or an assembly reference?) [C:\path\to\my\project.csproj]
It would make sense to me if it couldn't find Oracle.DataAccess at all, but how am I getting a compilation error about a missing API? Note that that API is present in ODP 10.1.0.401 so it is not a legitimate error from what I can tell.
Update:
This is somehow related to the DLL being in the GAC. If I have the DLL locally and change the reference so it includes a HintPath to that local file, then the thing compiles fine. Is it not appropriate to combine SpecificVersion = False with GACed assemblies?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我也在使用这个组件。我们从项目目录树内的“Assemblies”文件夹中引用此程序集,具体版本 = false。
它之所以有效,是因为所有团队成员的计算机上都安装了相同的版本。在构建服务器上存在不同的情况。我不记得为什么,但我必须将程序集绑定重定向添加到 Oracle 程序集的 machine.config 中,以使我的构建在 64 位构建服务器上运行。
这可能是由新的 ODP.NET 引起的,其中两个 Oracle.DataAccess 程序集安装到了 GAC 中。第一个用于版本 4.xx 的 .NET 4.0,第二个用于版本 2.111.xx。我使用 MSBuild 4.0 (TFS2010) 编译源代码(我们的项目针对 .NET3.5),它总是尝试从 GAC 加载 4.xx 版本而不是 2.xx 版本。
我通过更新 machine.config 文件之一解决了这个问题:
抱歉,我不太记得构建服务器上的 Oracle 问题,但是这个程序集重定向很有帮助。
I'm also using this assembly. We are referencing this assembly from the "Assemblies" folder inside project directory tree with specific version = false.
It is working because all team members has the same version installed on their machines. On the build server there was the different situation. I don't remember why but I had to add assembly binding redirect into the machine.config for Oracle assemby to get my builds working on 64bit build server.
It was probably caused by new ODP.NET where two Oracle.DataAccess assemblies were installed into the GAC. One for the .NET 4.0 with version 4.xx and 2nd with version 2.111.xx. I compiled my sources using MSBuild 4.0 (TFS2010) (our projects are targetting .NET3.5) and it always tried to load 4.xx version instead of 2.xx version from the GAC.
I solved it by updating of one of the machine.config files:
Sorry, I don't remember exactly my Oracle issue on the build server, but this assembly redirect was helpful.