How to add email attachments to an outgoing email

You cannot attach a file in that Send Email component by path. Here's what you need to do:

1. Add a "Read File" component immediately before the Send Email component
2. Set it to use "Full path" and configure that setting with the directory path to your PDF
3. Configure the rest of the Read File component
4. Back in your email component, set the file attachment to use "Process Variable" and then choose the output variable from the Read File component.

This is the closest guide to "component-by-component" doc in existence right now, but it won't help you too much on this one. New component doc initiative in the works right now.... 

Thanks for the help. I found the component you recommended.  For the benefit of other readers, it lives under Process Components  ->   Input Output  ->   Files  ->   Read File

The top configuration radio button is URL, and I store the path that way, so I tried it.
The Input variable to the Read File component contains a variable reference to the string containing
http://App1/Shared/Prospects/1164/documents/1164-Sitereport-2009-05-03.pdf

The Output variable of the Read File component is the local variable f_SiteReportPDF_ReadFile, which I have configured my Email contents to attach.  I get the following error:

The URL is correct because I can bring it into a link and browse to it within an executing workflow.

Why can a LogicBase.Components.FormBuilder.LinkComponent deal with this URL, and yet a LogicBase.Components.Default.IO.ReadFile with File Path Type set to URL cannot?  Puzzling.

On to the Full Path option which you suggested.

Unfortunaltely my project deploys on http://MARS/Solarflow, a different server than the APP1 server where the document lives.

On MARS, the App1 doc is at P:\Prospects\1164\documents\1164-SiteReport-2009-05-03.pdf,  where  P: is mapped to \\192.168.10.6\C$, with only C:\PROJECTS shared on C$, not the root.

 I used LogicBase.Components.Default.Process.ReplaceStringInText to transform the html path by replacing http://App1/Shared/ with P:/PROJECTS/ and workflow magically reverses all the forward slashes into backslashes for me, and then gives the new error...

Though the path is correct, the workflow may not have permission to navigate through the share.  Or, it may be that it only wants a path here, and not the document name on the end of the path, but I did check the box to say the path included the filename, so that may be a bug.  

In addition to URL and Full Path, another radio button offers selection of path relative to the deployment folder, but to get to P:/PROJECTS/ I would need to replace http://App1/Shared/ with ../../../../../../../P:/PROJECTS, which I tried...

Though perhaps it wants ..\..\..\..\..\..\..\P:\PROJECTS\ so it can translate the slashes for me?

Same error

Well perhaps I'm short one pair of dots?

Same error

Or perhaps I'm short a pair of dots back on the other path format?

Same error.

Do you have any suggestion on how to get around this path problem for a remote file? 
Could I possibly embed credentials in the path?

Thanks

 I believe the only way to do this is to have a seperate Application Pool in IIS and use a named domain account. The user would have to have rights to the path you are trying to access. Right now, all you published apps are running under the local NETWORK account. Once you create the new APP pool and make your project use that, you'll have access to the remote file.

Rob

Hi Rob

Can you give me any more details on this solution?

In IIS Manager, the DefaultAppPool default properties -> Identity is currently set to the predefined Network Service, but could be set to Configurable, and a domain user name and password could be selected.

Do you see any downside to just empowering DefaultAppPool rather than creating a separate AppPool?  Perhaps this is a security risk.  If I were to create a separate AppPool, would I need to move all applications currently in the Default pool over to the new pool?

Phil

Just a quick update...

As an experiment, I changed the Identity of the default application pool from Network Service to a domain user with file permissions to the mounted drive, and could no longer publish the workflow.  A "No Service" message appears as the publication process is attempting to launch the WebForms workflow.

If I create a new pool as you suggest, how would I go about moving just this workflow into the new pool, and then how would I avoid the No Service error when attempting to publish our use the workflow?

In a related experiment, I tried moving the files I'm attempting to attach onto a drive local to the workflow server, in the C:\Program Files path, and then I used the radio button on the Read File component to choose a relative path to the published directory of the workflow.

Now with the path correct, the SMTP send email component errors out with an invalid address messge, as if it cannot access the local path any more than the remote path I was trying earlier.  I guess the next step is to learn all about application pools, and moving applications among pools.

To change the APP pool, you first have to define the user in the identity. I use a Domain user with no special rights, just a a regular domain user.
You can create a new pool by right clicking on the APP POOLS  in INETMGR and selecting New Application Pool. Just accept the defaults, then change the Identity user. To assign your worklfow to the app pool, just right click on the website virtual entry and select properties. On the virtual directory tab, you'll see Application Pool at the bottom - just change that to your new pool.

You also need to add the named user to the IIS_WPG group on your workflow server.

Next, you have to register the SPN for the user to the server to allow Kerberos Authentication. Here is a link to how to do that. You'll have to do this on a Domain Controller.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;871179

As to the dangers, it boils down to security. If someone were to compromise your Workflow server and somehow manage to hijack your IIS App Pool, they would have access to the same resources the named user has. If you use a user with elevated privileges (like an admin user), this could be a huge problem. By limiting the rights of the named user, you can minimize this risk.

In my case, I need to run certain apps under a named account as I need to interact with a Microsoft Certificate server, and it requires a named account to do so, it simply would not work under the Network acct.

Rob