oEmail= Createobject("wwSMTP") && crashed with a popup message 'This application requires one of the following versions of .NET Framework: Local_ ... do you want to install ? (yes/no)' VFP will quit no matter the answer.

The captured error was ' member oBridge not found ' as a result.

This error only occurs on Windows 10 desktops, but not for users connected thru RDP server (Windows Server 2016). And it seems it does not happen all the time; sometimes you restart the PC and then it works for a while.

Any help is appreciated.

Steve Yu in Houston

.NET is a pre-installed Windows component so it should always be present unless it somehow was explicitly uninstalled (not even sure if that's possible even).

But sure sounds like .NET is not installed on that machine.

I would at minimum update to the latest version of v6 which is v6.21.

+++ Rick ---

Thanks for replying, Rick. The .net mode 0 is just not reliable in our network. It works most of the time on most PC's but not all. At this point I just want to make classic mode 2 to work, but can't make it work at all. I just upgraded Client Tools from 6.17 to the current 7.27 and I'm getting this in my smtplog.txt:

2022.10.6 16:18:22:481 - rec: 250-CMEXCH.crownmark.com Hello [192.168.1.19] 2022.10.6 16:18:22:481 - rec: 250-SIZE 37748736 2022.10.6 16:18:22:481 - rec: 250-PIPELINING 2022.10.6 16:18:22:496 - rec: 250-DSN 2022.10.6 16:18:22:496 - rec: 250-ENHANCEDSTATUSCODES 2022.10.6 16:18:22:512 - rec: 250-STARTTLS 2022.10.6 16:18:22:512 - rec: 250-X-ANONYMOUSTLS 2022.10.6 16:18:22:512 - rec: 250-AUTH NTLM 2022.10.6 16:18:22:527 - rec: 250-X-EXPS GSSAPI NTLM 2022.10.6 16:18:22:527 - rec: 250-8BITMIME 2022.10.6 16:18:22:543 - rec: 250-BINARYMIME 2022.10.6 16:18:22:543 - rec: 250-CHUNKING 2022.10.6 16:18:22:543 - rec: 250 XRDST 2022.10.6 16:18:22:559 - snd: auth login

2022.10.6 16:18:27:559 - rec: 504 5.7.4 Unrecognized authentication type 2022.10.6 16:18:27:559 - *** MAIL SENDING FAILED: 504 5.7.4 Unrecognized authentication type.

</>

set procedure to \\...\wwsmtp  && at start up
.
.
.
 LOCAL oEmail as wwSmtp
 oEmail= Createobject("wwSmtp")
 With oEmail
   .cMailServer= Trim(m0smtp)
   .cSenderEmail= Trim(msender)
   .cUsername = m0smtpuser    
   .cPassword = m0smtppass
   .cLogFile = "x:\steve\0\smtplog.txt"
*    .nMailMode = 0   && DotNet
    .nMailMode = 2   && 10-05-22 *yu  
    .nTimeout = 5
    .lUseSsl = .F.
   .cRecipient= memail
   .cCCList= memailcc
   .cBCCList= ""
   .cSubject= msubject
   .cContentType = "text/html"   
   .cMessage= msg
   .cAttachment= mattach
   llResult = .SendMail()
   If !llResult
     mnote = Substr(.cErrorMsg,1,100)
     mok = .F.
   Endif
 Endwith
 

Same syntax works in mode 0 (always does for me in a RDP session but fails in some desktop PC's as previously described)

Please advise.

Steve Yu

There's a starttls in there so that means the server expects SSL - you can't use classic mode for SSL connections.

+++ Rick ---

How do I turn off SSL for the classic mode to work ? I thought .lUseSsl = .F. was enough.

Classic mode can't do SSL. You can't turn it off - the server request it and the client has to provide the SSL connection (TLS actually).

It's not something the client can control. The server determines the protoocl.

+++ Rick ---

So basically for this server, classic mode will not work unless the TLS is turned off at the server ?

Correct.

That's what .NET mode is there for. It is meant to address the TLS issues as that's not something that is natively supported by the Win32 stack that's used in classic mode.

I'm curious to understand what would cause .NET to not work on a Windows 10 machine.

Looking at your error message again - are you sure you have the correct version of wwipstuff.dll and wwdotnetbridge.dll that matches your version of wwDotnetBridge.prg - these files are matched sets. Old versions of those DLLs (either the XP specific version or old versions) were compiled for older version of .NET and if you didn't update the DLLs that could be the reason you get the 'install .NET version' messages.

+++ Rick ---

Can you tell if the wwdotnetbridge.dll as attached is the correct version for Client Tools 6.17, which is the one in use with the errors ?

I may just have to rebuild my apps with the updated client tools 7.27 to see if the errors will go away.

Thank you for your time again, Rick.

Steve Yu in Houston

Look at the version number in the DLL files.

• In Explorer select wwDotnetBridge.dll or wwipstuff.dll
• Right Click
• Properties
• Details Tab
• Version number should show

If that's not it, make sure that the .NET Version is set on startup to avoid potential problems with other code that's trying to load a different version. At this point version should never be specified (everything should run on .NET 4.0 which is 4.0 for the version) which is the default and all internal components don't specify the version.

Ideally you'd set the .NET version on startup using InitializeDotnetVersion() somewhere in your application startup code and then never specify a version number. All the libraries WW ships now don't specify a .NET version, but in the past when 2.0 and 4.0 lived side by side they did so there maybe old code lur

More info here:

wwDotnetBridge.InitializeDotnetVersion()

None of this should be an issue if you just start using the library - this only might be a problem if you've used it in the past and have old code that uses older versions that might have used explicit version number specifications.

The best way to test is to do it independently of the rest of your application - create a small test program you can run that does nothing but send an email with the known good versions and see if that works.

+++ Rick ---