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.
Related
I recently switched to a new computer and can no longer use Crystal Reports when I publish to a server location, it works fine locally.
The exact error I get is: Could not load file or assembly 'CrystalDecisions.ReportAppServer.Controllers, Version=13.0.3500.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' or one of its dependencies. The system cannot find the file specified.
I have tried/verified:
SAP Crystal Reports version 13.0.24.2970 is installed along with SAP Crystal Reports runtime engine for .NET Framework (32 & 64 bit) version 13.0.25.3158 are installed on my local machine.
Server has SAP Crystal Reports runtime engine for .NET Framework (32 & 64 bit) version 13.0.6.1027 and 13.0.21.2533 respectively.
Checked the C:\Windows\assembly\GAC_MSIL\CrystalDecisions.ReportAppServer.Controllers file and verified that the listed version on the internal file matches the 13.0.3500.0 version in the config file as well as checking that the .dll file is included in the file.
Checked the server's C:\Windows\assembly folder and verified that the CrystalDecisions.ReportAppServer.Controllers.dll includes version 13.0.3500.0 with a file version of 13.0.21.2533.
Checked that the .NET Framework Version 4_0_30319 and ASP.NET Framework Version 4_7_3429_0 is included in the aspnet_client folder both locally and on the server.
Checked that the local references (CrystalDecisions.CrystalReports.Engine; .ReportSource; .Shared; and .Web) are all included locally, set to copy local, and have a version that matches the config file and .dll versions (13.0.3500.0).
Checked that the target framework in VS 2010 is set to 4.0.
Tried to change version to 13.0.2000.0 in config file but received debugging error that CrystalReportViewer is ambiguous to CrystalDecisions.Web.
Tried other aspnet_client folder versions
Tried to include specific code config file to look for aspnet_client folder
<businessObjects>
<crystalReports>
<crystalReportViewer>
<add key="UseBrowserLocale" value="true" />
<add key="resourceURI" value="/aspnet_client/system_web/4_0_30319/crystalreportviewers13" />
</crystalReportViewer>
</crystalReports>
</businessObjects>
Tried removing all Crystal Report assemblies from the config file but still received an error after publishing.
The only thing I have not tried is uninstalling Crystal Reports and installing the latest version. My coworker and I both received new laptops and he was able to get his working just fine and had installed the same version of CR as I did. Our code matches as well.
The one thing I can think of that may be causing an issue is that the file version on the .dll in question is newer than the file version that is on the server. Could this be causing the issue? If not, can someone help me figure this out?
Hit the same problem myself deploying to Windows Server 2016
if installing the MS c++ runtime doesn't help you, this is what I did:
On DEV Machine
Uninstall Crystal for Visual Studio
uninstall Crystal x64 runtime
Reboot
Install dot net 4.7.2
Install Microsoft Windows Update KB2999226
Install Crystal for Visual Studio (includes x64 Runtime) (V26)
Fix Crystal References (13.0.4000.0) in reports and calling pages
Rebuild app and publish
On Webserver
Install Crystal x32 runtime (V26)
Install Crystal x64 runtime (V26)
Install the MS c++ runtime
Push New published site to Web Sever
Remove Crystal Report assembly references from Web.config <-- responsible for the " The system cannot find the file specified." error
Reboot Azure Server
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.
Currently, I am trying to retarget my windows store app to windows 8.1 preview. The problem is, that I used sqlite-net package in one of my project. I followed steps described here:
http://www.lyalin.com/2013/07/09/sqlite-for-windows-runtime-for-windows-8-1-apps/ and downloaded pre-release version of sqlite visual studio extension from this link:
http://www.lyalin.com/2013/07/09/sqlite-for-windows-runtime-for-windows-8-1-apps/.
I have added a reference to a newly installed sqlite for windows runtime in my project, but I got an error while building:
Error 2 Windows Runtime type 'Windows.Foundation.Point' was found in
multiple referenced winmd files. Please remove either 'C:\Program Files (x86)\Microsoft
SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0\References\CommonConfiguration\neutral\platform.winmd'
or 'C:\Program Files (x86)\WindowsKits\8.1\References\CommonConfiguration\Neutral\Windows.winmd'
from the list of referenced files. C:\Users\Jarosław\Desktop\BCM\Win8Client\MetriceModel\WINMDEXP
MetriceModel (Windows 8.1)
Somewhere, on one of the forums somebody hinted, that if you remove reference to microsoft visual c++ runtime package from the project, it will solve the problem. After I did that whole solution compiled fine, but I got a following exception at runtime:
Unable to load DLL 'sqlite3': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Exception is thrown at a line:
#if NETFX_CORE
SQLite3.SetDirectory(/*temp directory type*/2, Windows.Storage.ApplicationData.Current.TemporaryFolder.Path);
#endif
of SQLite.cs file (file is from mentioned earlier sqlite-net package).
Project's folder bin/Debug/AppX contains file sqlite3.dll. Every project in my solution has x86 as a platform target. How do I fix this issue? Before migrating the project everything worked fine.
You must install the official version of vsix package on sqlite download page (v3.8.0.2).
In the Visual Studio Add-in manager, this package version is 3.7.1.17 and it's not correct.
After, i think it is a bug, you have to select the good processor (platform target).
I had the same error because I deployed a migrated winrt application (8.1) compiled in x86 on a x64 machine...
=> in windows 8.0 it works, but not in windows 8.1.
If you have a x64 machine you have to select the x64 target compilation. I hope it will be fixed in futur...
can you please re-install the preview of SQLite for WinRT 8.1? There was an issue with the initial package, but we worked with them to update. http://sqlite.org/download.html
If you have an exception with
SQLite3.SetDirectory(/*temp directory type*/2,windows.Storage.ApplicationData.Current.TemporaryFolder.Path);
Check if your project uses x86 and not any CPU
We have a project that compiles to a 32-bit COM DLL and to a 64-bit COM DLL (the same one from my earlier question). When I register both on my Windows 7 machine, both register successfully. When I register both on a Windows Server 2003 machine, both register successfully.
But when I try to register the DLLs on a Windows Server 2008 R2 standard SP1 machine, the 64-bit DLL registers successfully, but the 32-bit DLL fails with the message (sic):
The module ""%1"" may not compatible with the version of Windows that you're running.
Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I don't think a 32-bit DLL can be compatible with WS2003 and Win7 but not WS2008. That makes no sense.
What might be happening?
The version of Regsvr32.exe must match the 32-/64-bitness of the dll you're trying to register. The 64-bit regsvr32 cannot load a 32-bit dll, and vice versa.
You may need explicitly call the 32-bit version of regsrv32 located in %systemroot%\SysWoW64\regsvr32.exe.
From http://support.microsoft.com/kb/249873
Regsvr32.exe is included with Microsoft Internet Explorer 3.0 or later versions, Windows 95 OEM Service Release 2 (OSR2) or later versions, and Windows NT 4.0 Service Pack 5 (SP5) or later versions. Regsvr32.exe is installed in the System (Windows Me/Windows 98/Windows 95) or System32 (Windows NT/Windows XP/Windows Vista/Windows 7) folder.
Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Regsvr32.exe usage
RegSvr32.exe has the following command-line options:
Regsvr32 [/u] [/n] [/i[:cmdline]] dllname
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline]; when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must be used with /i
/s – Silent; display no message boxes (added with Windows XP and Windows Vista)
When you use Regsvr32.exe, it attempts to load the component and call its DLLSelfRegister function. If this attempt is successful, Regsvr32.exe displays a dialog box that indicates success. If the attempt is unsuccessful, Regsvr32.exe returns an error message. This may include a Win32 error code. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
193625 WinInet error codes (12001 through 12156)
This isn't likely to be the problem in your case, but might be useful for others who find this question by searching on the same error message:
I had a similar problem: a DLL that wouldn't register with either the 32-bit or 64-bit version of RegSvr32. I loaded the DLL the Dependency Walker (depends.exe, http://www.dependencywalker.com/) and got a much more useful message:
Error: At least one file was not a 32-bit or 64-bit Windows module.
Scanning the CPU column in the Module List identified the offending module. (In my case, it said "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module.")
Moral: The Dependency Walker might give you a more useful error message than RegSvr32.exe.
I got it registered by moving the dll to the c:\windows\syswow64\ directory (it wouldn't work in the system32 directory) and then explicitly calling syswow64\regsvr32, eg
c:\windows\syswow64\regsvr32 yourdll.dll
btw it wouldn't work when calling c:\windows\syswow64\regsvr32 c:\windows\syswow64\yourdll.dll
Use Process Monitor from SysInternals.
1. Filter by "Process Name" = regsvr32.exe.
2. Try to register your DLL file from the correct version of regsvr32.exe (the 32-bit version is in the SysWow64 folder)
3. Process Monitor will trace EVERYTHING that is happening on your computer.
4. First start your analysis by eliminating the registry events (for now):
5. You may be able to see which DLL file is found and not found.
Here a (very) partial screenshot of regsvr32.exe of Threed32.ocx where we can see some of the required DLL files:
6. Your work is just starting. From now.
I have the same problem, but I resolve it with commands
CD \windows\syswow64
regsvr32 c:\filename. dll
Running the command prompt as administrator fixed my issue.
I recently upgraded a VS2005 web deployment project to VS2008 - and now I get the following error when building:
The specified task executable location "bin\aspnet_merge.exe" is invalid.
Here is the source of the error (from the web deployment targets file):
<Target Name="AspNetMerge" Condition="'$(UseMerge)' == 'true'" DependsOnTargets="$(MergeDependsOn)">
<AspNetMerge
ExePath="$(FrameworkSDKDir)bin"
ApplicationPath="$(TempBuildDir)"
KeyFile="$(_FullKeyFile)"
DelaySign="$(DelaySign)"
Prefix="$(AssemblyPrefixName)"
SingleAssemblyName="$(SingleAssemblyName)"
Debug="$(DebugSymbols)"
Nologo="$(NoLogo)"
ContentAssemblyName="$(ContentAssemblyName)"
ErrorStack="$(ErrorStack)"
RemoveCompiledFiles="$(DeleteAppCodeCompiledFiles)"
CopyAttributes="$(CopyAssemblyAttributes)"
AssemblyInfo="$(AssemblyInfoDll)"
MergeXmlDocs="$(MergeXmlDocs)"
ErrorLogFile="$(MergeErrorLogFile)"
/>
What is the solution to this problem?
Note - I also created a web deployment project from scratch in VS2008 and got the same error.
Apparently aspnet_merge.exe (and all the other SDK tools) are NOT packaged in Visual Studio 2008. Visual Studio 2005 packaged these tools as part of its installation.
The place to get this is an installation of the Windows 2008 SDK (latest download).
Windows 7/Windows 2008 R2 SDK: here
The solution is to install the Windows SDK and make sure you set FrameworkSDKDir as an environment variable before starting the IDE. Batch command to set this variable:
SET FrameworkSDKDir="C:\Program Files\Microsoft SDKs\Windows\v6.1"
NOTE: You will need to modify to point to where you installed the SDK if not in the default location.
Now VS2008 will know where to find aspnet_merge.exe.
I just ran into this same problem trying to use MSBuild to build my web application on a server. I downloaded the "web" version of the SDK because the setup is only 500KB and it prompts you for which components to install and only downloads and installs the ones you choose. I unchecked everything except for ".NET Development Tools". It then downloaded and installed about 250MB worth of stuff, including aspnet_merge.exe and sgen.exe
You can download the winsdk_web.exe setup for Win 7 and .NET 3.5 SP1 here.