I want to convert an MSG file (Outlook mail message saved as a file) to an EML (RFC822) file. I'd also like to reverse the procedure and convert the resultant EML file back to MSG. From what I read, I can do this with Redemption via VBScript.
I don't have or desire to have Outlook installed, so I installed Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 on my Windows 64-bit machine as recommended on the Redemption page. I'm trying to run the following code:
Set session = CreateObject("Redemption.RDOSession")
Set msg = session.GetMessageFromMsgFile("c:\temp\mail.msg", false)
msg.SaveAs "c:\temp\mail.eml", 1024
I get an error that states "Wrong OS or OS version". The OS is 64-bit, and Redemption installed as 64-bit, so I'm guessing the standalone MAPI library installed as 32-bit.
Does anyone know if I can get this to work with Redemption? If not, does anyone have other suggestions to convert these file types without having Outlook installed?
Your app bitness must match the bitness of the MAPI system, there is no way around that. See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for details.
You can either install the 64 bit version of Outlook (any version) or compile your app in 32 bit (x86).
Keep in mind that the standalone version of MAPI does not handle Unicode MSG files.
Related
I have created access front end ACCDR from Access 2016. In order for users to use this file, users need to install Access runtime 2016.
Most of my users already have MS Office 2007 or 2010 installed. So, when users try opening the ACCRD file, after install Access runtime 2016. They still get an error as they are opening the file using the older version of Access (aka 2010) and not the 2016 version.
My question:
How to check if the user has the correct version of Access set as default? I am fine with paying for a software which checks this. I am also fine with editing registry if any or importing registry if any.
[ACCDR files are created by renaming ACCDE (Access compiled files)].
You can read the version directly:
Version = Application.Version
Should return "16.0". If not, pop a message to the user to open using Access 2016.
Even better, provide a shortcut for the user to open your app with the runtime.
Best approach would be to query the COM just after you launched the process and act accordingly.
if you don't have an access process already running, just start one, query it, and do your stuff in the process that you just invoked.
Microsoft.Office.Interop.Access.Application _accessApp = new Microsoft.Office.Interop.Access.Application();
string version = _accessApp.Version;
Match the version string against Microsoft's version history:
https://en.wikipedia.org/wiki/History_of_Microsoft_Office
for office 2016, the string you're looking for is 16.0
Another approach is checking the GUID of office via the registry
and comparing it to a known office guids (they aren't random).
https://superuser.com/questions/1140114/how-to-detect-microsoft-office-version-name
I am trying to embed a picture file in my html string and send out the email using VB6.
I need to use this function AddRelatedBodyPart in the library of Microsoft CDO for Exchange 2000 Library.
Can someone please help me to install this library in VB6. Thanks
You need MAPI for Exchange 2000: MSMAPI32.OCX and cdosys.dll.
If you don't find such an old installer, may be googling on the net you will be able to find the correct version of this two files. Then, copy and register this two files by hand:
For example: regsvr32 %windir%\system32\cdosys.dll
A note aside: On a 64-bit version of Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Be sure to use the 32bit version.
To test the successfully installation, in the VBIDE go to Project->References and add "Microsoft CDO for Windows 2000 Library".
Now, press F2 to open the Object Browser. You should be able to find the function you need.
We have an old Powerbuilder app running on Server 2000 and need to move it. I am having a problem with moving the Powerbuilder app ver 7.0, to a newer platform - Server 2003.
We basically moved the directory with the app in it and all the Dlls. Then I registered the ones that would allow it. We also had to set up Informix client-side software and verified that it was able to connect to the Database.
The app basically takes 2 parameters then checks for data in a remote database, then generates a return code to be used by another app. The return code we get is unexpected and I have no luck in looking up the number:
-1073741811
The app is run from the command line. When I run the app I get a Windows error that mentions Sybase and msvcr80.dll and a dump, and the return code mentioned above - Here is the error from the manifest text:
Server=watson.microsoft.com
UI LCID=1033
Flags=99088
Brand=WINDOWS
TitleName=Sybase Inc. Product File
DigPidRegPath=HKLM\Software\Microsoft\Windows NT\CurrentVersion\DigitalProductId
RegSubPath=Microsoft\PCHealth\ErrorReporting\DW
ErrorText=This error occurred on 2/14/2013 at 7:56:14 AM.
HeaderText=Sybase Inc. Product File encountered a problem and needed to close.
Stage1URL=/StageOne/cert_lsi_exe/7_0_3_10180/msvcr80_dll/8_0_50727_6195/0001e6d5.htm
Stage2URL=/dw/stagetwo.asp?szAppName=cert_lsi.exe&szAppVer=7.0.3.10180&szModName=msvcr80.dll&szModVer=8.0.50727.6195&offset=0001e6d5
ErrorSig=AppName: cert_lsi.exe AppVer: 7.0.3.10180 ModName: msvcr80.dll ModVer: 8.0.50727.6195 Offset: 0001e6d5
DataFiles=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.mdmp|C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\appcompat.txt
Heap=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.hdmp
ErrorSubPath=cert_lsi.exe\7.0.3.10180\msvcr80.dll\8.0.50727.6195\0001e6d5
I am surprised by the msvcr80.dll request, because this app was written around 2003 and I didnt think that c compiler was at ver 8 yet. I have used Dependency Walker and see no complaints there. I am probably in DLLHell with this thing, though... does anyone have any ideas what to look for?
Thanks in Advance!
I still have a few PB 7 applications around.
Did you try Application Compatibility?
Navigate to the folder and right click on the executable and choose the Compatibility tab.
I suggest trying
Run this program in compatibility for Windows XP (Service Pack 3)
Privilege Level [x] Run this program as administrator
You may need to use Windows XP (Service Pack 2) or an earlier version of Windows.
I created a Delphi application which utilizes an ODBC data source to access text files in csv format. The driver is the "Microsoft Access Text Driver". But when I deploy my application on a Windows 7 computer it does not work because this driver is not available (there are only two available in odbcad32: sql native client and sql server)
How can I install this driver? I have tried to install MDAC, but it doesn't do anything. No errors or anythinig, but it just shows a quick scroll bar and that is it. And I have heard that MDAC has been replaced by WDAC on Windows 7.
EDIT: I should add this is Windows 7 Home, not Professional.
You have to run the ODBC Administrator from this location:
C:\Windows\SysWOW64\odbcad32.exe
then you will see all the x32 drivers
You might have to install the Microsoft Jet driver. I believe that Microsoft broke it out of MDAC awhile back, and it is no longer be installed by default.
EDIT After further research it appears that they have removed the text file drivers from the jet engine entirely. You can still use the Microsoft ODBC DB Provider for ODBC Drivers to access dBase and Excel files, but no longer text files.
Project JEDI has an open source TJvCSVDataSet
Why not lighten it up and use a VCL TStringList with TStringList.LoadFromFile() and forget about ODBC, MDAC, WDAC and whatever else weighs down the task at hand?
I found I could access the Microsoft text Driver if my application is compiled targeting x86 cpus.
I believe you'll need to install this package to get the text driver (among others).
Here's a CSV demo that doesn't require you to install any components or write any parsing code. If you can call my class .Create method, you can use this code without installing anything.
It uses two unit files that implement the JvCsvDataSet component, which is still a class, which can be instantiated the same way you can create a TStringList, you just create a TJvCsvDatSet.
I have created the necessary manifests for my COM server DLL and a client application to work registration-free in Windows XP. I've tested all kinds of combinations (with and without a registration) and in all cases the client application sees the side-by-side version of the library if the manifests are present, and the registered one if not (or a COM error if there is no registration at all). I've tested on my Windows XP development machine, and given the files (DLL, client EXE and one manifest for each) to co-workers, who've also run everything successfully on their own Windows XP machines. The manifests are external XML files, not embedded resources. So far, so good.
However, when I copy the files to a Windows Server 2003 machine, it doesn't work. I get a silent failure, but an application error in the Application Event Log (see below). If I unregister the DLL and remove the manifests, I get a similar error (silent at the command prompt, but an application error in the event log). Obviously there is some problem finding the registration. I have reproduced this on every Windows Server 2003 machine I can access at our company. According to the Microsoft documentation on side-by-side/registration-free COM, it's supposed to work on Windows XP and later, and Windows Server 2003 and later.
To be clear, the same client runs perfectly on those same Windows Server 2003 machines against a registered (i.e., using regsvr32) version of the same COM DLL, under the same login credentials I'm trying to use for registration-free COM. In other words, there are no intrinsic issues masquerading as registration-free COM problems - this client and server operate fine when the server is registered globally in the registry.
Anybody have any ideas of how to investigate further? I'm not an expert on Windows Server, but is there perhaps some policy setting that would need to be changed to enable this support? If I can locate the necessary change, our tech support/infrastructure people will probably have no probably doing it, but I can't rely on them to research the issue too as they are swamped.
In case it matters (I don't think it should, but you never know) the DLL is written in Delphi 2007, while the client is written in Visual C++.
Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004
Date: 5/2/2009
Time: 8:07:45 AM
User: N/A
Computer: ***server name****
Description:
Reporting queued error: faulting application ***program name***.exe, version 0.0.0.0, faulting module ***program name***.exe, version 0.0.0.0, fault address 0x0002ac9e.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
One thing to look for is that whether the exe has an internal manifest. In XP, the exe manifest search order is external then internal. In Server 2003 and later, the order is internal then external.
With a COM server created in Delphi 7, I have seen similar problems if the COM server was unregistered and the client application started under a restricted user account, because Delphi's COM implementation always tried to update the registration information, even when the DLL's RegisterServer function was not explicitly called.
To see whether this is a problem, attempt to run the client application on an account with unrestricted administrative privileges.
MSDN mentions, that under Windows 2003, problems with registration free COM servers should be detailed in a specific section of the system event log:
When troubleshooting registration-free
COM issues, the Event Viewer on
Windows Server 2003 is your friend.
When Windows XP or Windows Server 2003
detects a configuration error it will
typically show an error message box
titled for the application you have
launched and containing the message
"This application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix this problem." I
advise that whenever you see this
message you reproduce the problem on
Windows Server 2003, consult the
System Event Log and look for events
from the SideBySide source. The reason
I don't suggest that you look at the
Windows XP Event Log in these cases is
that it will invariably contain a
message such as "Generate Activation
Context failed for [path][application
filename].Manifest. Reference error
message: The operation completed
successfully," which doesn't help
identify the problem.
http://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6
Also, if possible, tell us the file names and contents of the manifest files you use.