|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Argument with a developerIT 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***@fabrikam.com" SendTo = "joeu***@fabrikam.com; 1298***@skytel.com" 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 "Highlander" <tron9***@msn.com> wrote in message [snip]news:1159893053.381699.22300@h48g2000cwc.googlegroups.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. 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.) 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 To send email, an SMTP server is necessary. Note that I did not say SMTP > 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. 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 This is just rubbish. First of all, WMI is an integral part of the Operating > supported in .NET 1.1 or .NET 2.0 framework. The idea is to move away > from old technologies not to keep supporting them. 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. -- Show quoteHTH, Kevin Spencer Microsoft MVP Software Composer http://unclechutney.blogspot.com If the Truth hurts, wear it. "Highlander" <tron9***@msn.com> wrote in message news:1159893053.381699.22300@h48g2000cwc.googlegroups.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. 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***@fabrikam.com" > SendTo = "joeu***@fabrikam.com; 1298***@skytel.com" > 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 >
Show quote
"Highlander" <tron9***@msn.com> wrote in message IMHO:news:1159893053.381699.22300@h48g2000cwc.googlegroups.com... > [...] > 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? * 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 > IMHO: <snip>> I would agree with the developer <snip>One could write all of the necessary code from > scratch in .NET. It would be a LOT longer than the script you posted, but <snip>> 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 *NOT* IMHO:> 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. 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. "Kevin Spencer" <u**@ftc.gov> wrote in message Whatever. IMHO, if one is concerned about performance and complexity, the news:OAFraD65GHA.3644@TK2MSFTNGP03.phx.gbl... > *NOT* IMHO: > > COM Interop is something to avoid when possible, for various reasons, > including performance and complexity. 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 That's great, and very useful information. I'm glad to hear there's > 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. 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 "Peter Duniho" <NpOeStPe***@NnOwSlPiAnMk.com> wrote in message IMHO:news:12i5avlenj490b3@corp.supernews.com... > > 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. 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.)  |
|||||||||||||||||||||||
Other interesting topics