I found Vb6 tools package and deployment. I used it and created a package or setup file from my running vista operating system. Later when i tried deploying it in clients computer with winxp, it asks for update of system file and ask to restart. The process never ends just ask for update and restart. how should i create setup file to avoid this problem?
Edit:
If i create setup file in Win98 and deploy it in clients Vista or winxp then it runs fine...
There is a very good chance you are trying to deploy system files that you shouldn't. Typical examples include MSVCRT components.
You receive multiple "System files are out of date" error messages when you install a Visual Basic 6.0 application
Using Win9x can mask the problem because ancient versions are packaged. During installation either setup1 will detect that newer versions are already in place or Windows will fend them off via System File Protection. Vista is much better at this than XP was.
Yes, the PDW is old. For that reason you should seek out the MSKB articles on usage tips, newer information, and on manually updating the files PDW uses as guidance (its REDIST folder, VB6DEP.INI and the .DEP files that accompany many controls).
Best practices for deploying Visual Basic 6.0 applications is a good generalized starting point.
Many of these sorts of issues have been answered over the years since VB6 and the PDW were released.
The VB6 package and deployment tool is really dated. It doesn't play well with some of the new security features.
It's probably trying to install old copies of the VB6 runtimes and then Windows is restoring its own copies.
It's been a while, but can you remove the VB6 runtime files from the files to deploy in the Package and Deployment Wizard? If so, do so. As long as the computer being installed on has the latest service packs it will already have the VB6 runtimes on it.
If that doesn't solve your problem then check what other system files your deployment project has in it. In most cases you won't need to deploy any system files as modern, patched systems should have them all. There are a few activeX controls that may not be on modern systems, but those shouldn't cause these endless restart problems.
Alternatively, try another install technology. You could create a setup project in modern versions of Visual Studio. Alternatively there are some very good open-source and commercial products.
I've used this one quite successfully in the past:
http://nsis.sourceforge.net/Main_Page
Related
I am upgrading Visual Studio and it's 14 gigs in size. My worry is with my internet connectivity.
If my connection fails, would it start afresh or continue with what's not loaded in the system?
I know this isn't a programming question but I would appreciate your help.
I can't give you a definitive source, but in my experience the VS installer simultaneously downloads and installs its components. The already downloaded components are locally stored (I think even in the directory from where you start the installer) and will be re-used if you cancel the installer and restart it. That way you could even share the downloaded files among multiple computers.
However, as state in the comments, there are offline installers available. If your connection is wonky, the web installer might even be a better bet since your ISO or whatever may or may not be resumed if partially downloaded.
I'm trying to install Visual Studio 2005 on a Windows 7 box but am repeatedly getting the same error. When I run the installer it starts to run then pops up with a message saying:
"A problem has been encountered while loading the setup components. Canceling setup."
Various suggestions has said that maybe the install is corrupted so I downloaded a fresh copy of the ISO from MSDN today, same issue. Another suggestion is that installing from the ISO may be the issue so I extracted the contents of the ISO to a folder on my HDD, same issue. I have also tried running the files as administrator and in XP compatability mode, same issue.
Searching for this issue the most common responses I've found have been about installing SP1, however I cannot get the base product to install and therefore cannot apply SP1.
Does anyone have any further suggestions as to what I can do to fix this issue and get VS2005 installed? If anyone wants any log files of any variety I am happy to supply so long as you tell me where to look as I'm not sure.
As for why I am using VS2005 and not a newer product, it is required for the ongoing support and maintenance of some older applications we manage. These cannot be easily migrated to a newer version of Visual Studio without some considerable investment of time and that would probably be longer than the time it will take to develop newer, replacement applications (which is currently in progress). Until the new applications are available though we need to maintain an environment to use.
Did you try running setup.exe in compatibility mode with Windows XP? Some discussion here on how to do this.
Another alternative since you alluded to having an MSDN subscription. Download Windows XP and install it into a VM. (If HyperV isn't already in installed with your Win7, you can add it from Control Panel->Programs&Features->Turn Windows Features on/off). Then install VS2005 from there.
The question is at the end - let me start by posing the context:
One of the problem we are facing at work when using Visual Studio is to make sure that everybody on the team is using the same version of the SDKs.
A typical problem would be to have somebody use a different Direct X SDK version resulting in a different behavior of the code, or somebody upgrading to a more recent Platform/Windows SDK in order to use some new API and having the code fail on other's programmers machines if they still use the previous version.
A way we used to solve the issue for other middleware has been to put the whole set of libraries, include files, tool chains, etc... in our source control system, and have our projects to use these so nobody has to install anything.
We also managed to do that with earlier version of the Direct X SDK, but we always ran into issues with the Windows/Platform SDK due to the close links between the SDK and the toolchain.
Since we now have to support both VS2010 and VS2012, and have to support from Windows XP to Windows 8 targets, we have to support v100, v110 and v110_xp toolsets.
This means that we need all the associated compilers and the corresponding SDKs, both on our developer machines and build systems: This is getting ridiculously costly to maintain, specially considering that random windows updates and .net framework releases routinely tend to break msbuild.
So the question is:
Is it possible to have Visual Studio to use non installed toolsets and SDK and instead having it use whatever is available in some folder out of the normal VS installation locations?
Bonus question: If it is doable, is it possible to do that without having to change any locally installed configuration file on the machine - ie: Have all that in the solution/project or property sheets - so if we change the structure on the source control system we don't have to update every single machine?
Thanks :)
This sounds too complicated, given how complex some of these tool installations are. I would solve this problem by investing in some PowerShell scripts that look at the installed tools and tool paths and "police" the installations. It would be relatively easy to check for installed versions of everything, including patches and updates. You can run those nightly, or as part of a build. Also, you can compare aspects of different installations, such as the tool versions installed on a developer box with your build server.
This would give you 90% of the value for 10% of the pain.
The problems you describe are not solved with your approach. What you actually need is a build server and a definition of done including using binaries built with the build server. You also need a test suite as part of the build definition with some invariants related to the build environment used.
I have a vb6 application installed on a server. It works perfectly.
I am trying to relocate it to a different server, however I get an error: "Component: TABCTL32.OSX or one of its dependencies is not registered". TABCTL32.OSX does not exist on this server.
On another Windows 2003 server I get a different error saying another component is not registered. I read somewhere that VB6 is not installed by default on Windows Server 2003 and I read somewhere else that it is. Is there a way to see if it is installed? I am unsure what to look for in Add/Remove Programs. Do I need to install this: http://support.microsoft.com/kb/192461?
As suggested by the topic Windows Server 2003 includes a new version of Msvbvm60.dll this OS certainly does include the VB6 core runtimes. However it is not guaranteed to have the base subset of auxiliary VB6 libraries Microsoft began calling the "Runtime Extended files" in Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8.
In any case tabctl32.ocx must always be deployed anyway since it isn't included there.
The package described in VBRun60.exe installs Visual Basic 6.0 run-time file that you provided a raw link to is a sort of kludge and in any case is only meant for older versions of Windows (NT 4.0, Win9x) in the rare cases where you'd use it.
The VBRun60.exe file is not intended to replace the Package and
Deployment Wizard (PDW) for distributing Visual Basic applications.
For that matter it doesn't contain or have anything to do with tabctl32.ocx anyway.
Essentially what you are asking is not a development question and isn't appropriate for StackOverflow. It is an administrative issue more appropriate to somewhere like ServerFault instead.
If you aren't deploying this application using a proper installation package then that may loosely be considered a development issue, though it still really isn't.
Redistribute and register tabctl32.ocx in your setup.
If you do not have a setup, copy that file - preferably into (32 bit) windows\system32 folder or into the application's folder and issue the command regsvr32 tabctl32.ocx from within a command prompt with administrative privileges.
I'm looking for Qt packager for my Qt application targeted for windows platform.
I need it to create a nice installer to deploy and distribute my product on windows PC.
Which is best and recommended FREE packager?
For packaging I use the WIX (Windows Installer XML) toolset.
There are several advantages to using WIX:
Free and open-source
Creates MSI files, which allows your application to be easily deployed across large networks and correctly uninstalls (also very important)
Supported and developed by Microsoft, it is used by several other Microsoft teams internally, e.g the Visual Studio 11 Developer Preview installer features some of the latest WIX features
XML configuration allows reuse of components of installers (sets of files, feature sets)
Several types of user interface, new wizard pages can be created
Integrates into Visual Studio
Integrates into MSBuild - can allow consistent packaging to ensure you don't ship debug versions
I have used WIX for installers at work and for my own projects at home.
It isn't as simple as other solutions to get started, but once you've created a simple package, you'll find it easy to add new features.
NSIS is the way to go in my opinion. Straight forward scripting, compatible with all Microsoft Operating Systems and with support for User Levels.
Plus it has a huge active forum for any specific help you may need. I use the HMNSIS editor to write the scripts and have not come across anything it hasn't been able to do yet!
Qt has nothing that can help you, but the free Windows installer package creator is without a doubt NSIS
Inno Setup is a another good, free, light-weight installer system.
There is the Qt Installer Framework. That is a link to the manual for it. It is multi-platform. With it, you write XML files in a directory structure for delivery of components in the directories, called packages. It has scripting. You then compile it into a setup for your target platform.
Correct me if I'm wrong, but I was under the impression that they did not make it available to users of the Community edition until recent versions. When the earlier replies were written, it may well have been commercial version only.
Alas, nothing seems to warn you that you have to collect up components, nor tell you what they are, or even talk about the process; except that the 3rd. party, but free (Windows only), Dependency Walker can tell you what dynamic libraries are being used. I don't find it a necessity, but it can be helpful. (Tip: On Windows anyway, be sure to put "qwindows.dll" in a "platforms" directory with the exe. Tip #2: Make sure the Qt DLL's or static libraries are ones compiled for your compiler.)