Uninstall of a VB.Net 2010 program messing up all VB
-
We have programs in VB6, VB.Net 2005, 2008 and 2010. Some of the VB.Net programs were converted from VB6 using the VB.Net converter (Just open the VB6 project). All this is fine until yesterday. We uninstalled a program written in VB.2010 via the control panel. Went fine. But now other programs, VB6, VB.Net 2005 and 2008 are having problems. Now have compile errors and reference errors. We fixed the first. MSFLXGRD.OCX become unregistered (not deleted). Not sure why. We registered it and that fixed some problems. I am not sure why reference to dlls in other program source bin folders were removed. Adding the reference to these fixed them. Now in 1 of our 2008 programs we have an Undeclared MSXML2.XMLHTTP in Dim pXMLHTTPObj As New MSXML2.XMLHTTP This is on Win 7/64 Pro. If we open the same programs on another machine from the same folder there are no errors. So probably another unregistered dll. (XP) This program has a reference to Microsoft XML, V4.0 which is in the obj\bin\debug folder (it is there) and adding it seems to have fixed that also. I am now very fearful of uninstalling anything. Can someone please explain what is happening and how I can safely uninstall????? PLEASE!!!! Thanks
-
We have programs in VB6, VB.Net 2005, 2008 and 2010. Some of the VB.Net programs were converted from VB6 using the VB.Net converter (Just open the VB6 project). All this is fine until yesterday. We uninstalled a program written in VB.2010 via the control panel. Went fine. But now other programs, VB6, VB.Net 2005 and 2008 are having problems. Now have compile errors and reference errors. We fixed the first. MSFLXGRD.OCX become unregistered (not deleted). Not sure why. We registered it and that fixed some problems. I am not sure why reference to dlls in other program source bin folders were removed. Adding the reference to these fixed them. Now in 1 of our 2008 programs we have an Undeclared MSXML2.XMLHTTP in Dim pXMLHTTPObj As New MSXML2.XMLHTTP This is on Win 7/64 Pro. If we open the same programs on another machine from the same folder there are no errors. So probably another unregistered dll. (XP) This program has a reference to Microsoft XML, V4.0 which is in the obj\bin\debug folder (it is there) and adding it seems to have fixed that also. I am now very fearful of uninstalling anything. Can someone please explain what is happening and how I can safely uninstall????? PLEASE!!!! Thanks
It screws up because controls are not registered on a per-application basis. Controls are registered using the COM GUIDs in the controls and the registration is stand-alone. The controls can be used in any application anywhere. If you have multiple copies of the same control, the control is only registered ONCE since each copy has the same GUIDs and CLSIDs. The filepath to the control is also part of the registration. So, if you have an application that uses the same controls as another application and your installer, when uninstalled, removes the registration details when it removes the controls, the registration data is destroyed for the control no matter how many copies of it are on the machine. The problem comes down to how your installer is built. The Setup project that comes in Visual Studio is a barebones installer that doesn't have a ton of features in it and can do some pretty stupid things. If you trust it implicitly, without knowing how it's doing things or why, problems like your will come up. I highly recommend studying Windows Installer technology (specifically Shared Components and reference counting) and using a 3rd party packaging solution, like InstallShield, InnoSetup, Advanced Installer or WiX if you want to avoid situations like this in the future.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
It screws up because controls are not registered on a per-application basis. Controls are registered using the COM GUIDs in the controls and the registration is stand-alone. The controls can be used in any application anywhere. If you have multiple copies of the same control, the control is only registered ONCE since each copy has the same GUIDs and CLSIDs. The filepath to the control is also part of the registration. So, if you have an application that uses the same controls as another application and your installer, when uninstalled, removes the registration details when it removes the controls, the registration data is destroyed for the control no matter how many copies of it are on the machine. The problem comes down to how your installer is built. The Setup project that comes in Visual Studio is a barebones installer that doesn't have a ton of features in it and can do some pretty stupid things. If you trust it implicitly, without knowing how it's doing things or why, problems like your will come up. I highly recommend studying Windows Installer technology (specifically Shared Components and reference counting) and using a 3rd party packaging solution, like InstallShield, InnoSetup, Advanced Installer or WiX if you want to avoid situations like this in the future.
A guide to posting questions on CodeProject[^]
Dave KreskowiakIf figured as much but we have been uninstalling and re-installing VB.Net apps for years. Currently the program the started this is still having problems. Each time I start the IDE for this VS 2010 or re-open this solution has most of it's depencies refrences are not found. Errors Unable to find source file N:\accnt\code\program... for scrrun.dll, mscomct2.ocx, Interop.Scripting.dll, Interop.MSCOMctl2.dll, Interop.Excel.dll, Excel9.OLB, AxInterop.MSComctl2.dll. (in Solutuions If I refresh dependencies then errors go away until the next start re-opening of this solution even if I save the solution. This does not happen on the VB2008 projects even for those using the same components/references. How do I fix this?
-
If figured as much but we have been uninstalling and re-installing VB.Net apps for years. Currently the program the started this is still having problems. Each time I start the IDE for this VS 2010 or re-open this solution has most of it's depencies refrences are not found. Errors Unable to find source file N:\accnt\code\program... for scrrun.dll, mscomct2.ocx, Interop.Scripting.dll, Interop.MSCOMctl2.dll, Interop.Excel.dll, Excel9.OLB, AxInterop.MSComctl2.dll. (in Solutuions If I refresh dependencies then errors go away until the next start re-opening of this solution even if I save the solution. This does not happen on the VB2008 projects even for those using the same components/references. How do I fix this?
Try Save and Close your project, then go out to the project folder and delete the *.SUO files. You'll have to enable viewing hidden files in Explorer to see it. Then reopen your project and see what happens.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Try Save and Close your project, then go out to the project folder and delete the *.SUO files. You'll have to enable viewing hidden files in Explorer to see it. Then reopen your project and see what happens.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThanks. Now I know where that stuff is. It took care of it. Thanks
-
It screws up because controls are not registered on a per-application basis. Controls are registered using the COM GUIDs in the controls and the registration is stand-alone. The controls can be used in any application anywhere. If you have multiple copies of the same control, the control is only registered ONCE since each copy has the same GUIDs and CLSIDs. The filepath to the control is also part of the registration. So, if you have an application that uses the same controls as another application and your installer, when uninstalled, removes the registration details when it removes the controls, the registration data is destroyed for the control no matter how many copies of it are on the machine. The problem comes down to how your installer is built. The Setup project that comes in Visual Studio is a barebones installer that doesn't have a ton of features in it and can do some pretty stupid things. If you trust it implicitly, without knowing how it's doing things or why, problems like your will come up. I highly recommend studying Windows Installer technology (specifically Shared Components and reference counting) and using a 3rd party packaging solution, like InstallShield, InnoSetup, Advanced Installer or WiX if you want to avoid situations like this in the future.
A guide to posting questions on CodeProject[^]
Dave KreskowiakIn researching this it seems that the problem even exists with the 3rd party installers unless a lot of work is done first. So if a lot of work must be done why not just do it with the VS.Net Deploy and Setup project, etc. instead of learning another component. But it is not clear where to look for the proper documentation to know what to do. We if have a vb.project that has 30 screens with code behind and another 40 or so modules it is a bit tough to know what to do. Is the solution in the references or the setup dependencies, etc.? I've seen discussions of have different dlls which is unclear how to do it with the vb components and ocx modules, etc. both for MS VS stuff and also other SDKs, etc that we are using. I don't think that renaming DLLs will work. So where to begin? What is the best practises for setup and deployment? This has been causing us nightmares and we are ready to bit the bullet if we knew where the bullet was.
-
In researching this it seems that the problem even exists with the 3rd party installers unless a lot of work is done first. So if a lot of work must be done why not just do it with the VS.Net Deploy and Setup project, etc. instead of learning another component. But it is not clear where to look for the proper documentation to know what to do. We if have a vb.project that has 30 screens with code behind and another 40 or so modules it is a bit tough to know what to do. Is the solution in the references or the setup dependencies, etc.? I've seen discussions of have different dlls which is unclear how to do it with the vb components and ocx modules, etc. both for MS VS stuff and also other SDKs, etc that we are using. I don't think that renaming DLLs will work. So where to begin? What is the best practises for setup and deployment? This has been causing us nightmares and we are ready to bit the bullet if we knew where the bullet was.
The reason you're in this position is because you don't understand how Windows Installer works. So you're going to have to learn this no matter what.
QBTeKcom wrote:
So if a lot of work must be done why not just do it with the VS.Net Deploy and Setup project, etc. instead of learning another component.
Because you have no choice. The Deployment and Setup project no longer exists in Visual Studio 11 and it's capabilities are very limited to begin with. You have to use a 3rd party tool, such as InstallShield LE, or InnoSetup, or AdvancedInstaller, ... Either way, you're looking at a bunch of work to DO IT CORRECTLY IN THE FIRST PLACE!
QBTeKcom wrote:
We if have a vb.project that has 30 screens with code behind and another 40 or so modules it is a bit tough to know what to do.
The number of forms you have in your application has no bearing on the installer at all. The complicated part comes in when you start referencing external components and libraries. You have to KNOW what you're referencing, how they works and what their installation requirements are. Coming up with an installer is not just a "OK my app is done now throw an installer together" process. Installers are another program you write SIDE-BY-SIDE with your application so that the installer knows what your app is using and how to correctly install every file, in every component, in every feature, what merge modules are, why they exist and how to use them, ...
QBTeKcom wrote:
I don't think that renaming DLLs will work.
No, it won't.
QBTeKcom wrote:
This has been causing us nightmares and we are ready to bit the bullet if we knew where the bullet was.
You're writing application in the dark. You have no idea how the components in your app fit together nor how external libraries work, how they are registered or why, and how your installer has to handle these things. If you don't know these things, you can't just throw files anywhere you like and expect everything to work fine.
-
The reason you're in this position is because you don't understand how Windows Installer works. So you're going to have to learn this no matter what.
QBTeKcom wrote:
So if a lot of work must be done why not just do it with the VS.Net Deploy and Setup project, etc. instead of learning another component.
Because you have no choice. The Deployment and Setup project no longer exists in Visual Studio 11 and it's capabilities are very limited to begin with. You have to use a 3rd party tool, such as InstallShield LE, or InnoSetup, or AdvancedInstaller, ... Either way, you're looking at a bunch of work to DO IT CORRECTLY IN THE FIRST PLACE!
QBTeKcom wrote:
We if have a vb.project that has 30 screens with code behind and another 40 or so modules it is a bit tough to know what to do.
The number of forms you have in your application has no bearing on the installer at all. The complicated part comes in when you start referencing external components and libraries. You have to KNOW what you're referencing, how they works and what their installation requirements are. Coming up with an installer is not just a "OK my app is done now throw an installer together" process. Installers are another program you write SIDE-BY-SIDE with your application so that the installer knows what your app is using and how to correctly install every file, in every component, in every feature, what merge modules are, why they exist and how to use them, ...
QBTeKcom wrote:
I don't think that renaming DLLs will work.
No, it won't.
QBTeKcom wrote:
This has been causing us nightmares and we are ready to bit the bullet if we knew where the bullet was.
You're writing application in the dark. You have no idea how the components in your app fit together nor how external libraries work, how they are registered or why, and how your installer has to handle these things. If you don't know these things, you can't just throw files anywhere you like and expect everything to work fine.
Dave, you have said a lot about how we are doing in wrong, etc. but nothing about were we can get the documenation on how to do it right which is what was asked.
-
Dave, you have said a lot about how we are doing in wrong, etc. but nothing about were we can get the documenation on how to do it right which is what was asked.
You can start with a bunch of reading: COM Components[^] Windows Installer Basics[^] Windows Installer best practices[^]