Setting Outlook automatic reply signature using C# is only partly working - c#

I am trying to set the default Outlook signature for both new messages and replies using C#.
Everything is working as expected for new messages (meaning that when I create a new message in Outlook, I can see the default signature), but nothing shows up when I reply to messages (or forward them).
This seems weird for two reasons:
In Outlook, I can see in the signature manager that that the default signature for replies is set properly. If I select another signature and select "Auto_Signature" again, everything starts working as expected, so it's not a problem with the signature itself.
The new messages signature is set the same way as the replies signature and that one works.
Here is the code that I am using to set the default signatures:
using Microsoft.Office.Interop.Word;
private void ApplyDefaultSignatureExecuted(object? obj)
{
var signaturesFolder = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "Microsoft\\Signatures");
var fileName = Path.Combine(signaturesFolder, "Auto_Signature.htm");
using (var writer = new StreamWriter(fileName))
{
writer.WriteLine("<html><body>");
writer.WriteLine("<div><p><i></span></b></p></div>");
writer.WriteLine(HttpUtility.HtmlEncode("Signature that was generated via C#"));
writer.WriteLine("</i></p><p><b><span style='font-size:24.0pt'>");
writer.WriteLine(HttpUtility.HtmlEncode("Name goes here"));
writer.WriteLine("</span></b></p></div>");
writer.WriteLine("</body></html>");
}
Application oWord = new Application();
EmailOptions oOptions = oWord.Application.EmailOptions;
oOptions.EmailSignature.NewMessageSignature = "Auto_Signature";
// This is the line that should be setting the auto-reply signature
oOptions.EmailSignature.ReplyMessageSignature = "Auto_Signature";
//Release Word, not sure if this has any effect as I get the same results with or without those lines
System.Runtime.InteropServices.Marshal.ReleaseComObject(oOptions);
System.Runtime.InteropServices.Marshal.ReleaseComObject(oWord);
}
And here are some screenshots to go along with my explanation:
Reply - Signature does not appear automatically
Signature manager - Default signatures are set properly by C#, and changing to another one and back makes everything work as it should
New message - Signature appears automatically
According to everything I have read, this should be working since setting the signature for new message and replies is the same code, but it's not. I am using Office 365 and I don't mind switching libraries if that solves my issues.

I got it working by simply changing the line
oOptions.EmailSignature.ReplyMessageSignature = "Auto_Signature";
To
oOptions.EmailSignature.ReplyMessageSignature = oOptions.EmailSignature.NewMessageSignature;
Everything is now working exactly the same for replies and forwards as it does for new messages.

Related

How to use GetExtentOfWord in the new IAsyncQuickInfoSource API?

I am writing a C# extension for Visual Studio and I am trying to use the new API for QuickInfos: https://github.com/Microsoft/vs-editor-api/wiki/Modern-Quick-Info-API. I am prototyping based on this sample: https://github.com/microsoft/VSSDK-Extensibility-Samples/tree/master/AsyncQuickInfo. It works fine as long as I don't change it.
The sample is only focusing on the whole line:
var line = triggerPoint.Value.GetContainingLine();
However, I need to get the hovered word. In the old API, I was using this and it was working fine:
var navigator = provider.NavigatorService.GetTextStructureNavigator(buffer);
var hoveredWord = navigator.GetExtentOfWord(triggerPoint.Value);
Unfortunately, Visual Studio will freeze as soon as I call GetExtentOfWord with the new API!!! More precisely, I will pass a few times and then it will freeze (quite shortly).
What should do I to be allowed to get the hovered word extent with the new IAsyncQuickInfoSource API?
Thanks!

New identity for TOR using c#

I'm using my TOR browser to connect to .onion websites and download data using c#. What I wanted to do, was add a button that allowed the user to get a new identity, but nothing I tried have worked so far.
I've tried using telnet, sending a webrequest to the port 9151, running a vbs that was supposed to do this, but nothing worked.
I have tried using TorSharp, but while that worked that only worked Async and I couldN't use that properly. I'm currently using com.LandonKey.SocksWebProxy.
How could I do this?
I'll add relevant code when I know what is needed, just ask.
EDIT:
#Ralph Wiggum
Sadly I can't remember every way I've tried creating a new Identity, as I've said, I tried running a VBS using Diagnostic.Process.Start(), but i doN'T have that script any more.
I also tried using WebRequest but I'm not even sure how that should be done.
This is how that looked as i can remember:
com.LandonKey.SocksWebProxy.Proxy.ProxyConfig pc = new com.LandonKey.SocksWebProxy.Proxy.ProxyConfig();
pc.SocksAddress = IPAddress.Parse(tb_Location.Text);
pc.SocksPort = 9151;
SocksWebProxy sw = new SocksWebProxy(pc);
HttpWebRequest wreq = (HttpWebRequest)WebRequest.Create("http://127.0.0.1");
wreq.Headers.Add("SIGNAL", "AUTHENTICATE \"\"");
wreq.Headers.Add("SIGNAL", "NEWNYM");
using (var wres = wreq.GetResponse())
{
using (var s = new StreamReader(wres.GetResponseStream()))
{
MessageBox.Show(s.ReadToEnd());
}
}
I also tried using telnet (using PrimS.Telnet), and that didn't work either. That looked something like this:
CancellationToken ct = new CancellationToken();
PrimS.Telnet.Client c = new PrimS.Telnet.Client("127.0.0.1", 9151, ct);
c.WriteLine("AUTHENTICATE \"\"\n");
c.WriteLine("SIGNAL NEWNYM");
#drew010
As I said, I did use TorSharp but I stopped. It was incredibly easy to create a new identity there, but it ran entirely Async, and I couldn't manage to fix it to use it with the rest of my code.
To get a new identity using through code, you need to open a connection to the control port (usually 9051 and disabled by default [edit your torrc to add ControlPort 9051]) and issue a NEWNYM signal to establish a new circuit.
To do it you can use the TorControlClient class in TorSharp.
using Knapcode.TorSharp.Tools.Tor;
TorControlClient tc = new TorControlClient();
tc.ConnectAsync("localhost", 9051);
tc.AuthenticateAsync(null); // you should password protect your control connection
tc.SendCommandAsync("SIGNAL NEWNYM");
You can also use this batch file to request a new identity but C# is probably better for your application. Reference that code to see the sequence on the control connection for getting a new identity.
See ControlPort and HashedControlPassword configuration options.
Hope that helps.

Rotativa ActionAsPdf() Very Slow

Using Rotativa 1.6.4 from NuGet and have noticed the following issue using the code below.
ActionAsPdf hangs randomly for indeterminate amount of time.
Code below that is hanging:
var pdfResult = new ActionAsPdf("Report", new {id = Request.Params["id"]})
{
Cookies = cookieCollection,
FormsAuthenticationCookieName = FormsAuthentication.FormsCookieName,
CustomSwitches = "--load-error-handling ignore"
};
Background info that may help:
The customSwitches is in use to ignore a documented issue calling wkhtmltopdf.exe using the ActionAsPdf, but it does not suppress errors in the code only in the wkhtmltopdf call.
Observations, usage and testing:
It works but when running the application (whether or not stepping through code), it can be anywhere from 10 seconds up to about 4 minutes between hitting the pdfResult = new ActionAsPdf and finally entering into the "Report" action being called. Can't discern anything actually happening in the output window of Visual Studio, no errors are being thrown that I have found. Just random slow transition into the Reports() action.
I can run the Reports() action directly via URL and it never slows like this and is quite fast for PDF generation. I am running it using the ActionAsPdf to obtain the binary to save to file system and send via email, which is the prescribed method of doing so for this library.
The behavior exists on both a local Windows 10 dev box and a remote Server 2008R2 Test box. .Net 4.5.1 on both boxes, default IIS on each.
Questions I have:
Any idea on what might cause this slow down and how to remedy it?
I ended up using UrlAsPdf() instead of ActionAsPdf() and it works. Seems there may be some issues with the ActionAsPdf() and I have filed a bug with Rotative project on GitHub. The ActionAsPdf() is still marked as beta, so hopefully it get's fixed in future versions or by the community.
In my case, I had to do few more tweaks along with using UrlAsPdf(). I have narrowed down the issue to the cookie collection that I was adding. So I tried just adding the cookie that I needed, and the issue was resolved. Following is the sample code that I have used.
var report = new UrlAsPdf(url);
Dictionary<string, string> cookieCollection = new Dictionary<string, string>();
foreach (var key in Request.Cookies.AllKeys)
{
if (Crypto.Hash("_user").Equals(key))
{
cookieCollection.Add(key, Request.Cookies.Get(key).Value);
break;
}
}
report.Cookies = cookieCollection;
report.FormsAuthenticationCookieName = FormsAuthentication.FormsCookieName;

ActiveDirectory error 0x8000500c when traversing properties

I got the following snippet (SomeName/SomeDomain contains real values in my code)
var entry = new DirectoryEntry("LDAP://CN=SomeName,OU=All Groups,dc=SomeDomain,dc=com");
foreach (object property in entry.Properties)
{
Console.WriteLine(property);
}
It prints OK for the first 21 properties, but then fail with:
COMException {"Unknown error (0x8000500c)"}
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Entry()
at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Current()
at ActiveDirectory.Tests.IntegrationTests.ObjectFactoryTests.TestMethod1() in MyTests.cs:line 22
Why? How can I prevent it?
Update
It's a custom attribute that fails.
I've tried to use entry.RefreshCache() and entry.RefreshCache(new[]{"theAttributeName"}) before enumerating the properties (which didn't help).
Update2
entry.InvokeGet("theAttributeName") works (and without RefreshCache).
Can someone explain why?
Update3
It works if I supply the FQDN to the item: LDAP://srv00014.ssab.com/CN=SomeName,xxxx
Bounty
I'm looking for an answer which addresses the following:
Why entry.Properties["customAttributeName"] fails with the mentioned exception
Why entry.InvokeGet("customAttributeName") works
The cause of the exception
How to get both working
If one wants to access a custom attribute from a machine that is not
part of the domain where the custom attribute resides (the credentials
of the logged in user don't matter) one needs to pass the fully
qualified name of the object is trying to access otherwise the schema
cache on the client machine is not properly refreshed, nevermind all
the schema.refresh() calls you make
Found here. This sounds like your problem, given the updates made to the question.
Using the Err.exe tool here
http://www.microsoft.com/download/en/details.aspx?id=985
It spits out:
for hex 0x8000500c / decimal -2147463156 :
E_ADS_CANT_CONVERT_DATATYPE adserr.h
The directory datatype cannot be converted to/from a native
DS datatype
1 matches found for "0x8000500c"
Googled "The directory datatype cannot be converted to/from a native" and found this KB:
http://support.microsoft.com/kb/907462
I have the same failure. I´m read and saw a lot of questions about the error 0x8000500c by listing attribute from a DirectoryEntry.
I could see, with the Process Monitor (Sysinternals), that my process has read a schema file. This schema file is saved under
C:\Users\xxxx\AppData\Local\Microsoft\Windows\SchCache\xyz.sch.
Remove this file and the program works fine :)
I just encountered the issue and mine was with a web application.
I had this bit of code which pulls the user out of windows authentication in IIS and pulls their info from AD.
using (var context = new PrincipalContext(ContextType.Domain))
{
var name = UserPrincipal.Current.DisplayName;
var principal = UserPrincipal.FindByIdentity(context, this.user.Identity.Name);
if (principal != null)
{
this.fullName = principal.GivenName + " " + principal.Surname;
}
else
{
this.fullName = string.Empty;
}
}
This worked fine in my tests, but when I published the website it would come up with this error on FindByIdentity call.
I fixed the issue by using correct user for the app-pool of the website. As soon as I fixed that, this started working.
I had the same problem with a custom attribute of a weird data type. I had a utility program that would extract the value, but some more structured code in a service that would not.
The utility was working directly with a SearchResult object, while the service was using a DirectoryEntry.
It distilled out to this.
SearchResult result;
result.Properties[customProp]; // might work for you
result.Properties[customProp][0]; // works for me. see below
using (DirectoryEntry entry = result.GetDirectoryEntry())
{
entry.Properties[customProp]; // fails
entry.InvokeGet(customProp); // fails as well for the weird data
}
My gut feel is that the SearchResult is a little less of an enforcer and returns back whatever it has.
When this is converted to a DirectoryEntry, this code munges the weird data type so that even InvokeGet fails.
My actual extraction code with the extra [0] looks like:
byte[] bytes = (byte[])((result.Properties[customProp][0]));
String customValue = System.Text.Encoding.UTF8.GetString(bytes);
I picked up the second line from another posting on the site.

How do I popup the compose / create mail dialog using the user's default email client?

The use case is simple. At a certain point of time, I need to be able to show the user his familiar compose email dialog (Outlook or other) with
fields like from, to, Subject already filled up with certain application determined values.
The email would also have an attachment along with it.
The mail should not be sent unless the user explicitly okays it.
I did this once back in the ol' VB6 days.. can't figure out how now.. I just remember that it was quite easy.
Managed app, C#, .net 3.0+
Update#1: Yeah seems like mailto removed support for attachments (as a security risk?). I tried
You need to include ShellExecute signature as described here. All I got from this was a 5 SE_ERR_ACCESSDENIED and a 2 just for some variety
string sMailToLink = #"mailto:some.address#gmail.com?subject=Hey&body= yeah yeah yeah";
IntPtr result = ShellExecute(IntPtr.Zero, "open", sMailToLink, "", "", ShowCommands.SW_SHOWNORMAL);
Debug.Assert(result.ToInt32() > 32, "Shell Execute failed with return code " + result.ToInt32());
The same MailtoLink works perfectly with Process.Start... but as long as thou shalt not mention attachments.
System.Diagnostics.Process.Start(sMailToLink);
The other options are using the Outlook Object model to do this.. but I've been told that this requires you to add assembly references based to the exact version of Outlook installed. Also this would blow up if the user doesn't prefer MS for email.
The next option are Mapi and something called Mapi33.. Status still IN PROGRESS. Ears still open to suggestions.
You can create a process object and have it call "mailto:user#example.com?subject=My+New+Subject". This will cause the system to act on the mailto with its default handler, however, while you can set subjects and such this wont handle adding an attachment. I'll freely admit im not entirely sure how you'd go about forcing an attachment without writing some mail plugin.
The process code is:
System.Diagnostics.Process.Start("mailto:user#example.com?subject=My+New+Subject");
It's probably not the most efficient or elegant way, but shelling a "mailto:" link will do what you want, I think.
EDIT: Sorry, left out a very important "not".
Since mailto does not support attachments, and since MAPI is not supported within managed code, your best bet is to write (or have someone write) a small non-managed program to call MAPI functions that you can call with command-line arguments. Pity that .NET does not have a cleaner alternative.
See also : MAPI and managed code experiences?
Could it be that you used the mailto: protocol?
Almost all of what you highlight can be done, but I am quite sure, that you cant do attachments.
Microsoft MailTo Documentation
Starting process with mailto: arguments is the simplest approach. Yet, it does not allow anything more or less complex.
Slightly different approach involves creating email template and then feeding it to the Process.Start:
var client = new SmtpClient();
var folder = new RandomTempFolder();
client.DeliveryMethod =
SmtpDeliveryMethod.SpecifiedPickupDirectory;
client.PickupDirectoryLocation = folder.FullName;
var message = new MailMessage("to#no.net",
"from#no.net", "Subject","Hi and bye");
// add attachments here, if needed
// need this to open email in Edit mode in OE
message.Headers.Add("X-Unsent", "1");
client.Send(message);
var files = folder.GetFiles();
Process.Start(files[0].FullName);
Scenarios for the default email handler:
Outlook express opens
Windows: Outlook - does not handle by default, Outlook Express is called instead
Windows: The Bat! - message is opened for viewing, hit Shift-F6 and Enter to send
I've also tested with Mono and it worked more or less.
Additional details are available in this post: Information integration - simplest approach for templated emails
PS: in the end I went for slightly more complex scenario:
Defined interface IEmailIntegraton
Code above went into the DefaultEmailIntegration
Added implementations for OutlookEmailIntegration (automation) and theBat! email integration (using their template format).
Allowed users of the SmartClient to select their scenario from the drop-down (alternatively this could've been implemented as "Check the system for the default email handler and decide automatically")
You're making the assumption that they will have an email client installed, of course.
The option I've taken in the past (in a corporate environment where everyone has at least one version of Outlook installed) was to use the Outlook interop - you only need to reference the earliest version you need to support.
You could look at P/Invoking MAPISendDocuments (which I'd try and avoid, personally), or the other option would be to create your own "compose" form and use the objects from the System.Net.Mail namespace.
you can use a trick if you intend to use Outlook[this code is based on outlook 2010[v14.0.0.]]
Create Outlook MailItem
and transmit file (ie download)
if user opens the file (.msg) the compose message dialog opens automatically
here is the code ...
Microsoft.Office.Interop.Outlook.Application outapp = new Application();
try
{
_NameSpace np = outapp.GetNamespace("MAPI");
MailItem oMsg = (MailItem)outapp.CreateItem(OlItemType.olMailItem);
oMsg.To = "a#b.com";
oMsg.Subject = "Subject";
//add detail
oMsg.SaveAs("C:\\Doc.msg", OlSaveAsType.olMSGUnicode);//your path
oMsg.Close(OlInspectorClose.olSave);
}
catch (System.Exception e)
{
status = false;
}
finally
{
outapp.Quit();
}
then transmit the file you created say "Doc.msg"
string filename ="Doc.msg";//file name created previously
path = "C:\\" + filename; //full path ;
Response.ContentType="application/outlook";
Response.AppendHeader("Content-Disposition", "filename=\"" + filename + "\"");
FileInfo fl = new FileInfo(path);
Response.AddHeader("Content-Length", fl.Length.ToString());
Response.TransmitFile(path,0,fl.Length);
Response.End();

Categories