Is there an easy way to expose class variables in COM builds?

[Nick Dreyer]

In VB.NET I would like to not have to create property get/set procedures for
every class variable I want to expose to Excel VBA projects in COM builds.

Can anyone tell me if that is possible, or refer me to some documents that
will make me understand why this apparent limitation of VB.NET COM builds is
acceptable, i.e. why in "good" object code programs I should expect to never
have to create large numbers of public class variables that need to be visible
outside of objects?

I gather that this was not an issue in VB6, so why the limitation in VB.NET?


|\|.

 

[Dave]

why in "good" object code programs I should expect to never

have to create large numbers of public class variables that need to be visible
outside of objects?

I don't think there is any design pattern that recommends against the above. Shouldn't it just depend upon the needs of your app?

I've never heard of that "limitation" and so am curious as to the source of the information.

If you really want to avoid making properties, you can just use public fields. Really, your choices are methods or fields since
properties become methods when compiled.

 

[Herfried K. Wagner [MVP]]

In VB.NET I would like to not have to create property get/set procedures
for
every class variable I want to expose to Excel VBA projects in COM builds.

Can anyone tell me if that is possible, or refer me to some documents that
will make me understand why this apparent limitation of VB.NET COM builds
is
acceptable, i.e. why in "good" object code programs I should expect to
never
have to create large numbers of public class variables that need to be
visible
outside of objects?

I gather that this was not an issue in VB6, so why the limitation in
VB.NET?

In VB6 public variables were compiled to properties. I suggest to use
properties in your VB.NET project instead of public variables if you want
them to be exposed to COM.

 

[Gerald Hernandez]

In VB.NET I would like to not have to create property get/set procedures for
every class variable I want to expose to Excel VBA projects in COM builds.

Can anyone tell me if that is possible, or refer me to some documents that
will make me understand why this apparent limitation of VB.NET COM builds is
acceptable, i.e. why in "good" object code programs I should expect to never
have to create large numbers of public class variables that need to be visible
outside of objects?

I gather that this was not an issue in VB6, so why the limitation in VB.NET?

VB6 was COM based. There was much plumbing that it performed for you in the
background. It would automatically create the Interfaces, Type Libraries,
and many other things. With public variables / fields, VB6 would
automatically turn these into properties/methods for you. It is a
requirement of COM that anything being exposed externally have an entry for
the Interface in the Type Library. VB6 was also sort of an oddity in this
sense. Most other languages do not provide such things automatically. I'm
glad it did, but most others did not.

As you have found, VB.NET is not COM based. In fact, Microsoft's desire is
for .NET to replace COM whenever possible. Truth is that they really don't
want you using COM, but they realized the need for some outgoing COM
support. If you wish to provide COM support via VB.NET, you have little
choice but to dig in and learn the ins and outs of COM and implement this
all manually, much like C++ programmers have always had to do. Since
Microsoft doesn't really want this to become a common practice, they don't
make it easy. Additionally, since .NET is not COM based, it supports tons of
things that COM and therefore VB6 does not. Not automatically exposing such
things brings VB.NET inline with most other programming languages.

Gerald

 

[Nick Dreyer]

Gerald:

Thanks for your insights. I have inserted a few comments/questions into the
excerpted relevant parts of your message below

. . . It is a
requirement of COM that anything being exposed externally have an entry for
the Interface in the Type Library. VB6 was also sort of an oddity in this
sense. Most other languages do not provide such things automatically. I'm
glad it did, but most others did not.

So, was making it look like VB6 public class variables were exposed in COM -
by converting them to properties - one such nice "oddity"?

. . . Additionally, since .NET is not COM based, it supports tons of
things that COM and therefore VB6 does not. Not automatically exposing such
things brings VB.NET inline with most other programming languages.

To get this straight and once-and-for-all fully confirmed in my mind: VB.NET
COM builds do not convert public class variables into properties the way VB6
did? In other words I am going to have to create the property "overhead" code
myself for each such variable I need?

Lastly, is there some good reading out there on how to get one's mind thinking
about programing in a way that one's software designs minimize the use of
public class variables?

Thanks, Nick

|\|.

 

[Gerald Hernandez]

Nick, comments inline...

Gerald:

Thanks for your insights. I have inserted a few comments/questions into the
excerpted relevant parts of your message below



So, was making it look like VB6 public class variables were exposed in COM -
by converting them to properties - one such nice "oddity"?

[GH] Yes. This was one of those nice oddities. In essence, VB6 would
automatically compile public fields as properties so they would be usable.
Interestingly, in COM the properties actually get converted to subs and
functions when compiled. So VB6 actually took a couple extra steps. In other
languages, you would have to code each get and set method as seperate subs
and functions. Ah, VB6 seemed so nice.

To get this straight and once-and-for-all fully confirmed in my mind: VB.NET
COM builds do not convert public class variables into properties the way VB6
did? In other words I am going to have to create the property "overhead" code
myself for each such variable I need?

[GH] To the best of my knowledge, you are correct. VB.NET will not
automatically convert these variables to properties, and yes you will need
to code the wrappers / overhead yourself. However, some good news. In my
experience, I have found that creating properties in VB.NET in actually much
faster and easier than VB6. Mainly due to the autocomplete and the combined
Get/Set blocks. So while there might be more words in your source, you
actually end up doing like less than half the typing you would in VB6.

Lastly, is there some good reading out there on how to get one's mind thinking
about programing in a way that one's software designs minimize the use of
public class variables?

[GH] Good question. Sadly, I don't personally know of any; hopefully someone
else will chime in with a recommendation. I get the impression that you are
thinking that we all are saying that lots of public fields in classes is a
bad thing. Well, public "variables" / "fields" exposed in the way you are
talking about is less than ideal, even in VB6 they really should be wrapped
in a property for a few very reasonable reasons. However, using classes to
store a bunch of related values, similar to a User Defined Type, is actually
encouraged, especially in .NET. If you can group related methods and make
the class more self contained / self aware, then you are on your way to the
Object Oriented approach.

[GH] Based on my experience in retraining on VB.NET from VB6, my best advice
for the moment would be: "Try" not to become too frustrated. I know it isn't
easy ;-) But take the time to learn the VB.NET way of doing things. In time,
you will adjust and it won't take too long before you start to like .NET
more than VB6. If you let the inevitable frustration take over, it will
cloud your mind to learning new things. Just keep in mind that they are
different. If you try to make VB.NET be VB6, you will drive yourself nuts.
For me personally, I don't like VB.NET's level of COM support. So what I
have been doing is coding the COM portions in VB6 still, especially for VBA,
and then referencing it into .NET. Backwards? well yeah a bit. But
interestingly, coding in VB.NET for a short time has made me a much better
VB6 programmer than decades of experience. So hang in there, it gets better.

Gerald

 

[Nick Dreyer]

Thanks Gerald. I had more or less come to similar conclusions, not only about
the reality of, but also the "philosophical approach" to take with VB.NET.

Now that I have read your very considered response, I feel a lot better about
diving in to the new .NET way. There is obviously a lot to learn, and with
your assurance that there is a worthwhile outcome to look forward to, it feels
like the kind of learning that keeps drudgery from setting in - a good thing.

All the best, |\|.

Nick, comments inline...

Gerald:

Thanks for your insights. I have inserted a few comments/questions into the
excerpted relevant parts of your message below

So, was making it look like VB6 public class variables were exposed in COM -
by converting them to properties - one such nice "oddity"?

[GH] Yes. This was one of those nice oddities. In essence, VB6 would
automatically compile public fields as properties so they would be usable.
Interestingly, in COM the properties actually get converted to subs and
functions when compiled. So VB6 actually took a couple extra steps. In other
languages, you would have to code each get and set method as seperate subs
and functions. Ah, VB6 seemed so nice.

[GH] To the best of my knowledge, you are correct. VB.NET will not
automatically convert these variables to properties, and yes you will need
to code the wrappers / overhead yourself. However, some good news. In my
experience, I have found that creating properties in VB.NET in actually much
faster and easier than VB6. Mainly due to the autocomplete and the combined
Get/Set blocks. So while there might be more words in your source, you
actually end up doing like less than half the typing you would in VB6.

Lastly, is there some good reading out there on how to get one's mind thinking
about programing in a way that one's software designs minimize the use of
public class variables?

[GH] Good question. Sadly, I don't personally know of any; hopefully someone
else will chime in with a recommendation. I get the impression that you are
thinking that we all are saying that lots of public fields in classes is a
bad thing. Well, public "variables" / "fields" exposed in the way you are
talking about is less than ideal, even in VB6 they really should be wrapped
in a property for a few very reasonable reasons. However, using classes to
store a bunch of related values, similar to a User Defined Type, is actually
encouraged, especially in .NET. If you can group related methods and make
the class more self contained / self aware, then you are on your way to the
Object Oriented approach.

[GH] Based on my experience in retraining on VB.NET from VB6, my best advice
for the moment would be: "Try" not to become too frustrated. I know it isn't
easy ;-) But take the time to learn the VB.NET way of doing things. In time,
you will adjust and it won't take too long before you start to like .NET
more than VB6. If you let the inevitable frustration take over, it will
cloud your mind to learning new things. Just keep in mind that they are
different. If you try to make VB.NET be VB6, you will drive yourself nuts.
For me personally, I don't like VB.NET's level of COM support. So what I
have been doing is coding the COM portions in VB6 still, especially for VBA,
and then referencing it into .NET. Backwards? well yeah a bit. But
interestingly, coding in VB.NET for a short time has made me a much better
VB6 programmer than decades of experience. So hang in there, it gets better.

Gerald