I'm trying to get the oracle bindings for a wcf-custom send port working.
I get this error:
Could not load file or assembly 'Oracle.DataAccess, Version=2.111.7.0
None of the installs on the oracle site seem to have this version. Any suggestions?
That would be version 11g Release 7 (11.1.7). The 2 comes from .Net 2, I believe.
My notes on installing this for 32 bit hosts are (files downloadable from Oracle):
Get Oracle Developer Tools - ODTwithODAC1110621.zip
Take defaults and select all items. Will go to C:\app[yourusername]\product\11.1.0 by default.
Then install Patchset for ODT - p6890831_111070_Win32.zip
During the install select the previous installation folder from the earlier step (C:\app[yourusername]\product\11.1.0).
Select the existing Oracle home! It might not be obvious from the screen that it is a drop down – do not select the folder.
That should give you Oracle.Data.Access 2.111.7.0 x86 in the Global Assembly Cache.
There should be 64bit versions available as well.
timobr is right on if you're trying to connect to Oracle 11g. IF you're trying to connect to 12c, you'll need to update your machine.config bindings to redirect the request for the 11g DLLs to the 12c versions. See Sandro Periera's blog for more details; here's the relevant part to add to machine.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess"
publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="2.111.7.0" newVersion="2.112.1.2" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Note this has to be done for all applicable .NET verions (including both x86 and x64).
Also note that if you're running on a 64-bit host, you'll need the 64-bit drivers - but the admin console is a 32 bit application, and will not work properly without the 32 bit drivers. However, installing both on the same machine is a bit challenging...
I was able to get a workaround to operate but it's not ideal. I noted the 'add generated items' wizard was able to connect to oracle. The code to do this is in visual studio and is 32 bit code. So I knew the 32 bit code could connect. I created a 32 bit only host and have that much working.
I never got the 64 bit drivers to work but did not try Dan Field's redirect
Related
I believe this is not the same question as this for a couple of reason
There was no upgrading
I tried doing the x86 and x64 build and that did not work
The current versions of for newtorn.JSON are 4.5
First time working with TeamCity. The ASPNETCOMPILIER cannot load the assembly for 'Newtonsoft.json'
I do not know how to handle this. Some key points
NewtonSoft is in the packages folder
When restoring refences this could not be resolved
You're probably using indirect multiple versions of NewtonSoft.Json. As there can be only one version in the bin folder and NewtonSoft.Json is strong named, you will get
"Could not load file or assembly" errors runtime.
Solution is then to use the version 12 of NewtonSoft.Json also in your ASP.NET project, so version 12 could be loaded. It's recommend to update NewtonSoft.Json with NuGet.
If you still get load errors then with other version number, then also add to your config (if not done by nuget):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I've encountered this sort of issues more times than I like to admit and I've been doing this for a while now, so don't feel bad. Each time it's something small that really should not be an issue. Patience is required and is good for any developer to be reminded of.
In web projects changing the target CPU does not always change the values where it's supposed to. It's probably a bug. But what you can do is go into the project file itself and check for cases of "any cpu" and explicitly change any occurrence to x64.
If that fails make sure all your references use the the most up to date version of the framework (and target cpu if applicable) required for the newtonsoft library, although I think 4.5 is fine.
Create a blank project and see if you can install the library there and have it compile correctly, less stuff in a project will make it easier to troubleshoot.
Lastly, turn on full debugging with verbose output, you might get some more detail if you haven't already done that.
The best way I've found to resolve these issues is to isolate the problem by recreating the conditions I believe exist. When creating a new project, often I'm able to assess what's changed or missing. In the case of the target CPU, I knew it could only have been a mismatch since none of my code was present when I tested it in a fresh project.
I'm trying to run an webapp that is using some Azure SDK (and storage) apis but when I try to run it, I always get this runtime error.
I have the project on a Windows 7 box with Visual Studio installed and a bunch of SDKs and it works but on this new Win10 machine I'm starting it doesn't work.
msshrtmi.dll is present on the new machine on C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\runtimes\base\x86 (and x64 and in runtimes\net45\base) but on the old machine it is also on
c:\windows\Microsoft.net\assembly\GAC_XX\msshrtmi and I can see on IIS that is from it's loaded.
If I manually copy msshrtmi.dll to my bin folder the project works just fine. I also know this file is required form Microsoft.WindowsAzure.ServiceRuntime.
On this new machine I'm trying to avoid installing Visual Studio and using only Jetbrains Rider to build and run the project. It can build the project fine but now it doesn't run because of this.
Does the file really need to be on my windows\microsoft.NET folder? What installer puts it there? Or should I just include msshrtmi.dll as a dependency on my project?
Any other solutions for this problem?
I tried a lot of the solutions on other answers I encountered for this similar problem with no luck.
Edit: tried on ISS express 8 and 10
There are several possible ways to solve this issue:
1.Copy the msshrtmi.dll manually to your project. For example in the \bin folder next to the WindowsAzure.Storage.dll.
2.Install the Windows Azure SDK on your server.
3.Change some configurations from app.config.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="false" />
</runtime>
For more details, you could refer to this article and this one.
I've got an issue where my WPF application cannot be published with ClickOnce.
The application uses Nuget packages MVVM Light 4.1.26.1, Unity 2.1.505.2, CommonServiceLocator 1.0.
The problem is that when I publish, it all build fine, but I get this error when I try and install the clickonce package:
Unable to install or run the application. The application requires that assembly Microsoft.Practices.ServiceLocation Version 1.0.0.0 be installed into the Global Assembly Cache (GAC) first.
I did some digging and saw that there were two references to that assembly in the manifest, and one of them was marked as a prerequisite which I can't get rid of:
<dependency>
<dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="59D6D24383174AC4" language="neutral" processorArchitecture="msil" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="Microsoft.Practices.ServiceLocation.dll" size="29760">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="31BF3856AD364E35" language="neutral" processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
<dsig:DigestValue>eee+a+dQmhpSY/ApLxRipXdEp8UsTaZHXHClBU0Iwyc=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
I'm pretty sure the issue with the ClickOnce is down to there being two references to this assembly with the same version (but notice the different public key tokens).
I created a very simple repro as follows:
Create a new WPF application
Add Nuget package MVVM Light
Add Nuget package Unity (also adds dependant package called
CommonServiceLocator)
Build and publish the WPF application
Try and install the published MyApp.application clickOnce package....get the error detailed above
Here's a repro project:
skydrive repro project
Any ideas how I might get over this?
It's now 2019 and I ran into a similar problem, found this question as first entry, but found another (more recent) problem and solution to get MVVMLight and Microsoft.Practices.ServiceLocation work together.
Mvvmlight 5.4.1.1 doesn't work with CommonServiceLocater 2.0.4 (which is both the lastest stable build in March 2019) the way mvvmlight bootstraps it's ViewModelLocator.cs
Two things worked:
either downgrading to
CommonServiceLocater 1.3.0
Mvvmlight 5.3.0.0
or changing the reference from
using Microsoft.Practices.ServiceLocation;
to
using CommonServiceLocator;
Please try again. I just pushed a new build (4.1.27.0) to Nuget that is depending on the official CommonServiceLocator package where available. This should fix your issue. If you have more problems, please make sure to let me know.
Cheers
Laurent
Yes. The MVVMLight ServiceLocation assembly uses a different public key token than every other public implementation. It has made my life a nightmare for quite some time. I finally had to rip out all my nuget assemblies and go back to file references in a common directory for now. I am waiting for Laurent to fix this.
I had this problem as well despite having the 4.1.27 build of the MVVMLight nuget package installed. After hours of frustration I figured out it was because I had the MVVMLight toolkit (v.4.1 for Visual Studio 2012) installed. Once I uninstalled it, my deployment started working again.
Just thought I'd leave this here in case anyone else runs into that particular scenario.
I have installed the Oracle Client for the 64 bit machine using the XCopy 11.2 provided by Oracle (Installed everything as per the read me instructions).
I am using Visual Studio 2010 and the project is of type ASP.NET Website.
When I tried to execute my ASP.NET Website using the Oracle Connection installed above..it is giving me the error from the web.config file during compile time.
**
"Could not load file or assembly
'Oracle.DataAccess, Version=4.112.2.0,
Culture=neutral,
PublicKeyToken=89b483f429c47342' or
one of its dependencies. The system
cannot find the file specified"
**
It worked if I changed the value of Enable 32-Bit Applications to True in IIS App pool.
But my requirement is to make it work on 64 bit machine with 64 bit ODP.NET connector, So I do not want to change the value of Enable 32-Bit Applications to True.
So, If you could please help me finding an answer that would be greatly appreciated. Please help me fixing the above error.
The best possibility to handle this is to use the x86 version locally with Visual Studio and x64 version on the server with IIS.
To do this you have to download both versions - copy one in folder lib\x86 and the other in lib\x64
After this you have to modify the project file(s) - visual studio supports conditional references. Add following section to your project file:
<PropertyGroup>
<ReferencesPath Condition=" '$(Platform)' == 'x86' ">..\Lib\x86</ReferencesPath>
<ReferencesPath Condition=" '$(Platform)' == 'x64' ">..\Lib\x64</ReferencesPath>
</PropertyGroup>
After this reference the odp.net assmebly like this:
<Reference ... processorArchitecture=$(Platform)">
<SpecificVersion>False</SpecificVersion>
<HintPath>$(ReferencesPath)\Oracle.DataAccess.dll</HintPath>
<Private>True</Private>
</Reference>
This way when you can build locally as x86 and on the server x64 and always the correct version of Oracle.DataAccess.dll will be referenced.
Alternatively if you only want to use the x64 version than you have to stick to IIS even you work locally OR you could try to run the open source version of Cassini in x64 mode (http://cassinidev.codeplex.com).
For me the best possibility is to reference both versions as described above - this has been working fine for everyone on my team for a while now.
You must install 64-bit Oracle Data Access Components (ODAC) since the Oracle Client Installation doesn't register Oracle.DataAccess.dll into the assembly.
If your oracle data access installation is OK, everything should work after unchecking "Enable 32 bit applications" in your Application Pool settings.
If you still have the same error, it is possible that you have a 32 bit dll in your bin folder of the website. Just delete it and the website will use the 64 bit from the assembly and it should work.
I'm new to Wix and I have ran into a problem that I'm obviously not able to solve on my own, so any help will be very much appreciated.
Quick background:
I'm representing a software vendor building a comprehensive suite of SOA based applications for deployment in large enterprises. Our architecture consists of many layers which may be installed/upgraded independently, so I'm building several installers, composing from the ground up (like: platform, core framework components, service layer, business layer, application layer, etc.).
Software versions:
-Wix 3.5.1309.0 (wix.dll)
- Visual Studio 2008, .Net 3.5
- Build OS: Windows 2008 R2 Standard 64 bit
- Deploy OS: Windows 2008 Standard 32 bit
My problem is in regards to installing .Net assemblies in COM+ applications. I keep on getting the error "Could not install type library". I have been reading all the documentation that I can find, and I have been google'ing for several days now. I find quite a few posts on the topic, but I'm still not able to resolve the issue.
To isolate the problem I have extracted the issue into a separate installer. First I run the main installer:
1. Installs all assemblies into GAC, including the one to be installed in COM+.
2. Create local users and groups.
3. Create the target COM+ application, including roles etc.
4. Installs the target assembly, and the companion typelib, in a folder (to remove any GAC lookup issues)
This installer I can install/repair/uninstall, everything works fine.
Then I run the minimum installer containing only the issue, which tries to:
1. Install the assembly in an existing COM+ application (server), referencing the pre-installed .dll and .tlb.
The install fails, and the log is showing:
MSI (s) (AC:64) [19:16:01:127]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI1BAB.tmp, Entrypoint: ComPlusInstallExecute
ComPlusInstallExecute: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Could not install type library 'c:\Program Files\MyManufacturer\ComPlus\WDA.ServiceProviders.Update.11.tlb' into application 'WDA.ServiceProviders.Update.11'.', HelpFile='', HelpContext='0'
ComPlusInstallExecute: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method
ComPlusInstallExecute: Error 0x80020009: Failed to register .NET assembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assembly, key: MyAssembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assemblies
Action ended 19:16:02: InstallFinalize. Return value 3.
I also notice that the rollback removes the COM+ application, even though it was not created by this installer.
I can install the assembly manually, using the Server Manager, from the same physical file that the installer is referencing. After manually removing the component from the COM+ application, then the installer works!
Also, why do I have to supply a typelib in the first place? The EnterpriseServices.RegistrationHelper is generating the typelib on the fly anyway.
This is the minimum test installer that is failing:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:complus="http://schemas.microsoft.com/wix/ComPlusExtension"
>
<Product Id="48EDB258-BD84-47EF-94A2-B4950EE48139"
UpgradeCode="F29B8EBD-DFD1-4B7E-96FF-86842CAAE4A4"
Name="ComPlusInstalls"
Language="1033"
Version="1.0.0"
Manufacturer="MyManufacturer">
<Package Id="ABA41719-BC28-4A57-BA9A-58F4F3B2194F" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="WixTest.cab" EmbedCab="yes" />
<complus:ComPlusApplication Id="MyApplication" ApplicationId="1FCF220A-A1FE-44FE-BE91-B37341BA6D4A" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="MyManufacturer" Name="MyManufacturer">
<Directory Id="INSTALLLOCATION" Name="ComPlus">
<Component Id="MyComponent" Guid="6D46A007-6669-487B-BAA0-DFA7314C141D" KeyPath="yes">
<complus:ComPlusAssembly Id="MyAssembly" Type=".net" Application="MyApplication"
RegisterInCommit="no" DllPathFromGAC="no"
DllPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.dll"
TlbPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.tlb"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="MainFeature" Title="WixTest" Level="1" Absent="disallow" InstallDefault="local">
<ComponentRef Id="MyComponent" />
</Feature>
</Product>
</Wix>
Cheers,
-Nils
I have the same problem. Ive tried Wix 3.5 and 3.6.2012.0 and it hasnt worked with either. It works if
I use regsvcs first
Delete the component
Run the msi and click on Ignore when a message comes up about the application already existing
Did you manage to find a solution?
First, you might try upgrading to the latest version of WiX v3.5. There were some bug fixes in COM+ at the end. If that doesn't work, take a look at the open bugs around COM+. There are a couple known issues with the installation code due to complexities in COM+.
If any of those bugs sound applicable maybe you can help fix them with the community?