| Author |
Topic |
|
jhermiz
3564 Posts |
 Posted - 2004-10-13 : 23:06:57
|
| I know in MS Access and in VB6 as well as C++ it was possibleto create an outlook task in an application and send it...I need to accomplish this same functionality in asp.net. How do I create an outlook task in asp.net/vb.net ?Thanks,Jon |
|
|
jhermiz
3564 Posts |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-10-16 : 16:52:31
|
| COM Interop should do the trick. |
 |
|
|
jhermiz
3564 Posts |
Posted - 2004-10-17 : 00:23:41
|
quote:
Originally posted by robvolk
COM Interop should do the trick.
Huh ???Provide more details than that please ????Has anyone done this...if so point me to some article / sample code / or anything. Telling me COM interop aint gonna cut it right now...I've lost half my brain cells to this problem... |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-10-17 : 07:38:25
|
| I don't have any particular details as I don't know .Net that well. But the COM Interop library allows you to instantiate COM objects in .Net and use them as you would in a VB6, C++, etc. application. The .Net documentation should have plenty of examples if you search for "COM". The Outlook help file will also have examples on how to create a task item. |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2004-10-17 : 08:02:38
|
quote:
Telling me COM interop aint gonna cut it right now
HAHAHAHAHAHAHAHAHAHAAHASorry Jon, sometimes you get what ya pay for  Damian |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-17 : 12:07:06
|
| robvolk,I understand that...please see my code in the other forum. I can run this project in C# or vb.net no problem with client application. But when I use ASP.net ... I am having issues. MichaelP / jsmith / any of the ASP developers, any experience with this ?Thanks |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-10-17 : 12:36:17
|
| I would look at the authentication issue more closely, as they suggested in that thread. The code you posted doesn't appear to connect or log on to Outlook/Exchange. Maybe the Outlook Interop doesn't require it, but all of the COM examples I've seen define a Session object that has to connect to an Exchange store via an account.And you need to reconsider having an ASP.Net application opening an Outlook session directly. This will not scale effectively for many (concurrent) users. Outlook is already the worst resource hog in Microsoft history; instantiating hundreds of Outlook objects will kill your web server.Save the tasks to a table, or a text file, and write an executeable version of your code to read this data and actually create the task items. That way it can run periodically and independently of the web, database, etc. and not become a resource drag on them. It will be a lot more efficient to have the program handle many tasks in one batch than to have it do the same number one at a time, starting a new app each time. You can set it up as a scheduled task through Windows or even SQL Agent. You don't even need to write this executeable in .Net, it may be better not to. |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2004-10-17 : 13:39:19
|
| Another variation to Rob's suggestion might be to send the request to MSMQ, easy to do in ASP.NET, and build a "listener" windows service which picks up the message and processes the task creation request. |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-17 : 14:50:35
|
quote:
Originally posted by ehorn
Another variation to Rob's suggestion might be to send the request to MSMQ, easy to do in ASP.NET, and build a "listener" windows service which picks up the message and processes the task creation request.
None of the above suggestions is gonna cut it...Outlook tasks, if you use them, has a pretty lengthy process. The originator (creator) of the task is the OWNER of the task. When a task is sent to a responsible person (the task to be worked on) he or she can accept or decline. If the task is accepted the originator still maintains a copy of the original task. That way when updates are made to the outlook task by the responsible person those updates get propogated back to the originator. Email notifications and updates are also sent back and forth directly from within outlook without additional code. THis is a rather large and complex object model that does a great job of keeping tasks upto date and inline.Rob, your method would destroy all of this steamlining and disconnect virtually everything I just spoke of. Besides if the end user is creating the task and it gets stored on their outlook tasks than how will your method handle this? I cannot have one email account just storing everyone's tasks. We need to have all the features involved such as auto updates, delegations, notifications of acceptance, completion etc.Ehorn,Your suggestion would destroy this process as well. The "listener" cannot and will not know who the originator of the task was. In fact all of the notifications, etc. would be broken in your case.Both solutions would not work in this type of scenerio. Anyone else have suggestions on how to send outlook tasks from asp.net ?Thanks, |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-10-17 : 15:23:35
|
| It's very hard to suggest anything when there are few details about what the ASP.Net app is doing and what the Outlook code is supposed to do. My last suggestion is: either don't bother trying to get ASP.Net to do the work, or make this an Outlook app and not an ASP.Net app. If you want to take full advantage of Outlook then you need to base it upon Outlook, period. Every app I've ever connected to Outlook only did the basics; anything more involved was instantiated from within Outlook. In that regard, it's much easier to include a web page into Outlook than to try to get something else to control it. |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-17 : 19:53:17
|
| Rob,To be quite honest with you...this is the basics.My previous application was in visual basic with an access database. Because our company has grown to various sites and other divisions we wanted to rewrite this same application (which ran very well even with the outlook tasks) to a web based application connected to a sql server database. So why am I going to lose functionality cause I'm moving to something bigger and better ???? Makes no sense, and management WANTS this functionality. I've already had a discussion with some of the management and we do not want to lose the outlook functionality, that is the whole purpose with the application.In regards to giving more information, let me explain what the application is. The application is a global Issues Management System.Its really simple its basically two relationships:One Side (Issues) to Many Side (Action Items aka Tasks). Rob when an Issue is created an action item is associated with it. Let me give you an example:Issue: Rotater is not rotating part correctly.This issue may have many action items associated with it. When an action item is created it automatically pulls a responsible person who will be assigned this action item (he / she is responsible for working on the action item in hopes to resolve this issue.)This action item might be:Action Item 1: Redesign engineering componentAssigned To: jon doeAction item 2: Update documentationAssigned to: Jane DoeSo what happens here is when an action is created we used to send an outlook task, in this case to jon doe for action item 1. What happens now is the original person has this task stored in his / her outlook (this is how outlook works, it keeps track of the task, when its completed, percentage, etc). The task is sent to the responsible person so he / she now has a copy of it in their outlook tasks. When the responsible person updates dates, or updates percent of complete, an automatic email and update is sent to the original person who sent the task (again this is ALL outlook). In fact this responsible person NEED NOT open up the asp page. He / she can simply use outlook and NO MORE. He / she updates or marks the task complete and this updates the original task.The point is...in a company like ours, our end users LIVE in outlook, and we'd like to keep it that way. We still need the data in the db to report on and for historical reasons. But saying "just drop that functionality" is absolutely a no no in this project. I had suggested we just use email but that got shot down with VERY GOOD reasons that I will defiantely not argue about. For instance, email can be easily tossed. Email doesnt have accept / decline. Email cant be tracked, email cant be delegated, email cant be auto updated, etc etc....This functionality has to be in the tool, this is not a decision that I made, but I definately agree with it. In the previous application it was perfect, fast, solid, and everyone loved it. I cant tell everyone no more tasks...this would require everyone to actually log onto a web page just to mark a task complete. In other words we dont want to have to maintain both.I have written an outlook dll to update the item in the database that isnt the problem. My problem is sending outlook tasks from asp.net. I thought I had it earlier today (yes im working) but everytime I try to send it or write to it..the page just sits there...no errors or nothing.I cannot for the life of me believe that this is not possible. I know it is, I've seen commercial applications that integrate outlook tasks. So people in the forums saying its not possible I dont believe.I have to get this thing with outlook tasks. Period.Jon |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2004-10-17 : 20:27:28
|
| Are your users connected to Exchange ? Or using Outlook standalone ?If they are using exchange, it's much easier because the web server can interact with the mail server, rather than the web server trying to integrate with a client side app.I haven't done much Exchange programming, but the I will give you the general gist of it, and some keywords so you can go look up the documentation.There is a COM object called CDONTS (Collaboration Data Objects for NT Server) which will let you talk to Exchange and create emails and tasks etc. I'm not sure if it is installed if you don't have exchange, you will have to go find that out, it's filename is cdosys.dll (I think, might need to double check that).Then, if you add a reference in your ASP.NET project to that dll, you should be able to program against it reasonably easy, COM interop is the name for the dll that is generated automatically to allow your .NET code to interoperate with the COM dll.As for the CDO syntax, that you will have to look up, but this looks like a good start :http://www.google.com/search?hl=en&c2coff=1&safe=off&q=cdo+create+exchange+task&spell=1Hope that helpsDamian |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-10-17 : 21:26:26
|
| I did not say to drop the functionality. You completely missed the point of my last post. I'm saying to DROP the ASP.Net part, or subsume it into Outlook. You said that your users live in Outlook. GOOD. Keep them there. Take the ASP.Net and pitch it, or rewrite it as a module or form or whatever it needs to be and put it into Outlook directly. This is exactly what I said before. Whenever I needed heavy Outlook integration I wrote the code IN OUTLOOK and kept it there.It sounds more and more like you don't even need .Net or this web page. You say you don't want to maintain both. Then don't. Everything you can do in .Net to update data in a database can be done with plain old ADO and stored procedures called directly from Outlook. I've done that a hundred times, it's even easier than doing it in Access.BTW, whenever you see people write web-based Outlook apps, they've either using the Outlook ActiveX embedded in IE, or they're doing something with CDO and some fancy COM programming on the back end to make it look pretty. Either way they're programming Outlook, and there's no .Net involved or needed. |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2004-10-17 : 21:33:12
|
quote:
Ehorn,Your suggestion would destroy this process as well. The "listener" cannot and will not know who the originator of the task was. In fact all of the notifications, etc. would be broken in your case.
I think you are misunderstanding my suggestion...The "listener" windows service would be vb code (ie. COM exposing Outlook). used to create an Outlook task - Once the task has been created in outlook, it is maintained in outlook. The task creator submits his task information (via ASP.NET) to the message queue. The listener service then picks up the variables sent by the asp.net app (ie. Recipients, Subject, Body, etc...) from the MSMQ message and processes the request (Like you mentioned in your v/access version) to create an outlook task. MSMQ is just acting as a message broker between .NET and COM.Also, if you are still receiving DCOM access denial messages in the event log have a look at the following article:http://support.microsoft.com/default.aspx?scid=kb;en-us;290398If you cannot get the permissions configured consider this as an Alternate approach:xp_cmdshell calling vbscripthttp://www.experts-exchange.com/Operating_Systems/WinNT/Q_20536241.html |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-18 : 09:31:55
|
| Rob,To be honest, I cannot drop the application...the reporting, and the advanced functionality is just not supported in Outlook. Plus I have to pull data into SAP and we certainly dont want to lose this...Rob I know you're a smart guy, and I respect that, but I honestly cant take that advice (And although it is good) i just cant take it right now, its just not an option.Ehorn, you're ringing bells now...I wonder if I could do this with vbscript....vbscript is client side...but how would i pull that data right to the vbscript? And then call it with xp_cmdshell...Damian, yes we do use Exchange... |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-18 : 11:36:57
|
Ok update,Looks like exchange is not the option to look into. I received an email from someone at MS:The only supported way to work with Outlook tasks is through the Outlook Object Model (OOM). None of the Exchange APIs support programmatic access to Outlook Tasks.In current versions of Outlook they are standard COM objects, and would be used using COM Interop. I don't know whether Microsoft publishes a Primary Interop Assembly (PIA). The Microsoft Office Developer Center can give you more information on working with .NET:http://msdn.microsoft.com/office/understanding/outlook/You can also find more detailed information about the OOM at:http://msdn.microsoft.com/office/understanding/outlook/devdocs/default.aspxHowever, I didn't find much useful at the "Outlook 2003 VBA Language Reference" page, so the download is possibly your better bet. Here's the direct link to the download:http://www.microsoft.com/downloads/details.aspx?FamilyId=A1CEAD80-23E2-456F-8618-4DA50CC2C38C&displaylang=enRegards,Thom RandolphLead Programmer WriterExchange Content EngineeringWindows Server Systems User ExperienceMicrosoft Corp. Ehorn, I think vbscript MIGHT just do it....I will have to figure out how to send the actual data and see if it runs ... Thanks guys |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-18 : 13:33:36
|
| I have that example batch file..from a dos prompt i can typetask.bat and it works fine it creates the task.But if I do xp_cmdshell 'c:\task.bat'I get 'task.bat' is not recognized as an internal or external command,operable program or batch file.NULLI even tried task.batc:\tasketc etc...But it keeps giving me that it is not a valid bat...but at the dos prompt if i type in taskit works right away ....Anyone ? |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-10-18 : 16:53:47
|
| xp_cmdshell runs from the database server and not your client machine. So task.bak must exist on the C drive of your database server.Tara |
|
|
|
jhermiz
3564 Posts |
Posted - 2004-10-18 : 17:28:38
|
| errr then thats another problem i will encounter...I need to run this on the client side somehow...good lord this is difficult :(Why didn't I phd in landscaping or something. The reason why I need this to run locallyis that the task must be coming from a person and not the actual server account...Ehorn this kills your idea :( |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2004-10-18 : 17:55:22
|
| How about an ActiveX Control that does this?Active X Control can be done in a COM language, so you may be able to port what you used to have into a control and it would be fairly easy to deal with.Just a thought...BTW vacation was a blast :)Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
Next Page
|
Outlook Task