Jak powiedziałeś, to tylko ostrzeżenie. Ponieważ ODP.net nie jest „AnyCPU”, ostrzeżenie wskazuje, że masz zależność, która nie dostosuje się do systemu operacyjnego hosta, tak jak twoja własna aplikacja. Tak długo, jak twoja instalacja odp.net pasuje do systemu operacyjnego pod względem bitów, wszystko będzie dobrze. Ale kompilator nie jest w stanie podjąć takiej decyzji i próbuje cię uprzedzić.
Znalazłem artykuł o połączeniu w tym, co obejmuje możliwą zmianę (zakładam, że plik proj), aby wyłączyć błąd:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
W każdym razie aplikacja „AnyCPU” będzie działać poprawnie na serwerze, o ile 32-bitowy odp.net, który instalujesz na serwerze, jest tej samej wersji, co 64-bitowy odp.net, do którego się odwołujesz (lub zasady wydawcy są poprawnie zainstalowane przekierowanie do nowszej wersji). Aby wyeliminować wszelkie nieporozumienia, zwykle ustawiam „Kopiuj lokalnie” w odniesieniu do „fałsz”. Innymi słowy, kompiluję z konkretną wersją biblioteki dll, ale pozwalam jej działać zgodnie z tym, co rozwiązuje z GAC (co obejmuje zasady wydawcy, które zawiera większość instalacji odp.net).
Możesz także zainstalować 32-bitowy plik odp.net na swoim komputerze deweloperskim (najlepiej ponownie tę samą wersję), aby uruchamiać/debugować aplikacje 32-bitowe lub korzystać ze zintegrowanych narzędzi dostarczanych „z Oracle Developer Tools for Visual Studio” wewnątrz programu Visual Studio.
Wszystko to powiedziawszy, jest tu więcej niż na pierwszy rzut oka. Jeśli Twoja aplikacja faktycznie działa (co oznacza "to tylko ostrzeżenie") jako 64-bitowa, to NIE używa ona 32-bitowej instalacji. Przypuszczam, że twój komputer ma już zainstalowaną wersję 64-bitową (wiele domów Oracle).
