An argument (okay a debate) 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 = "Aler...@fabrik am.com"
SendTo = "joeu...@fabrik am.com; 1298...@skytel. com"
strSubj = "NO SMTP service needed."
strContents = "Testing e-mail script."

sch = "http://schemas.microso ft.com/cdo/configuration/"
Set cdoConfig = CreateObject("C DO.Configuratio n")
With cdoConfig.Field s
.Item(sch & "sendusing" ) = 2 ' cdoSendUsingPor t
.Item(sch & "smtpserver ") = "mail.fabrikam. com"
'.Item(sch & "smtpserverport ") = 25 ' if you need to set a port
number
.update
End With

Set cdoMessage = CreateObject ("CDO.Messag e")
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 the equivalent code of this VBScript within .NET,
then you can run the VBScript 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 .NET 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 .NET 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. I don't see any references to WMI
in this VBScript. Even if there were, it'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 a
relatively simple task. And this UnZip functionality is something else
we're requesting, and the developer is pushing back on this as well.

He's claiming that to include code for UnZipping files, and code for
running executables from the command line, is too complex to the point
where it would increase the cost and man-hours of the project beyond
what's reasonable.

Am I missing something here? Does this developer have valid arguments?

Thanks.

- Dave

[Charlie Brown]

Dave, just a quick comment on the smtp... you can set up smtp on almost
any workstation or server running windows, and starting with dotnet
v1.1 you can use smtp authentication which should address security
concerns.
As far as sending a page goes, i'm guessing you mean sending a message
to a "pager" device. This is pretty easy as well, and you can find a
lot of free code out there to do so, as well as many online paging web
services you could access yourself. Some pager service providers also
allow sending text email to pagers, so you could use the same email
sending code also. Code to send secure email is only about 10 lines or
less.
All of this can be done over port 25 of the firewall, or if everyone is
really secure minded than you could modify it to use port 80, which is
what your internet browser traffic uses anyway.
Highlander wrote:

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 = "Aler...@fabrik am.com"
SendTo = "joeu...@fabrik am.com; 1298...@skytel. com"
strSubj = "NO SMTP service needed."
strContents = "Testing e-mail script."

sch = "http://schemas.microso ft.com/cdo/configuration/"
Set cdoConfig = CreateObject("C DO.Configuratio n")
With cdoConfig.Field s
.Item(sch & "sendusing" ) = 2 ' cdoSendUsingPor t
.Item(sch & "smtpserver ") = "mail.fabrikam. com"
'.Item(sch & "smtpserverport ") = 25 ' if you need to set a port
number
.update
End With

Set cdoMessage = CreateObject ("CDO.Messag e")
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 the equivalent code of this VBScript within .NET,
then you can run the VBScript 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 .NET 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 .NET 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. I don't see any references to WMI
in this VBScript. Even if there were, it'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 a
relatively simple task. And this UnZip functionality is something else
we're requesting, and the developer is pushing back on this as well.

He's claiming that to include code for UnZipping files, and code for
running executables from the command line, is too complex to the point
where it would increase the cost and man-hours of the project beyond
what's reasonable.

Am I missing something here? Does this developer have valid arguments?

Thanks.

- Dave

[Peter Duniho]

"Kevin Spencer" <uc*@ftc.govwro te in message
news:es******** *****@TK2MSFTNG P05.phx.gbl...

And *that* is all opinion. While I gave logical reasons for my counsel,
you simply stated opinions as if they were facts, without any logical
reasons to support them.

Your "logical reasons" were flawed, as I already pointed out. And yes, my
suggestions are subjective, but they are shared by the broader Usenet
community.

Furthermore, *I* am not asking for advice. How is your criticism helpful ?

I posted an alternative viewpoint to your instruction to the original
poster. If you don't want your viewpoints to be questioned, you should
probably keep them private.

[...]
Perhaps you have plenty of spare time. Mine is worth a good bit of money,

If you don't have the time to afford to help people gratis, you don't belong
here answering posts in a public newsgroup.

and I have very little to spare. And I don't believe that your opinion is
representative of the majority of experts who participate in these
newsgroups out of a sense of social conscience.

A sense of social conscience and attaching a monetary value to help offered
aren't exactly what I'd call compatible ideals.

Someone else's email address? Well, I suppose you must be a clueless dolt.
That is the US Federal Trade Commission's SPAM email address
(http://www.ftc.gov/opa/2002/02/eileenspam1.htm). As you may read in the
referenced web page, that address is specifically for the purpose of
forwarding SPAM.

For *forwarding* spam. The FTC has not advised users to publish that
address as their own.

I see that you disguise your email address to prevent SPAMmers from
sending you SPAM. I go one step better. I let SPAMmers send it directly to
the FTC. If you had Googled the email address, you would have found this
out before you embarassed yourself publicly.

The uc*@ftc.gov address is one that I've known about since its inception. I
know what it's supposed to be used for, and adopting it as your own email
address is not among the intended uses. Also, you may be interested to know
that the current and correct address is actually sp**@uce.gov.

Does it make you feel better to call me a "clueless dolt" and to claim that
I've "embarassed myself publicly"? Neither of those statements are true,
but if it helps your ego, I'll be happy to play along.

In any case, I remain amused at a supposed professional, with highly valued
time, claiming to be an MVP no less, acting the way you are acting. I guess
the word "profession al" doesn't carry the meaning it used to.

Pete

[Rob R. Ainscough]

You can't put SMTP on port 80 unless you don't want your browser to work.
Even with authentication, there is still a big security risk runnin SMTP on
any PC -- this is a spammers wet dream. Most security minded companies will
NOT allow SMTP on any workstation, on a server sure becaues they can control
it better, but on a workstation is just asking for trouble!

We tried this once, two workstations were successfully infected with a
spammer virus/malware (whatever you want to call it) -- bottom line is you
can't control workstation users unless you lock them down tight via SMS or
something else. It is much easier to lock down and manage a server.

A possible solution is you send the info to a local or remote server (if one
exists) and have it do the sending of Email. In general, you really do want
to avoid sending Email from workstations -- yes it can be done, but no you
really don't want to do it.

Rob.

"Charlie Brown" <cb****@duclaw. comwrote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Dave, just a quick comment on the smtp... you can set up smtp on almost
any workstation or server running windows, and starting with dotnet
v1.1 you can use smtp authentication which should address security
concerns.
As far as sending a page goes, i'm guessing you mean sending a message
to a "pager" device. This is pretty easy as well, and you can find a
lot of free code out there to do so, as well as many online paging web
services you could access yourself. Some pager service providers also
allow sending text email to pagers, so you could use the same email
sending code also. Code to send secure email is only about 10 lines or
less.
All of this can be done over port 25 of the firewall, or if everyone is
really secure minded than you could modify it to use port 80, which is
what your internet browser traffic uses anyway.
Highlander wrote:

>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 = "Aler...@fabrik am.com"
SendTo = "joeu...@fabrik am.com; 1298...@skytel. com"
strSubj = "NO SMTP service needed."
strContents = "Testing e-mail script."

sch = "http://schemas.microso ft.com/cdo/configuration/"
Set cdoConfig = CreateObject("C DO.Configuratio n")
With cdoConfig.Field s
.Item(sch & "sendusing" ) = 2 ' cdoSendUsingPor t
.Item(sch & "smtpserver ") = "mail.fabrikam. com"
'.Item(sch & "smtpserverport ") = 25 ' if you need to set a port
number
.update
End With

Set cdoMessage = CreateObject ("CDO.Messag e")
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 the equivalent code of this VBScript within .NET,
then you can run the VBScript 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 .NET utility
launches an executable from the command line. That's all the
functionalit y it needs. That's where it stops. No other requirements
for working within the .NET framework are needed - other than the
ability for the .NET 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. I don't see any references to WMI
in this VBScript. Even if there were, it'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 a
relatively simple task. And this UnZip functionality is something else
we're requesting, and the developer is pushing back on this as well.

He's claiming that to include code for UnZipping files, and code for
running executables from the command line, is too complex to the point
where it would increase the cost and man-hours of the project beyond
what's reasonable.

Am I missing something here? Does this developer have valid arguments?

Thanks.

- Dave

[Nick Malik [Microsoft]]

"Kevin Spencer" <uc*@ftc.govwro te in message
news:e4******** ******@TK2MSFTN GP04.phx.gbl...

Which brings me to my final point: Cross-posting to multiple newsgroups is
not considered good netiquette, and is likely to result in your not being
able to find any answers, since the answers will not necessarily be posted
to all of the newsgroups you posted to, and people who help others (such
as myself) do not like answering questions that have already been answered
elsewhere.

Hello Kevin,

I think your argument with Peter may have been triggered by a typo on your
part ;-)

The term 'cross posting' is usually used to refer to the practice of placing
one question in multiple newsgroups. On the other hand, the practice that
you appear to be referring to is the practice of placing questions in each
of two or three different newsgroups seperately (or in this case, twice in
the same newsgroup). That practice is unfortunate and irritating, but it is
not called "cross posting." It is called multiposting.

Crossposting is just fine, and in fact, this message is crossposted to three
different groups.

One article I like to refer people to is this one:
http://nitecruzr.blogspot.com/2005/0...encourage.html

If you read Peter's reply, it appears that he didn't pick up on your
intent... he keyed off of your terminology.

BTW: I know how valuable your time is. Thank you for sharing some of it
with this community. We are richer for it.

--
--- 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.
--

[Nick Malik [Microsoft]]

Hello Dave,

"Highlander " <tr******@msn.c omwrote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...

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.

He is partly right. SMTP services need to be running... somewhere. They do
not need to be running on the machine that sends the mail. In your example,
you are using SMTP from a server called mail.fabrikam.c om. Your developer
can do the same.

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.

The rest of his argument is mistaken.

>
ME: There is a workaround. The following script will send e-mail
without SMTP services.

You are partially right, in the same way that the developer is partially
right. Your script demonstrates that SMTP e-mail can be sent using a remote
SMTP server. Your script DOES use SMTP services... just not local SMTP
services.
And as for sending a page, you use the same

e-mail script, and include a skytel e-mail address:

This tells me that the term 'send a page' means to transmit to a skytel
pager using SMTP. You are correct in that the same code (whether in .Net or
in CDO) can be used to communicate with any mail client.

<< code clipped>>

>
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.

Once again, the developer is only partly right.
CDO is not part of the WMI library. WMI is a current technology, but CDO is
not. See:
http://msdn.microsoft.com/library/de...do_roadmap.asp

I suggest you move away from CDO.

On the other hand, CDO is just a code level interface to the industry
standard SMTP protocol, which is amply supported by .Net.
See http://www.systemwebmail.com

If you are using .Net 2.0, see
http://www.systemnetmail.com

>
ME: If you can't run the equivalent code of this VBScript within .NET,
then you can run the VBScript via command line. That would allow it to
be used in the .NET 1.1 or .NET 2.0 framework.

moot point. The developer was wrong about SMTP. You don't need to use
vbscript to do this.

>
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.

the developer is poorly informed and probably a novice .net developer.

>
ME: When the code migration has completed, then the .NET 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 .NET utility to launch an executable from the command
line, and pass it a couple parameters.

This is a reasonable requirement from your part. It won't be needed for
sending e-mail though. You may want to use this ability in other ways.
Code migration is often done using flexible scripts.

Even if there were, it'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.

It is.
http://msdn2.microsoft.com/en-us/lib...llexecute.aspx

Writing code to figure out if it completed correctly is a little more
difficult.
As long as you don't expect his utility to respond to errors thrown by your
command scripts, you are probably OK meeting in the middle on this.

>
I would imagine that writing the code in .NET to UnZip a file is also a
relatively simple task.

It is not. On the other hand, the SharpZip library is available for free to
unzip files. The developer does not need to know how to write this complex
code.
http://www.icsharpcode.net/OpenSourc...b/Default.aspx

>
He's claiming that to include code for UnZipping files, and code for
running executables from the command line, is too complex to the point
where it would increase the cost and man-hours of the project beyond
what's reasonable.

He needs to give you a cost estimate and let you decide how much is too
much. That said, it sounds like he is ill-informed, so his cost estimates
may not be that useful, unfortuately.

>
Am I missing something here? Does this developer have valid arguments?

He would if he knew a little more information. I hope my response helps to
clarify the discussion.
--
--- 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.
--

[Kevin Spencer]

Hi Nick,

Thanks for the good link and clarification re my terminology. You'd think
after all these years I'd get it right! ;-)

At any rate, I tried to explain the principle, since the OP was apparently
not particularly savvy about newsgroups, and was unlikely to find the
original answer. But I'm not well-known for my tender bedside manner - still
working on it, but a long way from where I want to be! I tend to get into
more "trouble" when engaging in cross-posted threads (like this one), where
my replies end up in groups where I am not well-known for much of anything!

As for thanks, none are necessary. I feel that giving back is the only way
to keep the flow of help and information flowing. When I was young I went on
a 6-week hike of the Long Trail in Vermont. One of the leaders made a
definite impression on my 15-year-old mind, teaching us that when we stayed
at a camp site, we should always leave behind more wood than was left by the
last group that stayed there, and leave it in better condition than we found
it. As I grew older I came to understand that, because there are those who
can not or will not replenish the supply, it is only logical for anyone who
is willing and able to ensure that the slack is taken up. So, I have gained
and learned much from these newsgroups, and I hope to help in my own small
way in ensuring their continued usefulness.

:-)

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

A man, a plan, a canal, a palindrome that has - never mind.

"Nick Malik [Microsoft]" <ni*******@hotm ail.nospam.comw rote in message
news:05******** *************** *******@comcast .com...

"Kevin Spencer" <uc*@ftc.govwro te in message
news:e4******** ******@TK2MSFTN GP04.phx.gbl...

>Which brings me to my final point: Cross-posting to multiple newsgroups
is not considered good netiquette, and is likely to result in your not
being able to find any answers, since the answers will not necessarily be
posted to all of the newsgroups you posted to, and people who help others
(such as myself) do not like answering questions that have already been
answered elsewhere.

Hello Kevin,

I think your argument with Peter may have been triggered by a typo on your
part ;-)

The term 'cross posting' is usually used to refer to the practice of
placing one question in multiple newsgroups. On the other hand, the
practice that you appear to be referring to is the practice of placing
questions in each of two or three different newsgroups seperately (or in
this case, twice in the same newsgroup). That practice is unfortunate and
irritating, but it is not called "cross posting." It is called
multiposting.

Crossposting is just fine, and in fact, this message is crossposted to
three different groups.

One article I like to refer people to is this one:
http://nitecruzr.blogspot.com/2005/0...encourage.html

If you read Peter's reply, it appears that he didn't pick up on your
intent... he keyed off of your terminology.

BTW: I know how valuable your time is. Thank you for sharing some of it
with this community. We are richer for it.

--
--- 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.
--

[Charlie Brown]

Your correct Rob, I should NOT have said workstations in my reply, only
servers. I should have said use SMTP auth between the client and the
actual SMTP server, which is listed in the script example. Since the
OP already has an SMTP server, using that with auth between the app and
the server is the way to go.

Rob R. Ainscough wrote:

You can't put SMTP on port 80 unless you don't want your browser to work.
Even with authentication, there is still a big security risk runnin SMTP on
any PC -- this is a spammers wet dream. Most security minded companies will
NOT allow SMTP on any workstation, on a server sure becaues they can control
it better, but on a workstation is just asking for trouble!

We tried this once, two workstations were successfully infected with a
spammer virus/malware (whatever you want to call it) -- bottom line is you
can't control workstation users unless you lock them down tight via SMS or
something else. It is much easier to lock down and manage a server.

A possible solution is you send the info to a local or remote server (if one
exists) and have it do the sending of Email. In general, you really do want
to avoid sending Email from workstations -- yes it can be done, but no you
really don't want to do it.

Rob.

"Charlie Brown" <cb****@duclaw. comwrote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Dave, just a quick comment on the smtp... you can set up smtp on almost
any workstation or server running windows, and starting with dotnet
v1.1 you can use smtp authentication which should address security
concerns.
As far as sending a page goes, i'm guessing you mean sending a message
to a "pager" device. This is pretty easy as well, and you can find a
lot of free code out there to do so, as well as many online paging web
services you could access yourself. Some pager service providers also
allow sending text email to pagers, so you could use the same email
sending code also. Code to send secure email is only about 10 lines or
less.
All of this can be done over port 25 of the firewall, or if everyone is
really secure minded than you could modify it to use port 80, which is
what your internet browser traffic uses anyway.
Highlander wrote:

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 = "Aler...@fabrik am.com"
SendTo = "joeu...@fabrik am.com; 1298...@skytel. com"
strSubj = "NO SMTP service needed."
strContents = "Testing e-mail script."

sch = "http://schemas.microso ft.com/cdo/configuration/"
Set cdoConfig = CreateObject("C DO.Configuratio n")
With cdoConfig.Field s
.Item(sch & "sendusing" ) = 2 ' cdoSendUsingPor t
.Item(sch & "smtpserver ") = "mail.fabrikam. com"
'.Item(sch & "smtpserverport ") = 25 ' if you need to set a port
number
.update
End With

Set cdoMessage = CreateObject ("CDO.Messag e")
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 the equivalent code of this VBScript within .NET,
then you can run the VBScript 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 .NET 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 .NET 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. I don't see any references to WMI
in this VBScript. Even if there were, it'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 a
relatively simple task. And this UnZip functionality is something else
we're requesting, and the developer is pushing back on this as well.

He's claiming that to include code for UnZipping files, and code for
running executables from the command line, is too complex to the point
where it would increase the cost and man-hours of the project beyond
what's reasonable.

Am I missing something here? Does this developer have valid arguments?

Thanks.

- Dave