Open mails in outlook from C# using the protocol “mapi://” - c#

I wish to execute a URL in the format
mapi://{S-1-5-21-1626573300-1364474481-487586288-1001}/toto#mycompany.com($b423dcd5)/0/Inbox/가가가가곕갘객겒갨겑곓걌게겻겨곹곒갓곅갩갤가갠가 , which I got from searching via Windows Desktop Search.
On Vista with Outlook 2007, this fails to open Emails if outlook is already open. Except sometimes, when it works for mysterious reasons.
Below are some things I've tried in an attempt to get this to work:
Executing it with Process.Start, or executing it with Process.Start via cmd.exe /c start. The former froze for a minute, then did nothing, with Process.Start returning null (except when Outlook was not already open, when it worked). The latter popped up an "Unspecified Error" message box.
Open mails in outlook from java using the protocol "mapi://"
I couldn't figure out how to get this script to work. The vbs scripts I generated claimed to have found invalid characters. Also, this solution makes me sad.
http://social.msdn.microsoft.com/forums/en-US/windowsdesktopsearchdevelopment/thread/00491710-e245-452f-8b0a-56caa56277e4/
I suspect this solution will work. However, I couldn't get it working in C++ or C# due to compiler errors. This is a matter of not being sure which libraries to include or in C# how to effectively use ShellItem2 etc. with interop.
Creating application shortcut in a directory
I tried creating a shortcut and calling Process.Start on that. This also did not work, though the shortcut itself worked when I double-clicked on it.

Turns out the issue was a UAC issue. I tend to run VS as admin, since some apps need it.

Related

C# Excel 2010 Workbook Open error

We recently upgraded from Excel 2007 to Excel 2010, and we have found that existing code started failing.
Exception Message:
Office has detected a problem with this file. To help protect your
computer this file cannot be opened.
We have traced this to the line where we open the file
excelApp.Workbooks.Open
Even when opening the file manually, the Protected View Messagebox comes up.
How can we work arround this using C#.
Have a look at using Application.FileValidation Property (Excel) before your Open statement.
Returns or sets how Excel will validate files before opening them.
Read/write
Files that do not pass validation will be opened in a Protected View
window. If you set the FileValidation property, that setting will
remain in effect for the entire session the application is open.
You can set it to one of the enum values in MsoFileValidationMode Enumeration
msoFileValidationDefault
msoFileValidationSkip
if you set it to msoFileValidationSkip before the Open statement, it should bypass the check.
Something like
excelApp.FileValidation = MsoFileValidationMode.msoFileValidationSkip;
before the open statement.
Late to the game here, but this is a common annoyance: you need to define a 'Trusted Location'.
You're not the only developers encountering this problem when your code tries to open a spreadsheet file, and "Office has detected a problem with this file. To help protect your computer this file cannot be opened." is an extremely unhelpful error message.
Look up the Trusted Location code published by Daniel Pineault on DevHut.net in 2010:
DevHut code example: Trusted Location using VBScript
I'll get downvoted to hellandgone for posting VBA in a C# forum, so I'd better not post my implementation of Daniel's code (yes, I'm a VBA developer, bashing out VBA macros all day, not a real coder working with pointy things and curly braces). If you really want to see the VBA, it's in a reply to another post:
https://stackoverflow.com/questions/2962728/office-trusted-locations/28115700#28115700
I believe the proper salutation is 'Share and Enjoy'.
Do, please, put an acknowledgement of the original author, Daniel Pineault, if you reuse the code: it's been widely published without attribution on 'Expert' sites, and that's rather rude.
We had the same issue. Our SSIS package at SQL server uses Excel.Interop to parse files. One day we installed Office 2010 x64 on new server and for some files started getting error:
Office has detected a problem with this file. To help protect your computer this file cannot be opened.
At the same time, other servers work good. We found distinguish in versions of Excel: 14.04763.1000 doesn't work, but 14.0.7015.1000 works for us. The last version number belong to Office 2010 SP2. Eventually we downloaded SP2 and installed it,as result, the error has gone.

Windows service won't install: The specified service already exists

I'm writing a small service in C# and I've installed it and uninstalled it a couple of times and all of a sudden it won't install again. I tried to uninstall it and it says there is nothing to uninstall, but when I install it again I get the following message:
Error 1001: The specified service already exists
Now, I've tried the following solutions:
Close the service manager (as an open service manager may hold a
handle to it)
Tried to find it with SC QUERY and delete is using SC DELETE
(according to
Service already exists (when it clearly doesn't))
Tried to remove it in regedit (doesn't exist there)
I've correctly added the project output to Custom Actions (install,
commit, rollback, uninstall)
Restarted the computer (!)
I'm running out of ideas. There is absolutely no proof that the service is installed on my computer and even though thousands of developers seems to have had this problem (and I've even had it myself previously) I've never heard of a situation where none of the standard solutions actually works.
What could I have missed?
EDIT
I've been into regedit and I tried again to find my service, but this time I exported the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ section and searched it. I can find my service in the dump under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyService
But then I go there in the regedit view, it's not there. Any suggestions? How did I screw that up :?
RE-EDIT
Disregard edit, the service only shows in regedit while the install i showing the error message, but that's event weirder, the service is installed, then breaks and rollbacks...
As a temporary solution, you can change the name of the service slightly ( e.g. add or remove one or two chars from the service_name) but keep the display_name the same.
I would suggest looking and Sysinternals Process Monitor activity and going backwards trying to find what happened before the error was reported. You might be able to see that for example a certain reg key was accessed.
I had a similar issue to this (the service was in stopped state and then deleted by an overzealous disk space tidier) and to solve it I copied my new service to the same location as marked in the "Path to Executable" box, and then started the service.
No issues so far.

Error 1001 An error occured in sending the command to the application

COM Excel AddIn, C#, VS2008
The error happens occasionally when I install/uninstall my AddIn.
sometimes I see Error 1001 the specified file can not be found
Anyone know what causes these and how to fix? thanks
I use windows installer
http://msdn.microsoft.com/en-us/library/2w2fhwzz%28v=VS.90%29.aspx says if use [TARGETDIR], it should be like "[TARGETDIR]\" or "[TARGETDIR] ". I simply use /filepath = "[TARGETDIR]myinstallfile" in CustomActionData
What I do not understand is it works almost all time and fails occasionally
Also even if I change this to including space or backslash, I can't tell if that fixes issue since the issue does not happen every time. Anyone has experience? thanks
I found this and it fixes the issue though I am not sure I ever use DDE in my program
http://sympmarc.com/2010/02/04/microsoft-excel-error-there-was-a-problem-sending-the-command-to-the-program/
Then I found this http://www.opendylan.org/documentation/opendylan/interop2/inte_278.htm
It talks about COM Server
so I went to cmd, type in "Excel.exe /RegServer", then the error disappears.
I am not really not sure if this solution works for all cases.
In fact, I am concerned that I miss sth in installer.
Here is a Microsoft Support page related to an issue which looks quite similar to yours. So for me it looks like a bug in Excel rather than in your installer.
The article is quite large, but it boils down to making sure that:
your Excel app is not running with elevated rights
advanced setting "Ignore other applications that use Dynamic Data Exchange (DDE)" is unchecked
Other than that you might try to repair Excel installation or follow the advice given in this thread of ASP.NET forums to fix the registry for Excel installation.
I hope it helps someone facing similar issues.
If you get this type of error when uninstalling a VS setup project MSI, then the most likely reason is that TARGETDIR is not preserved between the install and the uninstall, therefore it has no value, and attempts to use it in an uninstall custom action will result in failure to find the file. The easiest solution (apart from always installing to known locations such as common files etc) is to save TARGETDIR to the registry and retrieve it later. In the VS IDE you can create a registry item with the value [TARGETDIR] to have it resolved at install time.

Cannot create ADODB.Connection with complicated programming chain

Ok so this is a really complicated problem, I will try my best to explain.
We have a c++ application which communicates with Sql Connection like so:
CoCreateInstance(_T("ADODB.Connection"))
This works fine.
We recently made all of our backend code into a Com Object. If I write a Vb program to load our Com Object and do some database operations everything works fine, CoCreateInstance(_T("ADODB.Connection"))
still works.
We use fitnesse for testing so I wrote a fixture that:
1) Takes a string of vb code input into an html page.
2) compiles the vb code
3) runs the vb code that uses our Com Object.
* fitnesse is a java application so the code path travels through Java as well.
Now when any operation touches the database the Com Object hits an exception. Uses message boxes, and removing code I narrowed the problem down to this line of code:
CoCreateInstance(_T("ADODB.Connection"))
normally the return code is 0, but with this chain of code calling code I get the return code: 800401F3 which says that it cannot find the object to load.
I am pulling my hair out trying to figure out whats going on. Any bit of insight would be greatly appreciated.
It is telling you that it cannot find the ProgId in the registry. That's not very healthy, it is a pretty standard component on any Windows install. Verify this, fire up regedit.exe and navigate to HKLM\Software\Classes\ADODB.Connection
If that is missing then you need to install the dbase providers on that machine. Download the MDAC 2.8 installer from Microsoft and run it. If it is not missing then you have a more mysterious problem, perhaps something to do with this being a 64-bit operating system. Look in HKLM\Software\Wow6432Node then. Get additional diagnostics by using the SysInternals' ProcMon tool to see what it is poking at in the registry.
As an alternative, you don't say whether your com "object" is a .dll. If it is, then make sure it is either "self-registering" or you'll need to run this at the command prompt.
regsvr32 myobject.dll
If it's an exe with COM objects, register the objects by running the program with the "/RegServer" command line option like this:
myobject.exe /RegServer
HTH

SharePoint fails to load a C++ DLL on Windows 2008

I have a SharePoint DLL that does some licensing things and as part of the code it uses an external C++ DLL to get the serial number of the hardisk.
When I run this application on Windows Server 2003 it works fine, but on Windows Server 2008 the whole site (loaded on load) crashes and resets continually. This is not Windows Server 2008 R2 and is the same in 64 or 32 bits.
If I put a Debugger.Break before the DLL execution then I see the code get to the point of the break and then never come back into the DLL again. I do get some debug assertion warnings from within the function, again only in Windows Server 2008, but I'm not sure this is related.
I created a console application that runs the C# DLL, which in turn loads the C++ DLL, and this works perfectly on Windows Server 2008 (although it does show the assertion errors, but I have suppressed these now).
The assertion errors are not in my code but within ICtypes.c, and not something I can debug.
If I put a breakpoint in the DLL it is never hit and the compiler says:
"step in: Stepping over non user code"
If I try to debug into the DLL using Visual Studio.
I have tried wrapping the code used to call the DLL in:
SPSecurity.RunWithElevatedPrivileges(delegate()
But this also does not help.
I have the source code for this DLL so that is not a problem.
If I delete the DLL from the directory I get an error about a missing DLL. If I replace it, back to no error or warning just a complete failure.
If I replace this code with a hardcoded string the whole application works fine.
Any advice would be much appreciated, I can't understand why it works as a console application, yet not when run by SharePoint. This is with the same user account, on the same machine...
This is the code used to call the DLL:
[DllImport("idDll.dll", EntryPoint = "GetMachineId", SetLastError = true)]
extern static string GetComponentId([MarshalAs(UnmanagedType.LPStr)]String s);
public static string GetComponentId()
{
Debugger.Break();
if (_machine == string.Empty)
{
string temp = "";
id= ComponentId.GetComponentId(temp);
}
return id;
}
This could be security related:
An important point is that it works in a console app.
In a console app RunWithElevatedPrivileges has no effect since it emulates the app pool user for your worker process, a user that should have no special rights on the box itself.
In contrast a console app runs in context of the logged in user.
Try emulating a user with rights like when you run the console application specified here (with Undo() inside try/finally mind you!). When obtaining the token you can create an SPUserToken and establish site context using the SPSite constructor that takes a GUID and a SPUserToken
Theres several examples out there documenting this approach, here for example.
EDIT: oh and the reason it worked on 2003 could be that your app pool account had way too many rights ;-)
Why not use WMI to get the serial number of hard disk, thus avoids execution of unmanaged code. See this sample How to Retrieve the REAL Hard Drive Serial Number
That non-deterministic crashing behavior is often seen with memory overwrites/corruption; sometimes it matters (crash), sometimes you get lucky.
You might want to check into getting a crash dump and analyze it with WindDbg. Since you have the source you could re-build it with the various stack, heap memory protection and warning systems enabled (depending on your compiler) and see what you get.
I'd find out if it is a User Account Control related problem, you can try to disable it.
2003 doesn't have UAC.
Your app pool account might not have the right to retrieve this information?
In visual studio, go into the properties of your executable assembly, and under the debug tab, check the enable debugging unmanaged code option.
If the method your are importing belongs to a class, you need to add the mangled C++ name (e.g. 2#MyClass#MyMethod?zii) as an entry point to the DllImport attribute (run depends on the native DLL to get it).
You do not need C++ for that: http://www.codeproject.com/KB/cs/hard_disk_serialno.aspx
If i put a breakpoint in the DLL it is
never hit and the compiler says :
"step in: Stepping over non user code"
That's the debugger, not the compiler, and if you configured it properly it wouldn't do that. Look for the options calls "Use native debugging" and "Just my code". The first one should be on and the second one off.
This problem may happen due to one of the problems listed below.
the web part may not have the right permissions to call the DLL or
you may not have set the appropriate trust level for your SharePoint site.
For the permission you can use impersonation and for the trust level below site can help you.
http://msdn.microsoft.com/en-us/library/dd583158(office.11).aspx
I made a new C++ DLL from scratch which works fine when referenced as a console application on Windows Server 2003 and Windows Server 2008, but as soon as I reference it from the DLL in SharePoint the same things happens and it won't run.
It does find the DLL, but I think it has no permissions to execute it, even if I put it into the My Documents section and reference it directly!

Categories

Resources