Related
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 developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!
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.
I have just installed a third party app on my Windows Server 2008 server
and I get the
ActiveX Component can't create object
message when I try to access using a CreateObject in VBScript.
It is definitely installed and exists under "Programs and Features". Does anyone have a list of things that I can check to figure out what is going on?
I have now tried to register the DLL using regsvr32.exe /i bob.dll as suggested but I get this error:
The Module "Bob.dll" was loaded but the entry-point DllRegisterServer was
not found.
Make sure that "Bob.dll" is valid DLL or OCX file and then try again.
I should note that this is a 32-bit application on a 64-bit machine at
this point. It also works fine on my machine which is Windows XP 32-bit.
It turns out to get this application working under VBScript, I had to do two things.
Run RegAsm.exe to register the DLLs.
Run the C:\Windows\SysWOW64\cscript.exe to run my VBScript.
If these don't work, check out the other answer here about enabling 32-bit applications in IIS.
It's also worth checking that you've got "Enable 32-bit Applications" set to True in the advanced settings of the DefaultAppPool within IIS.
The app is trying to create a COM Object and even if that COM DLL exists, it may depend on another DLL which isn't installed. You can use DependencyWalker to find out if this is the case.
Check your browser settings.
For me, using IE, the fix was to go into Tools/Internet Options, Security tab, for the relevant zone, "custom level" and check the ActiveX settings. Setting "Initialize and script ActiveX controls not marked as safe for scripting" to "Enable" fixed this problem for me.
Also when you register the component make sure you use the 32-bit version of regsvr32.exe.
If you simply run regsvr32.exe in a elevated prompt, it will default take the standard 64-bit version (which oddly enough is located in C:\Windows\System32)
The version I believe you need is located in C:\Windows\SysWow64\regsvr32.exe
It really looks as though the object you are referencing is not registered on the system. I know you said it's installed, but that doesn't necessarily mean it's registered. To confirm this, search for the progID that you used in your registry.
Example for this code:
set objFSO = CreateObject("Scripting.FileSystemObject")
I would search for Scripting.FileSystemObject in the registry. Then I would look at registry key above the found value, for InProcServer32 value. This will give you the path to the ActiveX file that it was registered from (for Scripting.FileSystemObject the file is "c:\windows\system32\scrrun.dll").
If you can't find your progID in the registry, then it's not registered on your system which is your problem. If it's not registered you need to find out what file registers it, which is usually an .ocx or a .dll in the same folder path of your third party app, and then register these file(s). Here is the command to register a file:
regsvr32 /i "c:\windows\system32\scrrun.dll"
Even if you find the progID value in the registry and it references a file that is present on your system, you may still want to try re-registering the file. I have found that sometimes the registration got broken somehow somewhere and it was easier to re-register the files then it was to fix the issue.
If its a 32 bit COM/Active X, use version 32 bit of cscript.exe/wscript.exe located in C:\Windows\SysWOW64\
I know this is an old thread, but has anyone checked if their Antivirus is blocking Win32API and Scripting on their systems? I have CylanceProtect installed on my office system and i found the same issues occurring as listed by others. This can be confirmed if you check the Windows Logs in Event Viewer.
I also meet the same error in vbscript.
Set objFSO = CreateObject("Scripting.FileSystemObject")
Solution:
Open command line, run :
regsvr32 /i "c:\windows\system32\scrrun.dll"
and it works
I've had the same issue in a VB6 program I'm writing, where a Form uses a ScriptControl object to run VBScripts selected by the User.
It worked fine until the other day, when it suddenly started displaying 'Runtime error 429' when the VBScript attempted to create a Scripting.FileSystemObject.
After going mad for an entire day, trying all the solutions proposed here, I began suspecting the problem was in my application.
Fortunately, I had a backup version of that form: I compared their codes, and discovered that inadvertently I had set UseSafeSubset property of my ScriptControl object to True.
It was the only difference in the form, and after restoring the backup copy it worked like a charm.
Hope this can be useful to someone. Up with VB6! :-)
Max - Italy
I had the same issue with Excel, I was trying to use a 32 COM DLL with an Excel 64 bits version and I got this error. I rebuild the COM dll to a 64 bits version and the error disappears. So be sure that your COM dll has the same architecture (x86 vs x64) than your application.
I had this problem too. I was trying to run an old 32-bit dll in a 64 bit system. I got it working by copying the .dll to the C:\Windows\SysWoW64\ directory and running this:
%systemroot%\SysWoW64\regsvr32 "C:\Windows\SysWoW64\thenameofyourdll.dll"
And also enabling IIS to run 32 bit apps