I've inherited a VB6 project that I'm trying to "Make".
The build fails on the "Making EXE" step with a licensing error:
License information for this component not found.
You do not have an appropriate license to use this functionality
in the design environment.
How can I figure out which component is missing the license?
The project has about 15 references; a mixture between commercial and Microsoft. I've installed development versions / licenses for all the obvious references - and checked that I can compile their sample apps successfully.
Of the remaining 13 odd references; how I can get more information as to which component is throwing the licensing error?
Any tips / techniques on how to get a more verbose error message would be greatly appreciated!
It's worth trying both the Microsoft fixes - one and two - for this error, in case you've run into one of the known issues.
If that doesn't work, open the form designer for every single form in the VB6 IDE. Look out for an error message box on displaying a form. When this error is displayed, the IDE writes a log file formname.log that gives more information on which control caused the problem.
Create a new, empty application with all the same references
Confirm that you still have the same problem
Delete the second half of the references
If you still have the same problem, then the problem is with the references which remain. Go to 3
If not, then the problem is with the references you deleted. Put them back. Delete one half of those you put back. Go to 2.
Basically, just a binary search, except it's really "binary delete".
All of the links of all of the answers are broken... And, some of us are still trying to either maintain or convert old VB6 applications (or both).
A somewhat useful tool was Process Monitor by Mark Mark Russinovich of Microsoft (it is sourced directly off of Microsoft.com and has been around for years). It allows you to monitor all resources used by the computer system wide, and allows you to filter that down to individual resources, processes, etc.
The useful bit is to start the program, and click the "Filter" button from the toolbar (Ctrl-L). From there, you need to add a rule. Select Path that begins with and that should be to the value "HKCR\Licenses". That is in the HKEY_CLASSES_ROOT section, where the Active-X components licensing information is. These should be set to Include.
Click Ok, and then click Clear on the toolbar (Ctrl-X) to clear all current events to reset the state. Events should already be populating that match that rule.
Then, invoke your build. To cut down on clutter, I used the command:
"C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe" /make <project file> /outdir <exe dest dir>
Once the compile runs, the build should fail with the same message, but simply open the Process Monitor, and you can see that last key that tried to read and failed. The UUID that says not found is the UUID where the license should reside.
From there, you can:
If your license allows, copy that value from a working PC and install it into the failing PC.
Google that ID, to see if there are instructions on how to obtain the correct
license (such as install it from one of the .REG files from the installation media)
Obtain and install the license some other way
While it doesn't tell you exactly what component corresponds to that UUID, it at least lets you get the specific UUID that is failing, which is further than any of the other current answers can do in their current state.
Try This
http://support.microsoft.com/kb/194751/EN-US
It will fixed VB6.0 Design Time License
Related
When i try to start one application (for instance application A.exe) error was throwing from already installed msi file (for Ex: B.msi) as "The feature you are trying to use is on a network resource that is unavailable or enter an alternate path to a folder containing the installation package 'B.msi'"
I have read some articles related to this error but all of them explaining if installer have any issues (if file have been damaged, deleted, moved, or quarantined by an anti-virus application) this error will occur but here when I try to launch one application then it is showing above mentioned error with another package name (B.msi) which I already installed.
Please let me know the cause of this issue it would be helpful to trace out this issue.
Note: For older version of our application don't have this issue (For creating installer earlier we have used Wise tool now using WIX tool. Is there any issue with WIX installer?).
Self-Repair Problems: This is generally a self-repair issue. I have written more times about this than I care to count, I'll see if I can send you here: MSI self-repair - the scourge of society.
Explanation: What is actually happening is that your installation goes through an integrity check when launced via an advertised shortcut, and a resource is found to be missing. The MSI will then try to repair itself (self-repair), but it is unable to find the required source files to retrieve the file it needs to reinstall - since the source files are no longer available at the location where you installed from. It is a good idea to install from a permanently available network location using administrative installations - especially for corporations.
Missing Source Files Resolution: In your case - to sort out the missing source files - you can either uninstall and reinstall (uninstall should not need source access in normal cases), and then preserve the installation files at a permanently available location (solving the problem for the future), or you can browse to the installation source when you are prompted to do so for your current installation (and there are some ways to automate setting new source paths). The installation source must be the one used to install the software originally (unless you know how to hack it, which is very involved).
Self-Repair Resolution: To sort out the actual self-repair conflict, you essentially need to find the culprit component causing the repair in the event viewer and then find some way to resolve the situation. All linked or explained in the above answer (repeated here). Proposed "real-world solutions" can be found in section 5 here: What do I do when launching an application triggers repeating, endless Windows Installer self-repair? As a workaround, you might want to try to launch the EXE files in question directly, to verify that the self-repair does not happen (generally this will prevent the self-repair, but it can still happen if there is a COM conflict or some other advanced conflict).
You can see a list of "Primary Cause of Self-Repair" some way down in this answer: How can I determine what causes repeated Windows Installer self-repair? (bad MSI packages with conflicting resources - COM conflicts?, security software quarantining files unexpectedly, cleanup scripts wrecking havoc, etc...). I would recommend you skim this list for ideas.
Uninstall Problems: This "installation source not found" problem can also occur so it prevents uninstall in special cases. Here is an answer which tries to summarize aspects of this problem: Powershell Silent Uninstall "Microsoft Report Viewer Runtime 2012" (somewhat too elaborate, but worth skimming I think).
Some Links (for reference and easy retrieval):
Installshield 2013 Installscript MSI: Wrong .msi location during Repair
Wix / MSI : Unable to uninstall
Uninstall without an MSI file
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
This should be pretty simple, but I can't seem to get it. I have a setup project (VS2010) that packages a few dozen image files (along with my SQLite file) and copies them to the user's computer when the program is installed. As these are essentially "stock" images, it's ok if the user deletes them (there is functionality to do so from within the program.) However, after one or more of these images have been deleted, the next time the program starts it gives a "Windows installer" dialog box, and deletes all of the remaining data files!
What I think is happening is the program sees the missing files, assumes the installation has been corrupted, and tries to go into some kind of recovery/uninstall mode. I'd like to know how to indicate in the setup project that the files need to be installed, but may be removed by the user at any time.
I have tried several combinations of File properties, and nothing seems to do quite what I want, which is for my installer to put them where I say and never think about them again. Do I have to reinvent the wheel and do this through a custom action??
EDIT: Transitive and Vital had both been set to True. Setting them to False causes the program to re-add the deleted images back after it has been restarted! I'll probably go with a custom action if I don't get an answer.
When using a file association or advertised shortcut Windows Installer automatically checks if component key paths are missing. If a key path is not found, a repair is trigger to reinstall the component.
Most likely your installer repair process does something that removes the other files.
A solution is to not register your components with Windows Installer. This is done by using a null component GUID and it's not supported by Visual Studio setup projects (it is however supported by most of the other setup tools).
Another solution is to make sure that your image files are not key paths in their components. This is also not supported by Visual Studio.
If you want to use a setup authoring tool which offers more control, you can take a look at this list: http://en.wikipedia.org/wiki/List_of_installation_software
I build an executable which is dynamically linked to several DLLs. Most of these are installed by default on Windows, but maybe with slightly different versions. Others I distribute with the app, but they in turn may depend on other DLLs.
If I run the executable locally and get the Windows error message saying that "Failed to load [whatever]. The application configuration is incorrect" it seems to mean that a library that 'whatever' depends upon is missing. But it (rather infuriatingly) omits to specify exactly which DLL it was having trouble loading. Sometimes I can work this out by using Dependency Walker to see if there are any libraries that are obviously missing. Other times, I can resort to Process Monitor which can show me which file Windows was looking for prior to issuing the error message.
But these aren't tools that are reasonable for an end-user to have to use, when trying to diagnose their problem. Is there any way of coaxing Windows to say precisely which library it is having trouble resolving, so that this can be output to a log or displayed in a message box?
In my experience, a common cause of this kind of error is accidentally shipping a component that was linked against the debug version of the C runtime, which is explicitly not redistributable, and so it is only on an end user's system if they happen to have the matching version of VisualStudio installed. It will have a name that looks something like MSVCR80D.DLL instead of MSVCR80.DLL.
Dependency Walker is certainly the right tool to use to check your executable as a developer. It can hook the application for DLL load events and run it, so you can discover DLLs that are dynamically loaded at run time as well as the DLLs that were named at build time.
Dependency Walker is also scriptable, and can write a log file. I use it this way as part of my build process to validate a shipment before packaging for release. I stage all the files to be shipped into a mockup of their delivered directory tree. I use a debug mode of the application hosted by dependency walker that makes it load all its optional bits and pieces then exit. Depends.exe leaves me a nice log file, which I inspect with a Perl script and fail the build if any DLL was loaded from anywhere on the system other than \WINDOWS or the staging area, or if an unexpected version or debug version of the C runtime was loaded. Only after that check succeeds do I build the InnoSetup installer package that will be released. This has saved embarrassment on a couple of occasions and was well worth the effort it took to figure out how to do.
If you know that every DLL is either an "official" Windows DLL or part of your shipment, then you have a really good chance of it all just working on the cusomer's machine.
Edit: The official home of Dependency Walker is a good place to poke around. The version offered there may be newer than the version included with MSVS, and there is a fair amount of decent documentation on advanced uses.
I can confirm that I have run IE profiled under depends.exe, but not tested much at all.
The windows event log usually contains some valuable information after these messages.
In XP, Right click "my computer", select "manage" and go to the "Event Viewer" there, check the system log, look for error messages which appeard about the time when the message box appeared. There should be a few of them. one of them will contain the name of the offending dll.
One technique I find useful is to create an installer project in Visual Studio (even if you don't end up shipping it). Inside your solution, create a new Setup and Deployment project and add the primary output of your project to it, then build the installer. This will do a dll dependency check phase which you'll see listed in the 'Detected Dependencies' section. So if there any dlls that you have omitted you should see them in this list.
Of course, now that you have an installer that's taken only 5 minutes to set up, you could ship that and it will deal with ensuring that the Visual Studio runtimes are setup correctly too.
I'm developing in Visual Studio 2005, using TFS as the source control. Whenever I haven't been working on the solution for a while, I always do a recursive Get Latest in Solution Explorer.
However, this doesn't always seem to work. If I know I don't have the latest version of a file, even right-clicking this (in Solution Explorer), choosing Get Specific Version and ticking the "Force get" box doesn't work.
I seem to need to open up the TFS Source Control window, and there force a Get of the file in question.
Also, the Solution Explorer often has the little "checked out to someone else" icon next to files, but when I check in Source Control, they're not checked out at all!
I'd just like to know if these problems are widespread, whether they persist in VS2008 (I haven't used TFS for a big project in 2008 yet), and if there are any fixes or workarounds.
1) I would not make a habit out of Get Latest from Solution Explorer. Even if it always worked 100% bug free, it is far slower and less reliable than doing it from the command line or Source Control Explorer. SlnExp has to crawl your whole project structure and issue non-recursive calls...pseudo algorithm:
parse sln file
foreach project in sln
TFS_GET makefile
parse makefile
enumerate sourcefiles[]
TFS_GET sourcefiles[]
loop
SCE requires no parsing and issues one single recursive webservice call. In addition to the performance gain, this is much safer:
(a) Build-time dependencies aren't always part of a project's file list. Executable tools, 3rd party assemblies, and deployment scripts are all common examples. SCE will download them, SlnExp won't.
(b) Scoping Get calls down to specific files won't yield the expected result when a file is renamed or moved. At best, the "old" name is deleted from disk; at worst, nothing appears to happen at all. (this may be the cause of the bug you reported) In order for a file to truly be renamed/moved in sync with the server, the old & new paths must both be inside the scope of the Get.
2) There have been many bug fixes to the SlnExp "glyphs" over the years. I won't claim that VS2008 SP1 is perfect in this regard but it is definitely improved.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. Most commonly what happens is that you've made a change to a file, and you want to undo those changes by re-getting the latest version. Well... that's what Undo pending changes is for and not the purpose of Get specific version.
If in doubt:
undo pending check in on the file(s) before you do 'get latest'
do a compare afterwards to make sure your file matches the expected version
run a recursive 'compare' on your whole project afterwards to see what's different
keep an eye on pending changes window and sometimes you may need to check 'take server version' to resolve an incompatible pending change
And this one's my favorite that I just discovered :
check the Output window for messages such as this :
Warning - Unable to refresh R:\TFS-PROJECTS\www.example.com\ExampleMVC\Example MVC\Example MVC.csproj because you have a pending edit.
Yes this critical message appears in the output window. No other notifications!
Nothing in pending changes and no other dialog message telling you that the file you just requested explicitly was not retrieved! And yes - you resolve this by just running Undo pending changes and getting the file.