I have a program which is written in VB6 and runs in many PCs with different windows versions, without any problem.
But in some PCs it does give me the error:
failed to activate control 'vb.usercontrol'. this control may be incompatible with your application
I register OCX files which are needed by my program.
I don't know if it's related to being a 32bit or 64bit OS or not.
I'll be happy to know your answers. Thanks.
I've found the problem and the solution :
There is an ocx file which has two version, and my program has been built with the new version and some PCs had the old version.
so there was a mismatch between two files.
Now, I replaced the old ocx with the new one and the problem solved.
Related
I notice that Microsoft Visual C++ runtime libraries are duplicated all over my computer, eg: at the following locations:
C:\Windows\System32
C:\Windows\SysWOW64
C:\Program Files\Common Files\microsoft shared
C:\Program Files (x86)\Mozilla Firefox
C:\Windows\WinSxS\amd64_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_b157f27efd203c73
C:\Windows\WinSxS\x86_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_553956fb44c2cb3d
Why is this? I thought a specific .dll could only be registered ONCE with windows? Is that not the case? Can you really register the same .dll from multiple locations?
I uninstalled an old version of Skype which had the C++ .dll's in its own folder. But doing so caused a whole load of other programs to break (eg Adobe Acrobat, etc). I fixed it by repairing the C++ 2015 redistributable from Control Panel's Programs & Features window. But while checking the damaged files were re-created and re-registered, I discovered so many versions. How do I know which one is registered with Windows?
If I wanted to write code that referenced those .dll's, which one would it use?
I found a hint of reason for this in this article.
Consider this scenario: you install program “A” and it uses library
version 1. You then install program “B” and it also uses library
version 1, so it doesn’t need to install it – it can just use the copy
that’s already there courtesy of program “A”. Now you uninstall
program “A”. Three things can happen:
It uninstalls the library because it installed it and it should clean
up after itself, not realizing that another program relies on the library. Program “B” breaks as a result.
It never uninstalls the library because another program might be using it. As a result, libraries check in, but they never leave.
We devise some method of tracking how many installed programs are using the library, and only remove it when the last one is uninstalled. Unfortunately, any single program’s failure – be it a programming error or a failure to install or uninstall properly – breaks this technique. At best, you’re left with copies of the library you no longer need, and at worst, uninstalling one program can cause one or more other unrelated
programs to fail.
It’s a mess. In fact, it’s such a mess that most
programs now don’t bother to try and share at all.
Putting Your Fate in Someone Else’s Hands:
Ultimately, application vendors realized that by relying on shared libraries like this, they were putting their fate into the hands of every other application that happened to use the same version of the same library. If only one of them made a mistake, and the library was accidentally removed or updated when it shouldn’t have been, it put all the others at risk.
So, application vendors typically now install their own copy of the
library that they manage and that they can rely on. Disk space is
cheap – much cheaper than the errors and frustration that were
happening when they tried to share.
So now, on my machine, many different applications all carry with them their own copy of the Microsoft Visual C++ Runtime.
And each is more stable as a result, by virtue of being in control of
their own destiny.
However, it remains unclear how dll files can be registered with the same name but from different locations. I did not think this was possible, but perhaps it is.
I have been a long-time visual studio developer, and I am trying to switch over to using mono so I can port my applications to Ubuntu. I have been trying to get some of my VS2010 C++ projects (.vcxproj file types) to load into MD on my Ubunutu 12.04 machine. According to the documentation I have read online this should work, however, every time I try and load a project I get the error shown below. Is there something else I need to be installing in order to be able to load C++ projects in monodevelop? I have done some searching, but have not yet found anything related to this particular question.
VC2010Test.sln(4): Unsupported or unrecognized project : '/home/me/Projects/Test/VC2010Test/VC2010Test.vcxproj'.
Thanks
MonoDevelop has a C/C++ binding, called CBinding.
But:
Beware, it's not meant to target managed C++.
AFAIK, it only works in Unix-like platforms.
So, if you still target non-managed C++ and are not using MonoDevelop for Windows, two questions:
Did you make sure that the binding (addin) is installed and enabled?
If the answer to the above question is yes, you may want to try this: the binding creates projects with the extension ".proj" by default, I think, so maybe you can change this to ".vcxproj", recompile, and test again. If it works, then it should be easy to create a pull request to include this extension of possible file types that this addin can handle?
Here's my issue: I wrote a VBA class module that consists of commonly used methods and functions. I am continually refining the module and making changes to it.
The problem is that I include this module in almost all of my VBA projects and I really don't want to keep importing the new module into each project everytime a change is made.
My question(s): Would it make sense to create a DLL that all of my projects would link to? Or is there an alternative solution that would make more sense?
Thanks
If you're going to create a DLL, which I think makes perfect sense, you might want to do so in a language built on the .NET framework, such as VB.NET or C#. This provides the ability to combat the 32bit and 64bit issue by building both 32bit and 64bit versions.
It's worth noting that a 32bit DLL running on Windows 64bit with Office 32bit will function just fine. It's when the user is running Office 64bit that you need to worry.
With regards to deployment, you could spend a little extra time to create an installer (using NSIS for example) to make deployment much simpler. This installer would serve the purpose of registering the DLL on the target machine. You could also make the installer install both 32bit and 64bit versions of the DLL to guarantee the DLL will be compatible, regardless of the users configuration. I like the idea of registering both bit versions to avoid the scenario where a user has a Windows 64bit/Office 32bit environment and decides to upgrade their Office version to 64bit. If you have the 64bit version already installed, the reference to the DLL will resolve correctly.
when i try to run a application developed in vc++ on windows7,i get popup window saying that"the program can not be started because MSVCR80D.dll is missing from your computer,try reinstalling the program to fix this issue."
I googled it,it says that this DDL may not be present in your system or it has been got corrupted,Now i searched this file, i get this file at 20 different folder in win7.
I am not getting which file has been corrupted or if it is missing then where it is mising?
can anybody tell in which folder ,this DDL is missing or might be corrupted?
Thanks in advance. .
You're trying to run a Debug version of your program on a machine which does not have VS installed. The MS*D.dll files are not redistributable - they are installed were VS is installed. If you want to run executables on other machines, compile them as Release. You might still need to deploy some files (depending on how you're linking to the CRT), but that won't be a problem.
Never ever distribute your DEBUG builds to customers. Always distribute Release build.
Yes, of course, in develoment environment having multiple machines, you may share Debug builds to other developers - provided others developers have debugging-tools (like VS) installed on their system along with Debug-binaries of shared DLLs (like MSVCRxx).
Are you using the same computer that compiled the program? If not, you need visual studio redistributable files to run it.
Search the internet for your version of visual studio or visual c++ redist, you'll find it.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.