From times to time when PC restarts, some dll from the GAC are removed. I am sure it's not a manual operation. How can I find how and when the dll are removed ?
NB : after each restart, I manually add the dll by drag and dropping them to C:\WINNT\assembly
Related
I have used a third party dll(ABCpdf) in my .NET app and installed the app onto another machine. The program worked fine but then the trial expired and we purchased the third-party component and copied the new dll into the application directory. When running my app we got an error that assembly could not be loaded. I have noticed that the reference to the dll has copy local set to false so I changed it to true. Still getting the same error.
I checked and there are a number of copied of the dll on the machine - one in the folder of the installed third-party application, one in application folder of my application (copied from the installation folder) and also one in GAC. I did set copy local to true but then again, once the assembly is installed in GAC, that's the version that will always be used.
How can I resolve the issue? Would deleting dll from GAC be safe? Would it resolve my issue? Please advise
Check the references used, etc.
First of all be sure that you're compiling with the right version, with license installed.
You can use this code to add the license key on runtime (to avoid future errors in your customers):
WebSupergoo.ABCpdf7.XSettings.InstallRedistributionLicense("your_serial")
AbcPDF don't need to be installed on GAC. So you can remove it from there.
Then, check the 32/64 bits issue, because ABCpdf use to provide 4 dlls, 2 for each platform (ABCPDF.dll and ABCPdfCEXX.dll).
Try deleting the DLL reference in your project's References and then readding it. Make sure you are adding the purchased DLL that is in your application's directory. I've had to do this plenty of times before when fighting with third-party DLLs...it usually works.
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?
how acually DLL concept works for vb.net project
I have included Microsoft.office.interop.excel dll and sqlite dll
but in other PC, excel dll gets automatically installed with setup
while sqlite dll, I need to manually put in GAC
why it is so ??
any solution, so that I can avoid manual work of copying...
You could provide an installer/setup with your application to install the assemblies in the GAC. Or just provide all the assemblies in the same directory as your application. If the assemblies are not yours, then please check if and how you can redistribute it.
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 an old legacy VB6 application that uses the free ChilkatXML ActiveX DLL extensively. I recently installed this application on a customer's PC – running 64 Bit Win7 (which it usually runs okay on) – and the XML document saving functions are failing. At first it was even failing to open existing documents, but I ran the full Chilkat installer – as it's a free component – and that part at least appears to be fixed.
The customer admitted the PC previously had a virus on it, so I'm thinking there may be some residual OS damage the clean up operation has missed. I've opened the DLL in Dependency Walker, which reported an error with the SYSNTFY.DLL module not being found – although I've checked and that DLL does exist in their System32 folder. I've tried copying the 32Bit version of that dll from my system into their sysWOW64 folder but that didn't work either – not that I realistically expected it to.
So, any ideas on what I need to do to fix this problem please?