I have developed an C# application that run very well in local.
But there is a problem when i put on the server.
The application uses a DLL library in his references (A.dll) and in a point of the execution the A.dll creates in the Temp directory another DLL (embedded in it, let's call it B.dll).
But when the A.dll try to load the B.dll an exception is threw:
system.invalidoperationexception: failed to load B.dll
I have not access at the DLLs source, are libraries.
So recap:
The process have the full control permission on the file and path.
(cheked)
Is running like Administrator. (checked)
In my application if I try to open the dll in binary mode, the
operations have no problems.
Runs well on every OS that i have tested (Windows 8_64 / XP_32 /
2008_32 / 7_64), but fails with 2008 R2 64.
I have tried to ReDownload, rename, reinstall the B.DLL, i have putted the program in the same path of the B.DLL, etc etc, with no results.
So at this point I think that is a security problem on the server, like "Processes cannot load DLLs" or something similar.
The exception:
http://i.imgur.com/NmB2Fth.png?1
Anyone can suggest me any solution? Would i check better? Where?
P.S
IF i try to register the dll i got the same error of this:
Register DLL file on Windows Server 2008 R2
The solution was simple.
I have used a very useful tool named Event Viewer (Start->Execute->eventvwr.exe)
When i started my application a new error event was showed on the Windows Logs->Applications:
Activation context generation failed for "C:\Temp\APP\myfile.dll".
Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="x86",
publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found.
Please use sxstrace.exe for detailed diagnosis.
A quick search and the result was that the server needed the Visual C++ Runtime for x86 (x86 because my application works in the 32bit application pool)
Once installed this package: http://www.microsoft.com/en-us/download/details.aspx?id=5582
Everything worked like a charm.
I hope this will help anyone to save some time!!
Related
(First things first, I'm kind of new on this type of programming)
I'm trying to make a windows form application where i request data from a PLC so it can be stored in a access database. This application is going to be running on a different computer.
On the solution i created and besides my project I'm using an existing project that works "like" the communication between the app and the PLC, it is called LibplctagWrapper (on my main project I create a reference to this last one)
(https://www.mesta-automation.com/how-to-communicate-to-an-allen-bradley-plc-with-c-and-libplctag-ethernet-ip-library/),
and it works on my PC, but every time y copy the Bin folder to the new computer, then run the app, it opens, but a warning popup messages appears. Saying: Unable to load DLL "plctag.dll": The specified module could not be found. (Exception from HRESULT: 0x8007007E).
The LibplctagWrapper is in another directory than my Solution and Main Project so I moved it to C: so the direction will be the same on the new computer. But it doesn't work.(copy the LibplctagWrapper in C: of the new pc as well)
Moved the entire solution/main project to C: as well... the same result.
Instead of just the bin folder i copied the entire project folder... im thinking the problem goes with the fact that the LibplctagWrapper is not in the same direction? but I don't know how to place it in the same direction... I search on visual studio but I never saw the option to move it.
Unable to load DLL "plctag.dll": The specified module could not be found. (Exception from HRESULT: 0x8007007E).
This error message is quite generic, missing dependencies can cause it as well as the mentioned module not being present at all. Check the Dependency Walker ( http://www.dependencywalker.com/) to discover required C++ runtimes or something alike. Remember to take x86/x64 into consideration.
#JavierMata - I think you have probably resolved this issue, but for others encountering something similar you can use the recently released official wrappers which can be downloaded via nuget. Github link: https://github.com/libplctag/libplctag.NET
The libplctag.NativeImport package handles loading the appropriate C runtime so you don't have to.
I have a simple application using a product activation system offered by cryptlex (cryptlex.com).
The program works correctly on my computer, but when I try to run the program on another machine it returns this error:
I've already made sure that the dll is inside the executable folder and everything looks OK.
When I remove all part of cryptlex the program works perfectly on any machine (x86-x64)
I used depencywalker to check for errors and found these two in the executable that uses cryptlex:
Windows 7 64bits,
.NET Version: 4.0
You can use Process Monitor to record all file activities of the program. Set a filter for your executable. After reproducing the error, save the log as XML file.
Then run ProcMon Analyzer (note: I'm the author of it). It will analyze the file and give a list of DLLs that were not found.
You could also do that manually, but note that some DLLs may not be found at first, but later be found when looking in the %PATH% environment variable etc. The tool will remove all those entries which have PATH NOT FOUND first but SUCCESS later.
While the DLL is present, have you checked the bitrate?
Most C# projects default to building against Any CPU - if the DLL is specific to a bitrate (ie x86 or x64) then it might be that the program picks the wrong bitrate on end machines (usually x86) but the right one on your machine (x64). This is usually best resolved by building out different x86 and x64 versions; it's messier, but only .NET itself is good at using the Any CPU paradigm.
The exception should have detail about what DLL in particular was not found - maybe look closer?
GPSVC and IESHIMS missing should not be a problem; as indicated by the hour glass, they're deferred dependencies anyway.
On my ASP.net site I have a reference to Microsoft.SQLserver.SMO. I copied this reference onto my production server and got a could not load error for Microsoft.SqlServer.Management.Sdk.Sfc. This error was fixed by copying the dll from the
C:\Program files\Microsoft Sql Server\110\SDK\Assembilies
However I then got the same error but for Microsoft.SqlServer.SqlClrProvider which is nowhere to be found.
Where can I find the SqlClrProvider dll? It works on my localhost so it must be somewhere.
On your development machine or a machine where you have SQL Server installed, the Microsoft.SqlServer.SqlClrProvider.dll file is in your GAC. However, you cannot copy this file without making changes to the registry.
Using the registry editor, go to HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Fusion. Add a new DWORD called DisableCacheViewer. Give it a value of 1.
Once this change is made, you can go to C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlClrProvider\ to get the dll you need.
To see a more detailed explanation, follow one of these links:
HOW TO RESOLVE “SQLCLRPROVIDER NOT FOUND” WITHOUT INSTALLING SQL SERVER ON THE CLIENT MACHINE OR NEEDING A DEPLOYMENT PROJECT
Could not load file or assembly Microsoft.SqlServer.SqlClrProvider
I wanted to make an embedded script in powershell and stumble upon your same problem.
The thing is that Microsoft.SqlServer.SqlClrProvider.dll is not installed in SQL files but in windows assembly.
Assembly folder is special: you can't copy anything with windows UI.
I just needed the Microsoft.SqlServer.SqlClrProvider.dll so that I can load it in my script like that:
[System.Reflection.Assembly]::LoadFile($scriptPath+"dll\Microsoft.SqlServer.SqlClrProvider.dll") | out-null
to copy it you can do the following:
c:\>cd c:\Windows\assembly
c:\Windows\assembly>dir /s Microsoft.SqlServer.SqlClrProvider.dll
# here you get the directory and the file
c:\Windows\assembly>copy c:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlClrProvider\<version>\Microsoft.SqlServer.SqlClrProvider.dll c:\Users\Administrator\Desktop\
you want to do that on a machine with SQLserver installed otherwise you may not find it.
It's just a workaround. I guess it's not the best thing to do if you need to execute your script in different environments.
hth
Copying SqlClrProvider dll into sqlserver Binn directory didn't help in my case.
Cause:
It was cause by using different versions of SQLServer on production machine and target machine.
Solution:
Make sure you are using the same version of SMO libraries as you have on the target machines. If there is SQLServer2008 on the target machine you must use v10 libraries otherwise you would get this error.
MoreDetails:
SqlServer on my target machines was version 2008 (10) and I had SqlServer2014 (12) on my own machine. When I used SMO library visualstudio added v12 libraries (Microsoft.SqlServer.SMO, ...) but smo is just a shell which use SqlClrProvider and it expects to have SqlClrProvider of same version on system assemblies. this caused the application to crash on the target machine since the v12 of SqlClrProvider didn't exist. By using v10 smo libraries I solved the problem
Had the same issue but for version 11. To get the right assemblies installed a did the following steps:
Check what version is expected: https://sqlserverbuilds.blogspot.com/. Version 11 => sql server 2012
Download Microsoft's web platform installer and install it
Search for 'sql server 2012' and install one or all of the following:
The first thing you need to do is disable the GAC Shell extension which allows you to browse the GAC, to do this:
Open “regedit”
Navigate to
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Fusion
Add a new DWORD or 32
bit DWORD named DisableCacheViewer with the Hex value of 0x1 or a
decimal value of 1
That disables the GAC Shell allowing you to fully browse assembly folder, now we can extract the assembly from the GAC and drop it into the bin folder or the dll location on the client machine.
Go to C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlClrProvider\
You may notice more than folder here, this is for each version of SQL server you have installed
For SQL 2012 it will be : \11.0.0.0__89845dcd8080cc91
You will then find the file Microsoft.SqlServer.SqlClrProvider.dll
Reference
I could not solve my issue, while using Microsoft.Sqlerver.SMO reference. So I instead used the System.Data.Sql.SqlDataSourceEnumerator class for all my Sql functionality needs.
For people googling this error, and arriving here, there is another possibility. Go into Services, and make sure that your SQL Server process can run. On my machine, the password for the user account had changed. Once I fixed the password, the process started, and I no longer received the above error.
I have a program that has been working just fine, however when I made a small change to the way the program loads from its ini, the zipping function stops working. I stepped through the program and found the error to be occuring on the following line:
var fs = File.Create(zipPath);
fs.Write(emptyZip, 0, emptyZip.Length);
fs.Flush();
fs.Close();
var sc = new Shell32.ShellClass();
var srcFlder = sc.NameSpace(program.Path); //THIS LINE
var destFlder = sc.NameSpace(zipPath);
var items = srcFlder.Items();
destFlder.CopyHere(items, 20);
System.Threading.Thread.Sleep(500);
ZippedPrograms.Add(zipPath);
I double checked the variables program.Path and others being sent to the ShellClass(), and they are not null or empty. This is the actual error that pops up when the program gets to this line:
Doing some googling I find that apparently the Shell32.dll I have referenced in my program does not work right with 7 (or server 2008, the target environment), and I needed to reference the XP version instead (52kb versus 48kb dll size). One of the links where I found this info: click me.
So I created a virtual machine and installed WinXP Professional on it, and navigated to C:\WINDOWS\system32\ and copied the Shell32.dll located there to my host computer. Strange enough, the DLL is ~8mb in size rather than the 52kb I was expecting. When I add it as a resource from VS2012, I browse to the copied file and add it (with copy local), but then for some reason it ends up being 48kb in size and the program continues to crash at the above mentioned line.
I have tried using DotNetZip along with other C# libraries for zip management, and for some reason they never work properly (creating corrupted ZIP files, not creating them at all, refusing to add random files/folders to the archive, etc). Before this issue the program was working flawlessly, so more than anything I am confused as to why all of a sudden it is not working and why the Shell32.dll is not A) the 8mb version I reference, and B) 'stripped down' to 48kb. On top of that, I checked the current deployment of the program, which lacks some features of the current version, among other things, and the DLL there is the 48kb size, and this particular deployment has worked with no problems.
I should also mention that I am currently running Windows 8 Pro, and developing in VS2012. The deployment environment is Windows Server 2008 R2. I originally wrote this program in VS2010 on Windows 8 Ultimate. When I opened the project for the first time in VS2012, there was no upgrade dialogue. All OS's listed (except WinXP Pro) are x64.
Has anyone had any experience with these issues/happenings? Any insight/tips/solutions will be greatly appreciated.
Thank you!
Dragging across an outdated system dll to a newer version of Windows is something that's just bound to fail, especially if it's (as in this case), a COM interop DLL. If Windows 8 is running a COM service, it's going to be running it with its "own" version of the DLL. If you then try to interact with it using an interface DLL for a different version, you'll get an interface mismatch. As you've seen, E_NOINTERFACE.
You're trying to use a version 6 DLL to communicate with a version 8 service. It's bound to run into problems.
The difference in size might have something to do with Visual Studio stripping the deployment DLL down to just the interfaces, instead of including all the implementation.
I'm writing ADO.NET provider. For debugging I use class DbProviderFactories.GetFactory method. This method constructs my inherited DbProviderFactory class that i use for create DbConnection inheritor of my provider and etc.. When I try set breakpoint in my provider code I sow it isn't work - execution doesn't stopped. When I throw exception in my code VS2008 showed message box describing "The source file is different...".
Debugging works good before day before tomorrow, but it isn't now. Does somebody know "magic checkbox" for resolve my trouble? Any idea?
Update1: Provider assembly is adding to GAC on post build step. Compiler didn't find errors in solution.
Update2: Source code of static referenced assemblies is "different" too.
Update3 and last: I've found source of trouble. I use x64 version of Windows 7. My application use some COM servers (usual native x32 COM Servers) that can't be loaded in x64 context. So I decided run it as x32 app using WOW so I set platform target as x32. But debugger started show messages like "The source file is different....". I don't understand why it works as works. I will write to microsoft support team.
You can tell it to ignore the problem by going to Tools, Options, going to the Debugger section, and unchecking Require source files to exactly match the original version.
To solve the problem, check your assembly locations. Your program is probably referencing a different version of your provider DLL than the one in the debugger. Try removing the reference and adding a Project Reference.
EDIT: Try removing the provider from the GAC (manually or at the beginning of the post-build step)
“The source file is different…” message in Visual Studio 2008 is result of debugging x32 apps on x64 Windows. See new thread
If you are using Visual Studio Express, you probably don't have Build->Clean Solution.
Try to remove the pdb debug file located in C:\Users\yourusername\Documents\Visual Studio 2010\Projects\yourproject\yournamespace\bin\Debug.
If you are afraid to delete the file completely, i would move it to a temporary folder.
Then try Debug->Start Debugging(F5)
Happy coding!
Try doing a clean (Build-> Clean Solution), and then rebuilding All (Rebuild Solution).