Here's an example of reports from a VFP mtdll:

*code in vfp mtdll
CASE oProp.Action=='pdf'
 LOCAL lcFileID,lcFile,lcNewPath
 lcFileID=SUBSTR(SYS(2015),3,10)+[.pdf]  && give PDF a temp file name
 lcFile=SUBSTR(oProp.AppStartPath,1,ATC([AVFPdemo2],oProp.AppStartPath)+8);
		+[r\pdffiles\]+lcFileID  && full path
 oPDF=CREATEOBJECT("PDFrun.AVFPpdf") && this is the VFP .EXE COM Server
 oPDF.start(lcFile,NVL(oRequest.Form("Company"),""))
 lcNewPath=SUBSTR(oProp.ScriptPath,1,ATC([AVFPdemo2],oProp.ScriptPath)+8);
		+[r/pdffiles/]+lcFileID  && URL for created file
 oResponse.Redirect(lcNewPath)  && redirect browser to created file

And here is the AVFPpdf class that actually runs the report form the web:

DEFINE CLASS AVFPpdf AS CUSTOM OLEPUBLIC
FUNCTION start
LPARAMETERS lcFullPath,lcCompany
IF EMPTY(lcCompany)
 SELECT * from d:\dotcomsolution\data\avfpdemo2\customer INTO CURSOR tcursor
ELSE
 SELECT * from d:\dotcomsolution\data\avfpdemo2\customer;
	 WHERE UPPER(company)=ALLTRIM(UPPER(lcCompany)) INTO CURSOR tcursor
ENDIF
set procedure to print2pdf.prg
do print2pdf with lcFullPath, "d:\dotcomsolution\avfpdemo2\reports\listcust.frx"
ENDFUNC
ENDDEF

>At some point I needed solution using COM+ but I could not do that because I had to use EXE.
>Also multiuse EXE servers are not good. So with a havy load you will have a bunch of exes loaded into a memory.
>I think DLL solution is more elegant.
>
>Mark
>
>>Mark,
>>
>>What's so wrong with building it as an EXE instead? It works great and lasts a long time.
>>
>>>What is a bottom line - can we print a report from a DLL?