Solved

Best Practices for VB Projects that refer to VB Controls in them

Posted on 2006-07-07
5
255 Views
Last Modified: 2013-12-25
Hello all

I have inherited a couple of VB apps, that have up to ten home-grown VB controls they use.  

The previous developer had all of these compiled in a c:\Program Files\My Company\bin folder, and all of the vbp projects referenced them there.  
Then the Install package wrote them to %system% during the install.

Q:  What's the easiest way to manage/deploy VB apps with multiple VB controls in them?

TIA
-Jim
0
Comment
Question by:Jim Horn
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
5 Comments
 
LVL 2

Accepted Solution

by:
bdbrown earned 450 total points
ID: 17060250
Jim,

Here are a few utilities for packaging and deployment which I use;

Dependancy Walker; http://www.dependencywalker.com/

ISTool; http://www.istool.org/default.aspx/

Inno Setup; http://www.jrsoftware.org/isinfo.php

Hope this helps

bdb
0
 
LVL 4

Assisted Solution

by:jomacinc
jomacinc earned 50 total points
ID: 17073092
You should install the components into the system directory on the development machine and reference them there.
That way the app should not have trouble finding them on any system they are installed to.
0
 
LVL 66

Author Comment

by:Jim Horn
ID: 17074744
Thanks for the comments guys.  

>You should install the components into the system directory on the development machine and reference them there.
This is the way I normally develop.  

The setup I inherited though had all custom ocx's in c:\Program Files\{Company Name}\bin folder, and all of the project files referenced the ocx's in this location.
I believed when the app was deployed using M$ Package & Deployment Wizard, the script wrote-registered them to the correct %system% folder.

So..  on the development pc you would have the ocx's live in two separate places, and possible (definatly) have registry conflicts.
0
 
LVL 4

Expert Comment

by:jomacinc
ID: 17077341
Is there a reason why the OCX's need to be in c:\Program Files\{Company Name}\bin folder on the development machine?
If not, they should be moved to the system folder and not stored in two places.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The debugging module of the VB 6 IDE can be accessed by way of the Debug menu item. That menu item can normally be found in the IDE's main menu line as shown in this picture.   There is also a companion Debug Toolbar that looks like the followin…
Background What I'm presenting in this article is the result of 2 conditions in my work area: We have a SQL Server production environment but no development or test environment; andWe have an MS Access front end using tables in SQL Server but we a…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

691 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question