Use Redemption without logged in user – Asp.net

Also keep in mind, that some libraries and automation will easy work on your dev computer, but come publish time, it will not. Try a simple shell() via process.start, and you see that on a locked down server running IIS, that such simple commands don’t work on a production server.

It can be hard if not not outright having to do hand stands to get some simple commands, even starting notepad.exe will not work in most cases. The reason is during development, we are on our computer – a super user. On a working server, then IIS runs under restricted rights. And last time I looked, from c#, or VB.net, redemption is not used, nor required.

In other words, even using c#/vb.net on desktop? You are in most cases free to automate Outlook, and I don’t recall that redemption is required, or even works with vb.net/c# anyway. If you use the office interop assemblies to automate outlook, then the inter-op assemblies are already signed, and are able to freely use outlook.

In fact, from Excel, or VBA, using a .net .dll and writing your outlook automation is a GREAT WAY to dump and not require redemption. (this is what I do from VBA).

However, there are boatloads of means to send email from .net, and including the built in SmtpClient.

In other words?

From .net, you never and don’t need Redemption if you use office inter-op.

And from .net, you have a BOATLOAD of choices to send emails.

As as result, I would not even begin to think of using nor adopting redemption – you simple don’t need it. Try cooking up a small desktop program in .net, try the interop office assemblies – you see they work fine and you don’t see nor get nor receive any warnings about some program attempting to use outlook from .net.

The next big red flag?

As I stated, I have NOT tested running outlook from .net on a REAL production server, and since IIS runs in the context of IIS services, then the ability to do simple things is quite much locked down, as they don’t allow nor want web servers to automate software since it is a security hole the size of a wide open barn door.

Given all the above issues? Then I fail to see why outlook is even being considered here.

Worse yet? Unless you have your own web server, it is HIGH unlikey you going to find a hosted server that has outlook installed.

But, do try a simple .net desktop application. Use the inter-op office assemblies. You find that redemption is not requred. It is this road and path I use from ms-access now to launch outlook. Now, since Access 2010, you can from VBA easy automate outlook, and since Access is a office applcation, then it is considered safe and signed, and once agian, no nag prompts from office exist. So, for about 10 years now, using office inter-op from .net, or even using OTHER office programs, then you don’t need redemption anymore, and from VBA such automation simple works without any nags at all.

However, if you try to do this from non office program, or non .net inter-op assemblies? Then yes, you do get the nags. But, I have not see a outlook nag in 10+ years as result of above.

However, really, but REALLY? Trying to use outlook from asp.net is a beyond bad idea. Remember, while you can have many web users, you only have one web server, and EVERY user runs on that ONE server in the SAME process. If you attempted to use outlook with more then one user – you likly fast going to get in trouble. Unlike a desktop, were you have separate computers?

On a web server, all users are using the ONE instance of IIS, and they are all on the SAME process thread!!!!

That means, when you hit submit button, YOUR code behind runs, then page renders, and send back to user. Next post-back from ANY user on the system means the SAME thread, and same code and same thread will run and deal with the next user!!!! – only one program instance exists here – not one for each user of the web site.

So, try testing from desktop .net – you see that you don’t need redemption anymore.

But, worse yet? From a web server point of view, this is a really bad idea.