D
David A. Beck
We have developed systems for a client with VB, SQL Server, IIS, and ASP. We
are in the process of doing all new work in .NET. We set up two directories
on a file server. One for the executables and one COM controls. Every use
maps to the
first directory (EXE) to run their programs. When they re-boot their
computer, we have a program in the startup that goes through the second
directory (COM) checking that all the current versions of the COM controls
we need are installed and installing them if they are not. We have home
grown COM components that we can change at will and the executables that use
them don't have to be changed. We would like to do something similar for our
VB.NET programs.
Our home-grown COM controls use other COM controls so re-writing them
comples us to replace the purchased COM conrols with managed code. In some
case we can't do that. We have a problem when we use a COM component in the
VB.NET assembly (DLL). We are told that the VB.NET DLL must be in the same
directory as the VB.NET executable and what's more the executable is locked
into a specific version of the VB.NET DLL. That would mean recompiling every
program that uses the VB.NET DLL when it is changed. Now the catch22, we can
get around the recompiling problem by strongly typing the VB.NET DLL and
putting it in the GAC, BUT you can't strongly type a VB.NET DLL that uses a
COM component.
It would seem that we must leave COM components out of our home grown VB.NET
DLLs.
Is there a different solution or am I incorrect in my assumptions?
David A. Beck
are in the process of doing all new work in .NET. We set up two directories
on a file server. One for the executables and one COM controls. Every use
maps to the
first directory (EXE) to run their programs. When they re-boot their
computer, we have a program in the startup that goes through the second
directory (COM) checking that all the current versions of the COM controls
we need are installed and installing them if they are not. We have home
grown COM components that we can change at will and the executables that use
them don't have to be changed. We would like to do something similar for our
VB.NET programs.
Our home-grown COM controls use other COM controls so re-writing them
comples us to replace the purchased COM conrols with managed code. In some
case we can't do that. We have a problem when we use a COM component in the
VB.NET assembly (DLL). We are told that the VB.NET DLL must be in the same
directory as the VB.NET executable and what's more the executable is locked
into a specific version of the VB.NET DLL. That would mean recompiling every
program that uses the VB.NET DLL when it is changed. Now the catch22, we can
get around the recompiling problem by strongly typing the VB.NET DLL and
putting it in the GAC, BUT you can't strongly type a VB.NET DLL that uses a
COM component.
It would seem that we must leave COM components out of our home grown VB.NET
DLLs.
Is there a different solution or am I incorrect in my assumptions?
David A. Beck