I am trying to make an Outlook 2003 add-in using Visual Studio 2008 on Windows XP SP3 and Internet Explorer 7.
My add-in is using custom Folder Home Page which displays my custom form, which wraps Outlook View Control.
I get COM Exception with 'Exception from HRESULT: 0xXXXXXXXX' description every time when I try to set Folder property of the OVC. Error code is a random number, every time is different. It is not the first access to control's properties, before that, View and ViewXML properties are set already. Control is marked as Safe for Scripting.
I am using value of the CurrentFolder.FolderPath property of the active explorer, which seems to be a right one:
Outlook.Explorer currentExplorer = app.ActiveExplorer();
if (currentExplorer != null)
{
ovcWrapper.Folder = currentExplorer.CurrentFolder.FolderPath;
}
This is top of the stack trace:
System.Runtime.InteropServices.COMException (0xXXXXXXXX): Exception from HRESULT: 0xXXXXXXXX
at Microsoft.Office.Interop.OutlookViewCtl.ViewCtlClass.set_Folder(String pVal)
at AxMicrosoft.Office.Interop.OutlookViewCtl.AxViewCtl.set_Folder(String value)..
This is happening only if the folder is located in non-default PST file. Changing to folder inside default PST file will produce no exception.
I must underline that everything worked just fine before I went to holiday :). It seems that Windows XP installed some updates which changed default security of Internet Explorer or Outlook 2003 while I was absent.
On the other (virtual machine) with Office 2007 and Internet Explorer 6, without any updates, everything is working just fine.
After a while, I finally find out what is the solution: change a name of the external storage to something new.
During startup of the addin, it loads the non-default PST file, and changes its name (not the name of the pst file, but the name of the root folder) to "Documents".
This is code:
session.AddStore("C:\\test.pst"); // loads existing or creates a new one, if there is none.
storage = session.Folders.GetLast(); // grabs root folder of the new fileStorage.
if (storage.Name != storageName) // if fileStorage is brand new, it has default name.
{
storage.Name = "Documents";
session.RemoveStore(storage); // to apply new fileStorage name, it have to be removed and added again.
session.AddStore(storagePath);
}
Solution is not to use 'Documents' as a name any more, but something new. Problem is not related to specific name.
Dobri Dan, nency :)I don't know if I can really offer a "silver bullet" solution given the information here...but here are a few ideas/notes to try out:Having worked with Outlook on a few projects in the past, I can tell you that it is a funny bird sometimes when it comes to giving/granting access to outside users/processes. It sometimes requires the user to manually confirm access or log in...so make certain that you have
app.Session.Logon()
taken care of somewhere.The other thing I notice is the use of app.ActiveExplorer() Make certain that this function is returning exactly what you think it is; It takes the topmost window on the user's desktop...which is usualyy but not always the window you are trying to work with, so just doublecheck.
Related
I have a problem with my Outlook addin.
First of all, a very very simple overview of the workflow:
The addin is supposed to get a folder list from the exchange server (public folders).
The user can select one of this folders.
The folderid of the selected public folder will be converted from the IdFormat EwsId to HexEntryId to get the mapifolder afterwards.
Then the user can open the folder in Outlook. This is done by setting the this.Application.ActiveExplorer().CurrentFolder.
The complete code:
// _service is an instance of ExchangeService (Microsoft.Exchange.WebServices.Data)
// The publicFolder is the selected public folder (type of Microsoft.Exchange.WebServices.Data.Folder)
var objAltPublicFoldId = new AlternatePublicFolderId(IdFormat.EwsId, publicFolder.Id.UniqueId);
var objId = (AlternatePublicFolderId)_service.ConvertId(objAltPublicFoldId, IdFormat.HexEntryId);
var outlookFolder = Application.Session.GetFolderFromID(objId.FolderId);
this.Application.ActiveExplorer().CurrentFolder = outlookFolder;
Most of the time this works good. But some users are getting an error while trying to open the folder.
The exception is always thrown by the method to get the mapifolder object ( Application.Session.GetFolderFromID(objId.FolderId);).
The error message is:
the message interface returned an unknown error if the problem persists restart outlook
But again, this only happens for a few users, but once a user goets this error there is a great chance that this problem will persist until the complete Office installation has been reinstalled. I haven't found any other way to fix this issue so far and the problem seems to come out of nowhere.
All I've found out so far is that the objId.FolderId always contains the correct value, and that this affects all folders, not only a specific one. But the user can manually open the folder in Outlook.
The Outlook versions of the affected people are 2016 and 365.
The affected assembly is the Microsoft.Office.Interop.Outlook.
The reference to this assembly has following properties:
Description: Microsoft Outlook 16.0 Object Library
Filetype: ActiveX
Identity: {00062FFF-0000-0000-C000-000000000046}\9.6\0\primary
Path: C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Office.Interop.Outlook\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll
Version: 9.6.0.0
I really hope that there is someone who's had the same issue and found a solution for that.
Right now, anything could be the source of the error. The Exchange Server, the network, outlook, the Microsoft.Office.Interop.Outlook assembly, the enabled cached mode.
I am using two outlook accounts from the same exchange server (i.e. same domain). We have an outlook add-in which we use to archive some emails from outlook to an external web application. While composing a new mail, it's possible to attach some files from external application to the mail being composed using the add-in.
Now things work perfectly when I have a single account on outlook. But after configuring another account and trying to do the same from secondary account, outlook gives error:
Outlook Initiator exception:
System.Runtime.InteropServices.COMException (0x80040107): Could not
open the item. Try again. at
Microsoft.Office.Interop.Outlook.NameSpaceClass.GetItemFromID(String
EntryIDItem, Object EntryIDStore)
I tried to dig into the code and found that the call to GetItemFromID() gives the exception shown above.
object item = ns.GetItemFromID(objectID, storeId);
The first parameter objectID (which is EntryIDItem) is different for different accounts but second parameter storeId is same.
I also tried to see the body of the method GetItemFromID() using disassembler but the method is defined as an extern method that means it's defined outside of the current assembly as un-managed code.
Tried to search for anything similar to that on stackoverflow but no luck. Can anybody please help me on this?
Try to leave only the first parameter. The EntryIDStore parameter is optional. See NameSpace.GetItemFromID for more information.
Note, the Entry ID changes when an item is moved into another store, for example, from your Inbox to a Microsoft Exchange Server public folder, or from one Personal Folders (.pst) file to another .pst file. Solutions should not depend on the EntryID property to be unique unless items will not be moved.
I have a windows forms application with a custom file extension set up. I am able to save data to my file, and when I double-click my saved file from Windows, it launches my application.
I have not, however, been able to get the name of the file I clicked on to read in its data. Everything seems to tell me args[0] should be the exe (as I'm seeing), args[1] would be the next parameter (probably what i'm looking for; the file name I clicked on) but args.Length is always just 1, whether I open the exe directly or click on a text file that launches the exe, I never have the file name I clicked on.
Edit (resolved; ish): OK, finally have a more specific issue nailed down. My application was deployed with ClickOnce, and I set up all the file associations through the windows forms application properties. When I right-click and view the properties of my saved custom file, it says "Opens with: ClickOnce Application Deployment Support Library" and not my application name. If I change the default to open with my .exe, magically it has the correct arg values (the exe, followed by the file name I clicked on).
You can't access command line arguments for ClickOnce applications directly. To get to them, I used the following, modified a bit from here:
System.Runtime.Hosting.ActivationArguments args = AppDomain.CurrentDomain.SetupInformation.ActivationArguments;
if (args.ActivationData != null)
{
foreach (string commandLineFile in AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData)
{
MessageBox.Show(string.Format("Command Line File: {0}", commandLineFile));
}
}
This gave me the file name I clicked on. Hoorah.
Okay first off this is NOT 'how do I find my local location of the click once app.' I know you can go Task Manager>Active Processes>(Find your click once app)>Open File Location. This is more on how do I know if I have four versions of a click once app for deployemnt of (Dev, QA, UAT, and PROD) how do I know which one has which remote install setup?
EG: So when you deploy a click once you choose a path in VS. Once you set up the path the user can go to the UNC path and then get their own local click once app, yay. What happens when this gets junked up? I just want to know simply:
How does the click once app reveal to me the local of the remote target in a place I can reference once the app is deployed?
Like a key pair list or something where I can see:
(Program DEV) | \\Devmachine\installs
(Program QA) | \\QAmachine\installs
From what I can tell from searching this is not as easy as it sounds to get. I am up for coding some C# .NET, some command line inputs, or some Windows commands to get to this information. I just cannot believe something like a target install folder is this hard to get when it is a REQUIREMENT to publish. The user basically uninstalled the program and naturally it did not remove the Click Once stuff at:
C:\Users\(username)\AppData\Local\Apps\2.0\LKE4469P.GDW\X7EMR5P8.B1Z\
I can find the similar named app folders but their naming does not match up to the manifests. And even when I look in manifests it appears the info is not there either unless it is in a masked form to decode.
The ApplicationDeployment.UpdateLocation property gives you the value for the remote location. It can be used like this:
// In any class
public static string GetDeploymentPath()
{
return ApplicationDeployment.IsNetworkDeployed
? ApplicationDeployment.CurrentDeployment.UpdateLocation
: String.Empty; // Debug mode
}
I am developing a Windows Phone 8 application but am having a lot of issues with file access permission exceptions hindering the approval of my application when ever I try accessing files in the "local" folder (this only happens after the application has been signed by the WP store, not when deployed from Visual Studio). To solve this I have moved all file operations to IsolatedStorage and this seems to have fixed the problems.
I only have one problem left though. My application needs to make use of the file extension system to open external files and this seems to involve the file first being copied to the local folder where after I can then manually copy it into IsolatedStorage. I have no problem in implementing this but it seems that a file access permission exception also occurs once the system tries to copy the external file into the local folder.
The only way I think this can be solved is if I can direct the system to directly copy into IsolatedStorage but I cannot figure how to do this or if it is even possible. It seems as if though the SharedStorageAccessManager can only copy into a StorageFolder instance but I have no idea how to create one that is directed into IsolatedStorage, any ideas?
PS. Do you think that the Microsoft system might be signing my application with some incompetent certificate or something because there is not a hint of trouble when I deploy the application from Visual Studio, it only happens when Microsoft tests it or when I install it from the store using the Beta submission method.
Below is a screenshot of the catched exception being displayed in a messagebox upon trying to open a file from an email:
EDIT:
Just to make it even clearer, I do NOT need assistance in figuring out the normal practice of using a deep link uri to copy an external file into my application directory. I need help in either copying it directly into isolatedstorage or resolving the file access exception.
Listening for a file launch
When your app is launched to handle a particular file type, a deep link URI is used to take the user to your app. Within the URI, the FileTypeAssociation string designates that the source of the URI is a file association and the fileToken parameter contains the file token.
For example, the following code shows a deep link URI from a file association.
/FileTypeAssociation?fileToken=89819279-4fe0-4531-9f57-d633f0949a19
Upon launch, map the incoming deep link URI to an app page that can handle the file
// Get the file token from the URI
// (This is easiest done from a UriMapper that you implement based on UriMapperBase)
// ...
// Get the file name.
string incomingFileName = SharedStorageAccessManager.GetSharedFileName(fileID);
// You will then use the file name you got to copy it into your local folder with
// See: http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.storage.sharedaccess.sharedstorageaccessmanager.copysharedfileasync(v=vs.105).aspx
SharedStorageAccessManager.CopySharedFileAsync(...)
I've inline the information on how to do this from MSDN http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206987(v=vs.105).aspx
Read that documentation and it should be clear how to use the APIs as well as how to setup your URI mapper.
Good luck :)
Ok I figured it out. The "install" directory is actually restricted access but for some reason the Visual Studio signing process leaves the app with enough permissions to access this folder. The correct procedure of determining a relative directory is not to use "Directory.GetCurrentDirectory()" but rather to use "ApplicationData.Current.LocalFolder". Hope this helps!