How do I install zlib?
I'm having a major headache trying to get zlib working on my computer. I need it for setting up a SFML Tiled map loader, but don't really have a clue what I'm meant to be doing.
I've read the brief documentation that came with the zlib DLL download, and have put the zlib1.dll in my System32 folder, but the test programs that came included with the download keep giving me "The program can't start because zlib1.dll is missing from your computer. try reinstalling the program to fix this problem." errors.
I think I've set it up right in Visual Studio 2012 as I get no compiling errors, just that error when I try to run the program.
They work fine when I copy the .dll into the same folder as the .exe. Why does what I read about installing zlib tell me to put the dll in System or System32? What is the System32 folder even for?
Will I have to pack the .dll in with any programs that I make? Can zlib be statically linked into my program?
I had a look around before asking but all other questions I found were too specific to be useful for me. D=
Related
we are using NSASS to compile our Sass files to css ( https://github.com/TBAPI-0KA/NSass ). NSASS is set up and working great in development environment. But when we try to deploy it to our testserver we are unable to get NSASS up and running.
We keep getting
Exception information:
Exception type: FileNotFoundException
Exception message: Could not load file or assembly 'NSass.Wrapper.x64.dll' or one of its dependencies. The specified module could not be found.
at NSass.SassCompiler..ctor()
at NSass.SassHandler..ctor()
The problem is that NSASS uses some dynamic way to load these dlls, that does not seem to work. The dll is located in \bin\NSass.Wrapper but fuslogvw is logging that it only tries to search the bin directory. The dynamic way of loading this dll is made so that it loads the x86 or x64 depending on the OS if I understand correctly.
For the bin loading code of NSASS: https://github.com/TBAPI-0KA/NSass/blob/master/NSass.Core/AssemblyResolver.cs
I have tried moving the dll files (both X64 and x86) to bin folder but I get the same error looking in event viewer even if the fuslogvw says that all is ok.
Anyone have any tips on what I can do as a next step to try and solve this?
Edit:
Tried logging AppDomain.CurrentDomain.SetupInformation.PrivateBinPath and it points to the bin folder as it should and AppDomain.CurrentDomain.BaseDirectory points to the correct folder aswell. Not sure if anything change the CurrentDomain from Application_Start where I log until the Assembly Load of the NSASS files.
Also worth noting. This is an EPiServer web so not sure if EPiServer changes anything. But if so shouln't it be problems in the Dev environment as well?
I finally found the issue!
After using DependencyWalker to analyze the dlls of NSASS I found that the server did not have the correct version of C++ Redistriburable.
So after installing that all works fine!
Hope this helps other people with the same issue.
We had the same issue but the fix ended up being two things.
Installing Visual C++ Redistributable Packages for Visual Studio 2013 onto our servers.
can be downloaded here
Changing our compiler to libsass-net using nuget, it seems very similar to NSass (github).
I need to update an existing DLL file that is already in use for our client-software that is installed on 400+ computers. This DLL file exists today and is already registered with regsvr32.exe when the software was installed.
The problem is that I cannot easily run the regsvr32.exe command without changing the entire update process, which is a mayor hassle as it is ancient and no documentation exists on it.
So I wondered if I actually have to re-register the dll file, or if replacing the file is enough. I tried searching for more information on this, but so far came up blank.
It depends on how you created the DLL.
If you broke the binary compatibility you must re-register the DLL using regsvr32. If you mantained the binary compatibility copying the new DLL should be enough.
VB6 had an option called "Binary Compatibility" which helped to deal with these issues (http://msdn.microsoft.com/en-us/library/aa733715(v=vs.60).aspx). I don't know if VC++ or VS.NET provide something similar.
Greetings,
edu
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I am just working on my bachelor thesis... It is a VST plugin (DLL library), which have dependency on libfftw3-3.dll (FFT library). When testing on my Laptop (64bit Win7 ultimate), i found a problem... I cant import this VST to any of Music Studios...
As on my PC, i have copied VST plugin dll and libfftw3-3.dll in the VstPlugins directory, but when i try to import this VST, system tells me that libfftw3-3.dll cannot be found.
This is not COM object, so i cant register it using regsvr32...
Can you please help me, what i am doing wrong? And how i can get this to work?
A VST is a COM component. It is loaded by the client program , the underlying call is CoCreateInstance(). The problem here is that Windows will only look in the directories that are relevant to the client program for the DLL you use. You surely didn't copy the DLL into the directory of the EXE, nor should you.
This is a generic problem with COM, solving it cleanly isn't easy. The Windows side-by-side cache is a solution but you'll graduate before you get that sorted out. You can punt the problem by modifying the system PATH environment variable. Or the desperate move, copying the DLL to c:\windows\system32 (syswow64 on the 64-bit version of Windows). Just to get you graduated, mind you.
If you still have trouble then you might have additional dependencies you don't know about. The CRT dll is a typical one, you'll get that when you compile your code with /MD in effect. You can chase those dependencies down with SysInternals' ProcMon utility, you'll see the client program searching for the DLL. Or DependencyWalker in Profile mode (F9).
I have a mex64 dll compiled on my machine. I used Matlab 2009b with VS2008 Pro to compile the dll. The dll works fine on my Matlab installation.
I want a colleague to use the dll so I sent it to him and he gets the following error message when trying to use the dll:
??? Invalid MEX-file 'filename.mexw64': The specified module could not be found.
My current assumption is that this is caused because he uses an older Matlab version or missing a dll that I have. I ran dependency checker and asked him to check that he has all the listed dlls.
I am still waiting for him to confirm his Matlab version.
What other reasons can cause this and can the Matlab version make a difference? (I mean R2009a when I have R2009B and not a huge version diff)
The other person has Matlab R2009a. Shouldn't the mex just work if I compile it on my computer and deliver it to him?
Does this only leave a missing dependent dll?
The issue is strange, but I can confirm it exists.
Using pre-built libraries for matlab that are correctly installed and in the path, I sometimes get the same error. If I type in the function name at the command-line, the function is visible and will auto-complete. However, the function will not initialize until I 'cd' into the directory with the .mexw64 library file.
>> AndorInitialize('')
Invalid MEX-file 'C:\Program
Files\MATLAB\R2011b\toolbox\andor\AndorInitialize.mexw64': The
specified module could not be found.
>> path
MATLABPATH
C:\Program Files\MATLAB\R2011b\toolbox\andor
C:\Program Files\MATLAB\R2011b\toolbox\andor\camera files
C:\Program Files\MATLAB\R2011b\toolbox\andor\m files
... etc
It turns out this is due to missing dependencies, which shouldn't be missing. To resolve the issue, use dependency walker (free, lightweight) to identify what's missing. The mathworks explains this.
http://www.mathworks.com/support/solutions/en/data/1-2RQL4L/
In my case, two DLL's weren't showing up properly, even though they were on my system and in the path. I copied the DLL's into the windows/system32 folder and the library functions now work correctly. What's particularly strange is that the same library worked on my computer a few days ago (prior to the moving the DLL's).
In general, MEX files should work across different versions of Matlab; in particular, they should be forward-compatible. You're right; sounds like a dll problem.
If you built it with Visual Studio, it may be linked to the Visual C++ Runtime. This is a set of libraries that is not installed on Windows by default. The "redistributable" for it can be downloaded here; having your coworker install that could resolve the problem. If that doesn't work, you can use Dependency Walker to check for other unsatisfied DLL dependencies.
Normally, configuring Matlab's "mex -setup" to use the Lcc compiler that's distributed with Matlab could be a way around this, but it's not supported for 64-bit Windows AFAIK.
Also, are you sure he has the 64-bit version of Windows?
Another possible source of the problem could be that you compiled in debug mode. The Visual C++ redistributables only support release mode.
The Dll was a wrapper for MySql access. We ended up using Matlab's ODBC and the MySql Connector.