Standard Include Files

[mike]

In my vb6 apps I have a set of standard modules that I include in all of my applications. However, when I upgrade an existing application it creates a copy of these modules in the application directory. The problem is that I can't move these files to a standard location and then point all my apps to this location. I've looked on different newsgroups and the closest solution I have found is to use inheritance. This solution works for using a standard form over and over again, but does not seem to work well when you have standard modules that you are wanting to use over and over again. Any suggestions?

[Dominique Vandensteen]

why not put all these classes/modules in a dll and reference to that dll in
all your applications?

dominique
"mike" <an*******@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...

In my vb6 apps I have a set of standard modules that I include in all of

my applications. However, when I upgrade an existing application it creates
a copy of these modules in the application directory. The problem is that I
can't move these files to a standard location and then point all my apps to
this location. I've looked on different newsgroups and the closest solution
I have found is to use inheritance. This solution works for using a
standard form over and over again, but does not seem to work well when you
have standard modules that you are wanting to use over and over again. Any
suggestions?

[mike]

Ok, I have tried that and I am getting a compilation error on the following line of code
Public Sub ConnectDB(ByRef DBName As String, ByRef ADOControl As VB6.ADODC, Optional ByRef UseDefault As Boolean = True, Optional ByRef ReadOnly_Renamed As Boolean = False, Optional ByRef RSLock As ADODB.LockTypeEnum = ADODB.LockTypeEnum.adLockOptimistic

The compiler doesn't like the vb6.adodc reference. When I upgrade an entire project it doesn't have a problem with this reference. Any suggestions

[Herfried K. Wagner [MVP]]

* "=?Utf-8?B?bWlrZQ==?=" <an*******@discussions.microsoft.com> scripsit:

In my vb6 apps I have a set of standard modules that I include in all
of my applications. However, when I upgrade an existing application it
creates a copy of these modules in the application directory. The
problem is that I can't move these files to a standard location and then
point all my apps to this location. I've looked on different newsgroups
and the closest solution I have found is to use inheritance. This
solution works for using a standard form over and over again, but does
not seem to work well when you have standard modules that you are
wanting to use over and over again. Any suggestions?

I would create a class library that includes these methods and reference
the class library from your EXE projects.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[mike]

Ok, I was able to put them all into a dll. The program still doesn't recognize the functions. Do I need to reference the code in the applications a specific way?

[Dominique Vandensteen]

add reference to that dll (for example via menu: project -> add reference)

your classes will also be in a different namespace...
dominique

"mike" <an*******@discussions.microsoft.com> wrote in message
news:D4**********************************@microsof t.com...

Ok, I was able to put them all into a dll. The program still doesn't

recognize the functions. Do I need to reference the code in the
applications a specific way?

[Jay B. Harlow [MVP - Outlook]]

Mike,
As Dominique stated, move the "common" code to its own assembly and
reference this assembly.

Remember however to reference all the same assemblies that the upgrade
wizard added. Specifically Microsoft.VisualBasic.Compatibility.

However I would strongly recommend you Refactor (http://www.refactoring.com)
your "common" code to not require the Microsoft.VisualBasic.Compatibility
assembly, as this assembly is not installed by default.

An alternative to a separate assembly is to "Link" to the file, when you use
"Project - Add Existing Item" click the down arrow next to the Open button,
select "Link file".

Hope this helps
Jay

"mike" <an*******@discussions.microsoft.com> wrote in message
news:0A**********************************@microsof t.com...

In my vb6 apps I have a set of standard modules that I include in all of

my applications. However, when I upgrade an existing application it creates
a copy of these modules in the application directory. The problem is that I
can't move these files to a standard location and then point all my apps to
this location. I've looked on different newsgroups and the closest solution
I have found is to use inheritance. This solution works for using a
standard form over and over again, but does not seem to work well when you
have standard modules that you are wanting to use over and over again. Any
suggestions?

[mike]

I put these files in a common assembly and add a reference to them in the project explorer. The program still doesn't recognize it. Am I not referencing it correctly?

[Dominique Vandensteen]

don't forget to check the right namespace

for example, above your code add
imports TheNameOfTheImportedNamespace
dominique
"mike" <an*******@discussions.microsoft.com> wrote in message
news:67**********************************@microsof t.com...

I put these files in a common assembly and add a reference to them in the

project explorer. The program still doesn't recognize it. Am I not
referencing it correctly?

[Herfried K. Wagner [MVP]]

* "=?Utf-8?B?bWlrZQ==?=" <an*******@discussions.microsoft.com> scripsit:

Ok, I was able to put them all into a dll. The program still doesn't
recognize the functions. Do I need to reference the code in the
applications a specific way?

In the EXE project, go to the solution explorer and select the project's
"References" folder. In its contextmenu, select "Add Reference..." and
select the DLL you created.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Jay B. Harlow [MVP - Outlook]]

Mike,
You need to be certain to put Public on every element that you want to
access from the second assembly. Also consider either Friend or Private for
elements that you don't want the second assembly to access.

Protected is useful for elements in base classes to be used by derived
classes.

I normally explicitly label elements as Public or Private rather then
relying on the defaults.

Hope this helps
Jay

"mike" <an*******@discussions.microsoft.com> wrote in message
news:67**********************************@microsof t.com...

I put these files in a common assembly and add a reference to them in the

project explorer. The program still doesn't recognize it. Am I not
referencing it correctly?

[Mike Nettles]

All functions have the public reference. I have tried explicitly typing
imports <namespace name> in my code and it still doesn't recognize it.

[Mike]

All fuctions are public. I have tried manually typing imports<the
namespace> and this has not helped either. Any ideas?

[Jay B. Harlow [MVP - Outlook]]

Mike,

All functions have the public reference. What about the Class or Module the functions are in?

I stated ALL elements need to be Public where element is (Class, Module,
Enum, Interface, Sub, Function, Event, Property, etc...)

Hope this helps
Jay
"Mike Nettles" <Mi**********@doss.wiu.edu> wrote in message
news:eU**************@tk2msftngp13.phx.gbl... All functions have the public reference. I have tried explicitly typing
imports <namespace name> in my code and it still doesn't recognize it.

[mike]

There was a combination of problems. I needed to change all my include files from modules to classes. This fixed the problem referencing the namespace. I'm new to dot net and I didn't realize I would have to specify the namespace as "imports <namespace.className>

Thanks for all the help.