Argument with a developer

[Highlander]

Hello all. I'm a systems admin and not a developer. I work in a large
IT department with teams of developers. Currently we are asking them to
develop a utility for us that will migrate code, among other things.
It's going to be written in .NET code, and is meant to replace our
current code migration utility which was written in VB6.

One of the functions we are asking for is the ability to send an e-mail
and a page to indicate success of failure of a code migration. The
developer is pushing back. Here's the exchange between the developer
and myself.

DEVELOPER: For an application to send an e-mail, SMTP services need to
be installed and running. To send a page, permissions need to be
implemented for internet access. Ports outside the firewall would be
needed to send pages. This creates a security issue.

ME: There is a workaround. The following script will send e-mail
without SMTP services. And as for sending a page, you use the same
e-mail script, and include a skytel e-mail address:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sendFrom = "(e-mail address removed)"
SendTo = "(e-mail address removed); (e-mail address removed)"
strSubj = "NO SMTP service needed."
strContents = "Testing e-mail script."

sch = "http://schemas.microsoft.com/cdo/configuration/"
Set cdoConfig = CreateObject("CDO.Configuration")
With cdoConfig.Fields
.Item(sch & "sendusing") = 2 ' cdoSendUsingPort
.Item(sch & "smtpserver") = "mail.allstate.com"
'.Item(sch & "smtpserverport") = 25 ' if you need to set a port
number
.update
End With

Set cdoMessage = CreateObject ("CDO.Message")
With cdoMessage
Set .Configuration = cdoConfig
.From = sendFrom
.To = sendTo
.Subject = strSubj
.TextBody = strContents
.Send
End With
Set cdoConfig = nothing
Set cdoMessage = nothing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DEVELOPER: This VB6 script is and its related calls to WMI are not
supported in .NET 1.1 or .NET 2.0 framework. The idea is to move away
from old technologies not to keep supporting them.

ME: If you can't run a script such as this one within .NET, then you
can run the script via command line. That would allow it to be used in
the .NET 1.1 or .NET 2.0 framework.

DEVELOPER: Just because it can be run via a command line does not mean
it is a part of .NET. If you check the .NET framework reference there
is no use of WMI interfaces. It is old technology that, through the
..NET framework, is not supported.

ME: When the code migration has completed, then the new utility
launches an executable from the command line. That's all the
functionality it needs. That's where it stops. No other requirements
for working within the .NET framework are needed - other than the
ability for the new utility to launch an executable from the command
line, and pass it a couple parameters.
The rest is done by the executable that is launched - the VBScript
above.

....

I don't follow what his points are exactly. I don't see any references
to WMI in this VBScript. But that's really a moot point anyway - since
all we need the .NET utility to do is run an executable from the
command line. I would imagine that writing the code in .NET to run an
executable from the command line is a relatively simple task.

I would imagine that writing the code in .NET to UnZip a file is also
is a relatively simple task. And this UnZip functionality is something
else we're requesting, and the developer is pushing back on this as
well - claiming that it's too complex - which increases the cost and
man-hours of the project.

Am I missing something here? Does this developer have a valid argument?

Thanks.

- Dave

 

[McKirahan]

Hello all. I'm a systems admin and not a developer. I work in a large
IT department with teams of developers. Currently we are asking them to
develop a utility for us that will migrate code, among other things.
It's going to be written in .NET code, and is meant to replace our
current code migration utility which was written in VB6.

One of the functions we are asking for is the ability to send an e-mail
and a page to indicate success of failure of a code migration. The
developer is pushing back. Here's the exchange between the developer
and myself.

[snip]

Your requirement that "It's going to be written in .NET code"
clearly does not allow room for non-.NET functionality.

(I'm not a .NET developer (yet) so I can't comment on
its ability to send or not send email from within it.)

 

[Kevin Spencer]

Hi Dave,

First of all, I hope your developer is a junior developer, because he
doesn't know much about the .Net platform or SMTP.

DEVELOPER: For an application to send an e-mail, SMTP services need to
be installed and running. To send a page, permissions need to be
implemented for internet access. Ports outside the firewall would be
needed to send pages. This creates a security issue.

To send email, an SMTP server is necessary. Note that I did not say SMTP
services need to be installed and running. As long as the client app can
access the SMTP server over a network, and has permission to use it, any
SMTP server may be used.

You didn't specify what you meant by "a page" so I can't comment. Did you
mean an attachment with an HTML page, or some form of pager page?

DEVELOPER: This VB6 script is and its related calls to WMI are not
supported in .NET 1.1 or .NET 2.0 framework. The idea is to move away
from old technologies not to keep supporting them.

This is just rubbish. First of all, WMI is an integral part of the Operating
System. Second, the .Net System.Windows.Management and
System.Windows.Management.Instrumentation namespaces are specifically for
working with WMI. Third, neither CDO nor WMI are necessary to send email.
The .Net platform has built-in classes (System.Net.Mail namespace) for
sending email. so, while your scripted "workaround" will certainly work, it
is unnecessary.

Finally, because of the above, the rest of the debate is moot.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

If the Truth hurts, wear it.

 

[Peter Duniho]

[...]
I don't follow what his points are exactly. I don't see any references
to WMI in this VBScript. But that's really a moot point anyway - since
all we need the .NET utility to do is run an executable from the
command line. I would imagine that writing the code in .NET to run an
executable from the command line is a relatively simple task.

I would imagine that writing the code in .NET to UnZip a file is also
is a relatively simple task. And this UnZip functionality is something
else we're requesting, and the developer is pushing back on this as
well - claiming that it's too complex - which increases the cost and
man-hours of the project.

Am I missing something here? Does this developer have a valid argument?

IMHO:

* It's a mistake to use public newsgroups as a way of resolving internal
departmental differences. If the developer finds out that you did so, it's
sure to only increase any animosity that may exist currently.

* Your description of the issue suggests to me that this is more about a
difference of opinion with respect to your solution specification. That is,
what does it mean to be "written in .NET code"?

I would agree with the developer that calling out to an external VB6 routine
negates the point of being .NET-only. That is, what happens when you try to
run on a system that has .NET, but not VB6 support? This is exactly the
sort of migration work-around that causes all sorts of headaches down the
road, when you think you've gotten fully incorporated in the new technology,
only to find that in fact all you've done is add another layer on top of the
old technology. Everything comes apart when that old technology gets
broken, removed, or otherwise deprecated.

As far as the specific example goes, I don't see that using the script you
posted is necessary in order to implement the desired functionality in .NET.

First of all, the "Collaborative Data Objects" (CDO) object being used in
the script you posted isn't specifically a VB6 object. It's a
general-purpose COM object provided in certain versions of Windows. I don't
see any reason one should not be able to call it directly from .NET, though
doing so may involve using some form of interoperability (ie platform
invoking (P/Invoke)).

Secondly, using CDO is just a shortcut way to implement something that talks
directly to a SMTP server. One could write all of the necessary code from
scratch in .NET. It would be a LOT longer than the script you posted, but I
don't see any reason it couldn't be done. It may or may not be within the
skill set of the developer, but it's technically possible.

IMHO, you and the developer should both try to communicate a little better,
to understand more precisely what your specific goals and limitations are.
Based on that, come up with a solution that meets everyone's criteria.

The best, most theoretically robust solution would probably be to just do
everything from scratch, based on the SMTP definition. But in reality,
Microsoft tries very hard to maintain backward compatibility, and I think
it's unlikely that CDO is going to go away any time soon. Because of that,
it may be most efficient for the developer to invest his time becoming
familiar with how interop works in .NET and using that to use CDO just as
the VB6 code you posted does.

But it's true that the CDO object isn't .NET per se, so you and the
developer need to get your definitions in order first. Otherwise, you're
just going to come back around to the beginning of this argument.

Pete

 

[Kevin Spencer]

IMHO:

I would agree with the developer

scratch in .NET. It would be a LOT longer than the script you posted, but
I don't see any reason it couldn't be done. It may or may not be within
the skill set of the developer, but it's technically possible.

The best, most theoretically robust solution would probably be to just do
everything from scratch, based on the SMTP definition. But in reality,
Microsoft tries very hard to maintain backward compatibility, and I think
it's unlikely that CDO is going to go away any time soon. Because of
that, it may be most efficient for the developer to invest his time
becoming familiar with how interop works in .NET and using that to use CDO
just as the VB6 code you posted does.

*NOT* IMHO:

COM Interop is something to avoid when possible, for various reasons,
including performance and complexity. In addition, as I mentioned in my
original and detailed response to the OP, the System.Net.Mail Namespace in
the .Net 2.0 platform is all that is needed to send email, and the object
model is quite easy to use.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

If the Truth hurts, wear it.

 

[Peter Duniho]

*NOT* IMHO:

COM Interop is something to avoid when possible, for various reasons,
including performance and complexity.

Whatever. IMHO, if one is concerned about performance and complexity, the
entire .NET framework may be something one wants to avoid.

It seems to me that if you've got a COM object that implements the
functionality you desire, and there's no more elegant solution available,
that's the way to go.

In addition, as I mentioned in my original and detailed response to the
OP, the System.Net.Mail Namespace in the .Net 2.0 platform is all that is
needed to send email, and the object model is quite easy to use.

That's great, and very useful information. I'm glad to hear there's
something built into the .NET framework that supports the desired
functionality. However, this is the only reasonable argument against using
CDO as far as I'm concerned.

Pete

 

[Mike Lowery]

IMHO:

* It's a mistake to use public newsgroups as a way of resolving internal
departmental differences. If the developer finds out that you did so, it's
sure to only increase any animosity that may exist currently.

IMHO:
If posted anonymously and in a careful way, it's unlikely the developer would
ever know, and in reality it should matter little even if he did. We've all
worked with people who like to baffle us with B.S. and it's everyone's right to
research a subject further by asking other experts. That's just good business.
Otherwise one strong-headed employee can snowball everyone else because nobody
knows better or are too intimidated to confront the person. Bad business.

Of course there can be extremes to this and someone shouldn't question every
decision a person makes, especially if they know little about the subject
themselves (just enough to be dangerous.)