SpecificVersion false вызывает ошибки компиляции - PullRequest
Новая
       9

SpecificVersion false вызывает ошибки компиляции

3 голосов
/ 15 февраля 2012

У меня очень большой проект, который использует Oracle ODP.NET. Прямо сейчас это сборка против версии 10.1.0.401 (которая на данный момент является довольно старой версией). Это работает как на моей машине разработчика, так и на машине сборки. На сборочном компьютере не установлена ​​Visual Studio, а используется MSBuild непосредственно для файла решения.

Я пытаюсь установить новую версию ODP на моей машине разработчика. Однако я не хочу влиять на других разработчиков или сборочную машину. Я хочу позволить людям обновлять версии в разное время, и я не могу обновить сборочную машину, пока не обновятся наши веб-серверы (корпоративная среда - это займет месяцы).

Прямо сейчас в системе контроля версий ссылка на Oracle.DataAccess в файле * .csproj выглядит следующим образом: 

<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, поэтому, насколько я могу судить, это недопустимая ошибка.

Обновление:
Это как-то связано с тем, что DLL находится в GAC. Если у меня есть локальная DLL-библиотека и я изменил ссылку, чтобы она включала HintPath для этого локального файла, то эта вещь компилируется нормально. Разве не целесообразно комбинировать SpecificVersion = False со сборками GACed?

1 Ответ

3 голосов
/ 16 февраля 2012

Я тоже использую эту сборку.Мы ссылаемся на эту сборку из папки «Сборки» внутри дерева каталогов проекта с определенной версией = false.

<Reference Include="Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\Assemblies\Llblgen\Oracle.DataAccess.dll</HintPath>
</Reference>

Это работает, потому что на всех компьютерах всех участников команды установлена ​​одинаковая версия.На сервере сборки была другая ситуация.Я не помню почему, но мне пришлось добавить перенаправление привязки сборки в machine.config для сборки Oracle, чтобы мои сборки работали на 64-битном сервере сборки.

Вероятно, это было вызвано новой ODP.NET, где в GAC были установлены две сборки Oracle.DataAccess.Один для .NET 4.0 с версией 4.xx и второй с версией 2.111.xx.Я скомпилировал свои исходники, используя MSBuild 4.0 (TFS2010) (наши проекты ориентированы на .NET3.5), и он всегда пытался загрузить версию 4.xx вместо версии 2.xx из GAC.

Я решил это, обновив один из файлов machine.config: 

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89B483F429C47342" culture="neutral" />
        <bindingRedirect oldVersion="2.102.0.0-2.120.0.0" newVersion="2.112.2.0" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>

Извините, я точно не помню проблему с Oracle на сервере сборки, но перенаправление этой сборки былополезно.

...