How can I save emails to my local desktop folder in Microsoft Outlook 2007? I need a plugin or can you help me in writing a plugin with some suitable code as reference. I don't have permission to create *.pst. I don't want to save it manually everytime.
There are several commercial solutions available, for example: MessageSave or MailToFile, but I understand that you're looking for a free alternative. In that case you may check SharepointUpload.
Despite its name it allows to a normal folder.
Note: Although the tool was designed for SharePoint's naming restrictions, the tool can be used to extract all the above to a normal folder (e.g. C:\Temp).
It's freeware and you have also available the source code so you could modify the product if it doesn't meet your needs.
SharePoint Upload is a command line freeware tool (with .NET source) that can extract e-mails from PST, Public Folders, and Exchange Mailboxes and place on a file system in MSG format (using Redemption)
Related
What methods exist to include parameters (such as userid) into the setup.exe that users download from a server?
I'm looking for a way to give a customized installer to users that I already know (because they are logged in).
Is your question tied with some technology/installation system? Or you are researching which installation system to use to achieve this functionality?
In NSIS there is option to append custom data to installer, see this article: http://nsis.sourceforge.net/ReadCustomerData.
Maybe the easiest would be to send a setup_whateverparameter.exe filename instead of setup.exe...
A smarter approach would probably be to store parameter into a ressource file which would be edited from command line with some tool like http://www.reseditor.com/
Another one would be to generate a sort of INI file which would be packed with the original setup file using some installer software like Inno Setup (http://www.jrsoftware.org/isinfo.php) and the original installer would be configured to check if some ini file exists in a temporary location, to just use its content to do specific tasks.
Other possibilities might exists, thoses are just the one which might be the most easy to implement.
#elfrancesco hinted at Ninite and Patrick from Ninite got back to me with:
We put the installer id in a segment of the .exe that doesn't get
included in the hash for the signature. So we just sign our loader
.exe once whenever we update it and then our web server drops in the
key for each download.
I have an old Legacy Application Developed in VB 6.0. They used some 3rd Party controls using IGSplash40.OCX,PVCalendar9.OCX etc..The code works fine in one server.
They have installed Infragistics NetAdvantage 2004 Vol.1 tool to use those controls in VB Application. Now I have to move the application to another computer.
When I open the application especially forms..It says unable to load xxxform.refer logs for details and while running also It says 'License information for this component not foud. you do not have appropriotate permisson to use this functionality in designer environment'.
Also, I collected those ocx files from another server and tried to run my application.
How to resolve this?
The developer package for controls normally includes not only the OCXs and DLLs involved, and not only the documentation, but an installer that puts the libraries, docs, and any necessary design-time licenses in place and registers them.
If you find yourself copying such files in place and manually registering them you're likely to fail unless you have some freeware library.
Even freeware libraries should come with a proper set of docs, a DEP file, and dev machine install package to put everything in place. Merge modules are a nice thing to offer as well. Sadly most freeware authors are generous if they offer a readme file.
There is more to the ecosystem of an OCX than just the OCX file itself.
The only fix is to replace these controls with controls that you do have licenses for, buy alternatives, or try to contact the original vendor about supplying a replacement install package or acquiring a new license and new package.
In Windows 7 you will find the usual .ocx files in the folder Windows\SysWOW64. In that folder there are a number of .srg files that seem to be the corresponding licenses. My problem was with richtx32.ocx and I had to open the corresponding RICHTEXT.SRG file, and create in the registry the corresponding key and introduce the license string manually.
MSCRM 4.0
Problem:
I'm currently storing xml files in the ISV directory along with my web applications. From a plugin (or potentially a seperate app), I need to find an easy way to navigate to the ISV directory to read these xml files. This routine will be called extremely often, so processing minimization should be a strong consideration.
Potential solutions:
Registry: There is a registry key called 'WebSitePath' with the data 'C:\Inetpub\wwwroot\CRM'. Could potentially use this to build the path. (Will this be the same on all systems/installations?)
IIS directory data: Looping through the DirectoryEntries of path '"IIS://localhost/W3SVC"' I could obtain the the web application where description is equal to "Microsoft Dynamics CRM". (Will this be the same on all systems/installations?)
Webservice: Create one to read and return the data contained in these xml files The webservice would have easy access to its executing directory.
Database: Store the data of these files in the database.
Help:
Can anyone suggest a simpler solution to obtaining and reading a file from the ISV directory? If not, which of the above solutions would be the quickest to process?
Thanks for any and all contributions.
If you manage your deployment, I would first try to access the file at the location that you think the file can be found (like an hint). If you can't find it, I would try to retrieve the ISV folder location using the registry.
If you are not controlling the deployment, using a file in the ISV folder is not a good solution, because CRM can be deployed using different roles, and the ISV folder is not necessarily on the same server, so I would rely on a external database.
I need to recover the contents of an OST file from Outlook 2003. I don't need to do this so badly that I'm willing to pay the hundreds of dollars some companies charge for recovery utilities; I'm more interested in doing this from the intellectual challenge side of things. Are there any recommended libraries for doing this? I'd prefer something in either C# or Java.
If you want to do it as an exercise you may want to write your own library.
PST format specification
Wiki article on PST and OST file formats
lipff - opensource C library and tools to access the Personal Folder File (PFF) and the Offline Folder File (OFF) format. PFF is used in PAB (Personal Address Book), PST (Personal Storage Table) and OST (Offline Storage Table) files.
PST file format SDK C++. Can read PST and OST files.
I ran into the same problem. There seems to be a bunch of commercial tools, but I was only able to find one open source tool libpst. The (limited) documentation only talks about .pst files, but it worked like a charm on both .pst and .ost files for me (Outlook 2003, I believe).
I had a few issues compiling it. It couldn't seem to find the Python::Boost lib, but the following worked:
./configure --without-boost-python --disable-python && make
No need to rename the .ost file or convert it with scanpst.exe. Something like readpst -M outlook.ost will dump all your emails into files under the current dir.
Rename the .ost extension to .pst and run scanpst.exe in your Office installation directory. For versions prior to Outlook 2007 this will convert your OST to a PST.
Maybe you could check Alioth LibPST. If you know C, you can probably go through the source code and make it do whatever you would like to do.
I have a VB6 application that needs to be installed on Windows Vista as a Standard User. Using Visual Studio 2005 I have created a setup project that will place the application in a standard user safe place or folder. I also have a dll that I want to install and register to the users application data folder. Once my windows installer is created in VS'05 I flipped the word count properties' 3rd bit using msiinfo.exe so that Vista will not prompt Admin credentials when it runs the msi. The application installs without any problems until it tries to register the dll to the users application data folder. When it reaches that point it throws an error stating that it cannot register the type library for the dll. It appears the installer does not have the authority to register a dll to the users folder. Is this correct? My understanding was that Vista only complained about standard users updating or changing items that affected all users of a machine. Any ideas? Thoughts? Suggestions?
Steve
My suggestion is, if you are able, to use regfree com / manifest files instead of registering the ocx/dll files, which as you mention is a real chore under a basic user account.
There is an excellent free app you can use to build the manifest for you as well here: http://mmm4vb6.atom5.com/
We have been using this for a few years now, with no issues.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
Instead of registering your DLL files directly, you can use RegFree COM.
This involves creating an XML manifest file for your app, so Windows will look for your DLL files in the application folder, instead of using the system registry to find them.
This means your app will run properly without your installer having to register DLLs.
These links have more info:
http://msdn.microsoft.com/en-us/magazine/cc188708.aspx
http://www.devx.com/vb/Article/32888/1954
You can use the free Make My Manifest software to create the manifest files you need:
http://mmm4vb6.atom5.com/
Generally I agree to what Joel Coehoorn says in his answer.
However, knowing how the registry works in this regard, I can make the suggestion that you try to manually register your DLL to HKEY_CURRENT_USER\SOFTWARE\Classes, basically repeating what regsvr32.exe would do to HKEY_LOCAL_MACHINE\SOFTWARE\Classes.
It's a bit of a hack, and maybe it won't work, but you can try it.
related post on MSDN: http://msdn.microsoft.com/en-us/library/ms693350.aspx (thanks to MarkJ pointing this out in the comments)
related post on vbforums.com: http://www.vbforums.com/showthread.php?t=507228
Unattended Make My Manifest is a remake of MMM that can be used to generate manifests in automated builds. It uses a script file to add depended COM components.
Registry-free COM: MakeMyManifest is well spoken of. It is an automatic tool for creating manifests for VB6 projects: I haven't tried it myself.
DirectCOM is an alternative to registry-free COM. It also has fans, again I haven't tried it.
EDIT The MMM website is down. I see here that the author was having trouble with their hosting and has provided another location to get Make My Manifest - download it here.
There is a semi-automatic technique for creating manifests for registry-free COM. You can create the manifests with Visual Studio 2008 (you can use a free version like Visual Basic Express Edition). Then make a couple of edits by hand to make the manifests suitable for use from VB6. See this section of this MSDN article for step-by-step instructions - ignore the rest of the article which is about ClickOnce.
Registering a DLL does impact all users (DLLs are registered globally) and therefore requires Admin permissions. There is no way around that.
The solution for newer programming environments is that the DLL doesn't need to be registered to be used. However, since vb6 relies on COM you're probably out of luck.