Is there any downside other than the increased package size, for deploying a DLL that is part of the GAC?
What should we be worried when we do this? I believe GAC DLLs win over local DLL, so worst case scenario, if the target machine does not have the DLL on GAC and the local DLL is for 64 bit but the target machine is 32 bit, I can see a problem. But in this case, deploying the DLL as local copy does not make it worse.
I am not suggesting to put everything on local copy. I am wondering if local copy approach is to be considered as "safer way".
There is nothing wrong with it at all. You GAC DLLs will "win" over your local bin if they are the same version number and if they are the same version number there is no problem, a neither here nor there kind of thing. See this question on stack:
Dll in both the bin and the gac, which one gets used?
Related
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.
I'm getting a DLLNotFoundException in standalone builds on some windows machines, others work perfectly. Dll file is definitely in the plugins folder, copied it to the projectName_Data folder too but no difference.
Also attempted to add dll to streaming assets folder and set new path (Environment.SetEnvironmentVariable) as above but that didn't work either.
Using Unity 4.5.5 btw
Any help at all would be greatly appreciated!!!
What I found is that the error DllNotFoundException is, in some circumstances, very misleading. Unity is not to blame for this because when something goes wrong with dll loading, Unity simply doesn't have that dll in memory and tells you so.
As Keysosaurus says, Visual C++ Redistributable must be installed for your standalone version to work and in most cases this solves the trouble but there can be other reasons like third party dependencies.
In case you are using third party libraries then you must also copy all the needed DLLs or SOs to your executable's folder.
For example I am working with OpenNI 2 and when I build I immediately copy all files from C:\Program Files (x86)\OpenNI2\Redist folder to the folder that contains the .exe. Not doing this results in DllNotFoundException.
Also don't forget that DLLs (and SOs) must match the architecture you are targeting so if you are targeting x64 (64 bit) then your DLL must be x64 too and if you try to use a x86 (32 bit) DLL Unity will be confused and will not load that giving you the same error.
As a side note bear in mind that Unity 5 comes both in 32 and 64 bit versions. In order to run your game in Unity Editor, all third party libraries must be present in both x86 and x64 (in Unity's conventional folders) or at least the one that matches you Unity Editor's architecture.
I discovered that the problem was that players needed Visual C++ redistributable installed, which can be downloaded here:
https://www.microsoft.com/en-gb/download/details.aspx?id=40784
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I have done extensive testing with this and have isolated the problem to this. I'm trying to keep this to the point but please ask if there's any other information you feel I'm leaving out.
-a.exe is our vb6 app that references x.dll
-x.dll is an in house vb6 dll that references y.dll
-y.dll is an in house .net interop dll
-Everything works fine on the development machines.
-I have more than triple checked our .net setup project to ensure files are being pulled from the correct places.
When installed, a call from x.dll to y.dll fails. Ultimately how I am able to fix this is by copying x.dll from the development machine over the x.dll file that was installed by the setup project on the target machine. These two should be identical.
Anyone have any clues whatsoever what this could be? It's pretty much the strangest dll problem I think I've ever had :(
Though I fixed the problem, I still don't completely understand why there was a problem but here's what I found...
Vb6 always wants to change the dll being referenced to the one most recently registered. We used to register dlls to an application directory located in C:\ and not within the source code folders, and we referenced them from there, and grabbed them from that directory for the install package.
When we switched to subversion we moved the dlls into a dependency folder within the branch. However, the dlls continued getting copied and registered to the application directory as well where the build would grab them from. I had to update the build to grab the dlls from the new branch location and stop them from being copied to the old location.
That seems to have fixed the problem, but I don't fully know why because a comparison of the dlls in both locations showed they were identical.
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.