Home > .NET, Azure, Crystal Reports, Visual Basic 6 > Vb6 software on Azure VM

Vb6 software on Azure VM


There are still customers that uses old, aged software: for example, i have customers using my old program for truck transports, that uses a Microsoft Access file as database.
As i wrote in this post, this software in installed on a on-premise server, which was tipically Windows server 2003.
Now, these old servers (often recycled) are dying, the hardware today is more cheaper than in the past but an Windows Server 2012 license is still expensive for a small office.
So the idea: let’s try to migrate to Azure!
So i began an incredible amount of try & catch (errors..)
The application requires to send emails via CDO , with an attached pdf file generated from the Crystal Reports engine (used from the app for the printing activities).
In order to print via CDO is required a working email client; in the old Windows 2003 there was by default Outlook Express, instead from 2008 version in Windows Server there is no more an email client: this can be resolved installing Windows Mail, but it requires .NET 3.5
First error: using an Windows Server 2012 DataCenter NOT R2.
The main problem with the “normal” version is, IMHE (In My Humble Experience) that .NET 3.5 is not installable because you can’t use the downloadable 3.5 installer and this must be done from the Server Manager that complains about missing sources (for example see here, but i was not able to achieve the same result) : could be that attaching an ISO file (of Windows Server 2012) it works.
But i lose no more time and try creating instead an Windows Server 2012 R2 vm: same complain about the missing sources, but this time .NET 3.5 installed without issues.
The installation of Windows Mail was without problems and so for my app.
The only problem is the calendar for date input: my vb6 app uses mscal.ocx (perhaps a wrong choice) which is problematic.
For example in the setup.lst file generated from the vb6 package installer wizard the mscal is generated as

File10=@MSCAL.OCX,$(WinSysPath),$(DLLSelfRegisterEx),$(Shared),5/7/98 12:00:00 AM,90112,

But the DLLSelfRegisterEx must be changed in DLLSelfRegister otherwise the setup is not successful.
And in every case the problem is that the calendar was not displayed (interface in Italian):

The solution was to recreate from scratch the VM and create an vb6 installer WITHOUT mscal.ocx: it is already present in the Azure vm and trying to install another mscal.ocx causes big troubles in the registry; now the mscal.ocx is working ok.
Another curious thing was that in the vb6 code

With Flds
    .Item("http://schemas.microsoft.com/cdo/configuration/smtpusessl") = boolUseSsl
    .Item("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate") = intSmtpAuth
    .Item("http://schemas.microsoft.com/cdo/configuration/sendusername") = strUser
    .Item("http://schemas.microsoft.com/cdo/configuration/sendpassword") = strPwd
    .Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = strSmtpSvr
    .Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = intSendUsing
    .Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = intSvrPort
End With

“microsoft” was accidentally written with the initial “m” uppercase, so the email sending was not working in the new 2012 R2 server (instead in Windows Server 2003 yes!); after the correction, emails sent.

%d bloggers like this: