I needs to install .NET 4.0 assembly to GAC duing the MSI installation, target OS can be either XP and Windows7. I see there is a different is registering dlls to GAC in XP and windows7.
Could someone explain what should i consider during GAC installation ?
kuru.
Normally GAC folder paths are different for 64 and 32 bit Dlls in Win7. Whereas in XP it resides under same folder. But when adding assembly to GAC through MSI we dont really need to worry about built version. based on the built version MSI will register them under 64 or 32 bit folders.
Related
I have a 3rd party dll which when used in my local VS was working perfectly without any issues. This 3rd party dll came with 32bit and 64 bit dll installation files. I ran the 64bit installer and the system32 folder had the dll required. My local project had no trouble calling these dll's.
When I tried the same step to host the website on IIS 7.0 on 64bit windows 2012 R2 testing server, I was getting the following error :
Unable to load DLL '3rdparty.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
To fix this i tried uninstalling the 64bit and installed the 32 bit dll's and SysWow64 had the dll's required and no error was received.
I checked if system32 had those dlls but there was none and only syswow64 had the dll's. Can any one tell me why 32 bit dll's worked on the server and 64bit on my local ?
Also when trying on different machines I found 32 bit installer worked on all but 64 bit had issues on some machines.
Adding to this strangeness, when I hosted a copy of same website on different folder however under same application pool of IIS 7.0 on the testing server. I received the error on one website while the other had no issue loading the dll's required. Both these website had everything same in terms of IIS user used, access rights only difference was they were under different folder structure.
Also is there any way of referencing 3rd party dll to use particular path rather than trusting system32 and syswow64 folders in website projects.
As mentioned by Cyril I used Procmon to track where the asp.net website was looking for the 3rd party dll. On checking it was found that 3rd party dll was being looked at SysWow64 folder rather than on anticipated folder that is System32. This was happening because the website before copying was compiled on 32 bit version and hence copied version was looking for 32 bit and not 64 bit. This was making it to behave differently. However I need to understand how does the .net compiler decide to use which version to get to the bottom of this confusion that I have.
Following question also helped: Dll in both the bin and the gac, which one gets used?
I have installed a Web app on IIS 7.0 Windows Server 2008 R2 64bit.
I am referring an oracle.DataAccess.dll;
When I try to access the application I get the following message:
"Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Can anybody help me, please?
It seems the Oracle Data Access Component installation process using the "11.2 Release 3 (11.2.0.2.1) with Xcopy Deployment" version is broken. To fix this you must register the missing assemblies in the GAC. To do this for this specific version run these commands from within an administrator console:
md C:\Windows\assembly\GAC_32\Oracle.DataAccess\4.112.2.0__89b483f429c47342\
copy %ORACLE_HOME%\odp.net\bin\4\Oracle.DataAccess.dll C:\Windows\assembly\GAC_32\Oracle.DataAccess\4.112.2.0__89b483f429c47342\
md C:\Windows\assembly\GAC_32\Oracle.Web\4.112.2.0__89b483f429c47342\
copy %ORACLE_HOME%\asp.net\bin\4\oracle.web.dll C:\Windows\assembly\GAC_32\Oracle.Web\4.112.2.0__89b483f429c47342\
Note that this registers only the DLL's but not other languages resources. So, if you are using any another language than English (de, es, fr, it, ja, ko, pt-BR, zh-CHS, and zh-CHT), then you need to register these as well using the corresponding resource file.
If you have Visual Studio installed on the machine, you can issue the following commands instead:
gacutil /i %ORACLE_HOME%\odp.net\bin\4\Oracle.DataAccess.dll
gacutil /i %ORACLE_HOME%\asp.net\bin\4\oracle.web.dll
Note: look for gacutil.exe under the Visual Studio installation folder for it.
Hope this helps.
P.S. Or you can try this.
I avoided registering the 11.2 Release 5 assemblies in the GAC by setting "Enable 32-bit Applications" for the application pool to true.
You may need to enable 32-bit applications in your AppPool.
http://www.alexjamesbrown.com/development/could-not-load-file-or-assembly-chilkatdotnet2-or-one-of-its-dependencies-an-attempt-was-made-to-load-a-program-with-an-incorrect-format/
You need to register that dll on the live server using GAC util. Also check if its present in bin folder or not. Some times missing dll's in bin directory results in same error
In my case, I use VS 2010, Oracle v11 64 bits. I might to publish in 64 bit mode (Setting to "Any Cpu" mode in Web Project configuration) and I might set IIS on Production Server to 32 Bit compability to false (because the the server is 64 bit and I like to take advantage it).
Then to solve the problem "Could not load file or assembly 'Oracle.DataAccess'" (sometime appear the "Compiler Error Message: CS1705: Assembly" error):
In the Local PC and Server is installed Oracle v11, 64 Bit.
In all Local Dev PC I reference to Oracle.DataAccess.dll (C:\app\user\product\11.2.0\client_1\odp.net\bin\4) which is 64 bit.
In IIS Production Server, I set 32 bit compatibility to False.
The reference in the web project at System.Web.Mvc.dll was the version v3.0.0.1 in the local PC, however in Production is only
instaled MVC version 3.0.0.0. So, the fix was locallly work with MVC
3.0.0.0 and not 3.0.0.1 and publish again on server, and it works.
Installing 64-bit ODAC 11.2 Release 3 (11.2.0.2.1) Xcopy for Windows x64 from:
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
Fixed it for me. Make sure to update your system path as per step #4 in the readme file.
The accepted answer, published by George Netu helped to solve my problem, but I had to fiddle with some additional trifles:
Problem description:
Under C:\Windows\assembly, I found two Oracle.DataAccess items(GAC-folders?). Relict, caused by several Oracle client installations. One item showed Version 2.112.1.0 but was actually version 2.121.2.0 (visible through Properties->Version). That inconsistency was the bug.
First unhelpful attempts:
tried to deinstall and reinstall the Oracle full client, both in versions Runtime/Administrator
tried to redeploy the correct .dlls
tried to copy the new installed assemblies in the GAC serveral times, as stated in the accepted answer above via command prompt (but that didn't solve the version mismatch..)
tried to use gacutil /i ...
Final success:
I landed on the Gacutil.exe msdn page and were ultimately able to delete the items from the C:\Windows\assembly folder.
gacutil /u Oracle.DataAccess, Version=2.112.1.0, Culture="Neutral",PublicKeyToken=45e343aae32233ca
gacutil /u Oracle.DataAccess, Version=2.212.2.0, Culture="Neutral",PublicKeyToken=45e343aae3223abc
gacutil /u Oracle.Web, Version=2.112.1.0, Culture="Neutral",PublicKeyToken=45e343aae3223def
After that, i repeated the two gacutil /i ... commands and the two dlls appeared there in consistent versions.
Finally restarted the IIS, and it works..
Yeah, it is a quite annoying issue I faced sometimes. The main problem is that an web application uses wrongly 32 bit Oracle.DataAccess.dll instead of 64 bit, or in the reverse case. There are a few solutions for it.
1. Enabling 32-bit applications in the application pool if your application is 64 bit and need to run 32 bit Oracle.DataAccess.dll.
Go to the IIS and set true for "Enable 32-Bit Applications" option in Advanced Settings of an Application pool.
2. Correcting reference dll.
Reference path is supposed to be system reference path configured by Oracle Installation process. But, some cases such as installing or updating new Oracle version, the latest DLLs doesn't update old ones, or path is changed, or a reference is not updated in the web application project. Therefore, we should correct Oracle.DataAccess reference manually.
Go to the web application and remove Oracle.DataAccess reference. And add new reference for Oracle.DataAccess. It must be correct Oracle.DataAccess.dll from your oracle installation path. For example:
C:\Oracle\product\12.2.0\client_1\odp.net\bin\4\Oracle.DataAccess.dll
ODP.NET and Dependent Unmanaged DLL Mismatch
To enforce the usage of
Oracle.DataAccess.dll assembly with the correct version of its
unmanaged DLLs, an exception is raised if Oracle.DataAccess.dll
notices it has loaded a mismatched version of a dependent unmanaged
DLL.
https://docs.oracle.com/cd/E11882_01/win.112/e23174/InstallODP.htm#ODPNT152
3. Easy and quick way (but not proper solution) to fix the issue is that override directly an Oracle.DataAccess.dll file copying from oracle installation path (for example: C:\Oracle\product\12.2.0\client_1\odp.net\bin\4\ ) to Bin folder of your web application.
Hope this helps you a little. Good luck.
I had the same problem.
I go to the project properties in general section set platform target to 64 bit (x64) and my problem solved
In application pool ---> click Advance settings --> Enable 32 bit option
see the this image
Its been a while since I setup a Build Server so maybe I've forgotten something or maybe .NET 4.5 is different from whatever version I did this with last time, but here is my problem.
I'm trying to setup a build server to monitor a source control repository. Whenever something changes, I want the server to pull the changes and build the project. If there are no errors, I want to deploy the site to a web site running on the build server.
In the past when I did this, I thought that I was able to do this having only .NET installed, but when I try to build this project I get an error that "C:\Program Files\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" is missing, and if I go and look I can see that it is missing. In fact there are no Visual Studio 11 targets files.
After a lot of thought and head scratching, I went out and got the "Windows 8/.NET 4.5 SDK" thinking that the .NET 4.5 SDK might install the targets files that I needed, but it did not unless I installed it wrong somehow.
So, what do I need to put on the Build Server in order to get the project to build. I would prefer not to have to install the full Visual Studio 2012.
To run on on your CI server without Visual Studio, you only need to copy a few folders from a development machine to the same location on the CI server. There is no need to install the SDK.
VS 2015:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications
VS 2013:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications
VS 2012:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications
VS 2010:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
.NET 4.6:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6
.NET 4.5.2:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2
.NET 4.5.1:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1
.NET 4.5:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5
.NET 4.0.1:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0.1
.NET 4.0:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
Or, as Matt suggested, you could copy them into a subdirectory of your project and alter the <MSBuildExtensionsPath32> location in your MSBuild (typically .csproj or .vbproj) file.
Once you have done this, your project will compile.
You should also set the VisualStudioVersion environment variable explicitly to the Visual Studio version (10.0 for VS2010, 11.0 for VS2012, 12.0 for VS2013, 14.0 for VS2015) you are using just to be sure it is set right in your configuration.
My problem was related to installing the Windows Software Development Kit (SDK) for Windows 8 on a Windows 2008 Box. If you read further on the page, you will get to a heading labeled ".NET Framework 4.5 SDK Tools on Windows Vista and Windows Server 2008." This tells you to:
Run the Windows SDK for Windows 8 installer on a supported operating system (for example, Windows 7, or Windows 8).
Choose the following option on the Specify Location screen: Download the Windows SDK for installation on a separate computer.
Press the Next button.
Answer the questions on the Join the Customer Experience Improvement Program (CEIP) screen.
On the next screen, choose the .NET Framework 4.5 Software Development Kit feature. Unselect all other features that can be unselected.
Choose the Download button.
Go to the download location (specified in step 2) and find the following .NET Framework 4.5 SDK tool installer files:
sdk_tools4.msi,
sdk_tools4.cab
You can copy these files to a Windows Vista or Windows 2008 Server computer within your organization. These files need to be copied to same directory on the Windows Vista or Windows 2008 Server computer.
Note: Do not redistribute these files outside your organization or as part of any other installer.
On the Windows Vista or Windows 2008 Server computer, review the license terms here .
Check whether .NET Framework 4.5 is already installed on the computer. Otherwise, download and install .NET Framework 4.5 from www.microsoft.com .
Open a command prompt with administrator privileges.
Go to the directory where .NET Framework 4.5 SDK Tools installer files were copied.
Install .NET Framework 4.5 SDK tools by using the command line:
Msiexec /i sdk_tools4.msi VSEXTUI=1
From msdn:
The Windows SDK no longer ships with a complete command-line build environment. You must install a compiler and build environment separately. If you require a complete development environment that includes compilers and a build environment, you can download Visual Studio 2012 Express, which includes the appropriate components of the Windows SDK.
In order to fix this, I had to copy the folder C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5 from my development machine (which has Visual Studio 2012 by the way) onto the build agents. After this operation, Team City did not report any more errors and mscorlib.dll was not output to the bin folder.
Microsoft Build Tools 2013 will help in this case, as its download page describes:
If you don't have Visual Studio installed on your computer, you can
use Build Tools 2013 to build managed applications. The Visual Basic
and C# compilers are also included in this download. (In earlier
versions, these tools were included in the stand-alone .NET
Framework.)
My dept. likes taking a minimalistic approach to what's installed on our Win 7 build machines. However, we don't like just copying and pasting files/folders because of potential registry key issues. Instead of installing VS 2013, I installed the following much smaller and free components. Now the dev team can build VS 2013 web apps successfully.
.Net Framework v4.5.1, required to install the tools - http://www.microsoft.com/en-us/download/details.aspx?id=40779
MS Build Tools 2013, we needed the C# compiler - http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx
MS VS 2013 Isolated Shell, we needed the web app targets - http://www.microsoft.com/en-us/download/details.aspx?id=40764.
I solve this problem with Visual Studio Agents.
You can try install Visual Studio Agents 2012.
http://www.microsoft.com/en-us/download/details.aspx?id=38186
I have a 64 bit CHILKAT CRYPT assembly (for .NET 4.0). when I run my application in IIS 6.0 in Windows Server 2003 (64 bit) I got an error that the assembly is not found. on the other hand, in my local machine I have a 32 bit assembly and Windows7 32 bit and it works fine.
What should I do to to overcome this error and what are the causes?
The main problem I found is that the web application is built for platform x86 and deployed to x64 machine on which the machine does not allow 32 bit programs to run.
in this case the error that indicates that the assembly is not found is not correct. its simply not compatible with x64 machine.
I found that the following steps solved the problem:
Add the 64 bit assembly to web application project (visual studio 2010)
Select x64 for target platform from the configuration manager in visual studio
Build the solution and deploy it
This steps really fixed my problem.
I have a 32-bit application that I'm packaging with InstallShield 2009 Premier. I would like to be able to install it on 32- and 64-bit machines, but the InstallShield installer doesn't seem to be able to automatically detect that it's being run on a 64-bit machine and consequently redirect the creation of registry keys to HKLM\Software\Wow6432Node... and the creation of files to C:\Program Files (x86)... Despite my best googling, I can't seem to find out how to configure the InstallShield project to account for this.
Any ideas?
Since you have a 32-bit application, you need to leave its installer the way it is.
Wow6432Node and Program Files (x86) were specifically designed for 32-bit applications. On a 64-bit machine Program Files and HKLM\Software are for 64-bit applications only.
A mixed 32/64-bit installer can be used only for an AnyCPU application.