VB6 to C# Architecture Question - Best Practice?

[=?Utf-8?B?bW9mbGFoZXJ0eQ==?=]

In VB6, we created a number of ActiveX DLLs that all shared a similar
interface. The main application would load these in dynamically (late-bound.)
This worked well for our situation because we could update the DLLs
independently of the main EXE, and performance was not a problem.

We want to do the same thing in C# (at least test it), but we are not
exactly clear what the best practice is. We would prefer to do something
similar, but we are open to any advice.

In VB6 terms, we have a shared class which serves as the interface to our
DLLs. To keep the example simple, I created this:

‘ VB6 Class Interface
Public Function DoSomething() As Boolean
DoSomething = True
End Function

Each DLL would be compiled with the same class.

A simple example of how we would use this is here:

Private Sub Command1_Click()
Dim objClass As Object
Dim strClass As String
Dim bUseFirstClass As Boolean

bUseFirstClass = False

If bUseFirstClass = True Then
strClass = "prjTestA.clsExample"
Else
strClass = "prjTestB.clsExample"
End If
Set objClass = CreateObject(strClass)

Debug.Print objClass.DoSomething()

Set objClass = Nothing

End Sub
What is the best way to do something similar in C#? We started looking at
reflection, but I want to make sure that is considered the best way to
approach this, or if there is some other words of wisdom we should follow.
Any sample code would be most appreciated!

Thank you for your time and advice.

Mo

[=?Utf-8?B?RGF2aWQgQW50b24=?=]

In C#, you could have (converted directly via Instant C#):
private void Command1_Click()
{
object objClass = null;
string strClass = null;
bool bUseFirstClass = false;

bUseFirstClass = false;

if (bUseFirstClass)
{
strClass = "prjTestA.clsExample";
}
else
{
strClass = "prjTestB.clsExample";
}

System.Type objClassType = System.Type.GetTypeFromProgID(strClass);
objClass = System.Activator.CreateInstance(objClassType);

Debug.Print objClassType.InvokeMember("DoSomething",
System.Reflection.BindingFlags.InvokeMethod, null, objClass, null);

objClass = null;
}

--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
"moflaherty" wrote:

In VB6, we created a number of ActiveX DLLs that all shared a similar
interface. The main application would load these in dynamically (late-bound.)
This worked well for our situation because we could update the DLLs
independently of the main EXE, and performance was not a problem.

We want to do the same thing in C# (at least test it), but we are not
exactly clear what the best practice is. We would prefer to do something
similar, but we are open to any advice.

In VB6 terms, we have a shared class which serves as the interface to our
DLLs. To keep the example simple, I created this:

‘ VB6 Class Interface
Public Function DoSomething() As Boolean
DoSomething = True
End Function

Each DLL would be compiled with the same class.

A simple example of how we would use this is here:

Private Sub Command1_Click()
Dim objClass As Object
Dim strClass As String
Dim bUseFirstClass As Boolean

bUseFirstClass = False

If bUseFirstClass = True Then
strClass = "prjTestA.clsExample"
Else
strClass = "prjTestB.clsExample"
End If
Set objClass = CreateObject(strClass)

Debug.Print objClass.DoSomething()

Set objClass = Nothing

End Sub
What is the best way to do something similar in C#? We started looking at
reflection, but I want to make sure that is considered the best way to
approach this, or if there is some other words of wisdom we should follow.
Any sample code would be most appreciated!

Thank you for your time and advice.

Mo

[Nick Malik [Microsoft]]

"moflaherty" <mo********@discussions.microsoft.comwrote in message
news:3E**********************************@microsof t.com...

In VB6, we created a number of ActiveX DLLs that all shared a similar
interface. The main application would load these in dynamically
(late-bound.)
This worked well for our situation because we could update the DLLs
independently of the main EXE, and performance was not a problem.

We want to do the same thing in C# (at least test it), but we are not
exactly clear what the best practice is. We would prefer to do something
similar, but we are open to any advice.

In VB6 terms, we have a shared class which serves as the interface to our
DLLs. To keep the example simple, I created this:

' VB6 Class Interface
Public Function DoSomething() As Boolean
DoSomething = True
End Function

Each DLL would be compiled with the same class.

A simple example of how we would use this is here:

Private Sub Command1_Click()
Dim objClass As Object
Dim strClass As String
Dim bUseFirstClass As Boolean

bUseFirstClass = False

If bUseFirstClass = True Then
strClass = "prjTestA.clsExample"
Else
strClass = "prjTestB.clsExample"
End If
Set objClass = CreateObject(strClass)

Debug.Print objClass.DoSomething()

Set objClass = Nothing

End Sub
What is the best way to do something similar in C#? We started looking at
reflection, but I want to make sure that is considered the best way to
approach this, or if there is some other words of wisdom we should follow.
Any sample code would be most appreciated!

Thank you for your time and advice.

Mo

I think I know what you are trying to do but I'm not sure. In VB6, you
didn't have proper inheritance, but in C#, you do. There is no reason you
cannot create an interface directly. In C#, you can create the interface,
compile it into a DLL, and then simply make a reference to that DLL from all
projects that need to implement the interface (no need to compile the
'psuedo-base-class' into every DLL... it's a real base class or interface
now).

So all the design patterns work just fine in C#. Examples of how to use
each of the design patterns in C# can be found at www.dofactory.com

For what you are trying to do, you are creating a plug in. So create the
interface that all of your subtypes will implement and create a factory that
is able to instantiate a type based on a string. The string can come from
reflection or it can come from a config file... either way, hide the
creation of your plug-in type in a factory method so that the calling code
won't have to know or care where your logic is for discovering the actual
type you are creating.

I hope that helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[=?Utf-8?B?bW9mbGFoZXJ0eQ==?=]

Interesting product!

[Chris Dunaway]

On Jan 31, 10:25 am, moflaherty <[e-mail]>
wrote:

In VB6, we created a number of ActiveX DLLs that all shared a similar
interface. The main application would load these in dynamically (late-bound.)
This worked well for our situation because we could update the DLLs
independently of the main EXE, and performance was not a problem.

We want to do the same thing in C# (at least test it), but we are not
exactly clear what the best practice is. We would prefer to do something
similar, but we are open to any advice.

In VB6 terms, we have a shared class which serves as the interface to our
DLLs. To keep the example simple, I created this:

' VB6 Class Interface
Public Function DoSomething() As Boolean
DoSomething = True
End Function

Each DLL would be compiled with the same class.

A simple example of how we would use this is here:

Private Sub Command1_Click()
Dim objClass As Object
Dim strClass As String
Dim bUseFirstClass As Boolean

bUseFirstClass = False

If bUseFirstClass = True Then
strClass = "prjTestA.clsExample"
Else
strClass = "prjTestB.clsExample"
End If

Set objClass = CreateObject(strClass)

Debug.Print objClass.DoSomething()

Set objClass = Nothing

End Sub

What is the best way to do something similar in C#? We started looking at
reflection, but I want to make sure that is considered the best way to
approach this, or if there is some other words of wisdom we should follow.
Any sample code would be most appreciated!

Thank you for your time and advice.

Mo

You didn't use an interface at all, except only superficially.
Otherwise your classes would have used the Implements keyword to
implement the interface. If you had used a "real" interface, you
would not have had to use a variable of type Object, but a variable of
the type of the interface class.

But as Nick Malik said, in C#, you can create a proper Interface type
and then implement it any classes you needed. You can use reflection
to check to see if a class implements the interface and instantiate it
if it does.

Chris