Free Support Forum -

Windows Temp Folder Filling Up

We have noticed that when we use the PDF concatenate functionality there are temporary files left in the Windowx/Temp folder. Although the file sizes are 0 bytes windows has a limit of 65565 files allowed in this folder and when it hits this limit aspose can no longer write any no files to this so falls over. Can you tell me if this is a bug in aspose with these files being left over or is there a way to clean them up when we have finished concatenating a pdf?

Any help would be appreciated.


Hi Graeme,

Thanks for using our products.

I have tested the scenario using Aspose.Pdf for .NET while using Document as well as PdfFileEditor class to concatenate the PDF files and I am unable to notice any Temporary files under C:\Windows\Temp location (In system variables, C:\Windows\Temp is set as path for Temp variable). I have tested the scenario over Windows 7 X64 Enterprise and VisualStudio 2010 Professional.

Can you please share some details regarding your working environment, we are sorry for this inconvenience.

Thanks for the quick reply. After testing it is happening on a number of different windows environments and also different versions of Aspose. It is the concatenate function that is falling over when the limit is met in the folder which says to me that the concatenate method is trying to write a file into the temp directory. Is there anything we could be doing that could cause the file to be left over, i.e. not closing a memory stream or something like that?

Kind Regards
Can you also get one of your developers to check your concatenate method for a call to GetTempFileName() as this is the windows api method for creating the temporary file (info about this in link below). After careful debugging of the code we can see that the windows api creates a temp file when it hits the concatenate method and further seems to do nothing with it and does not clean it up.

Can i also add that from searching i have found quite a lot of other users that have posted on here with the same issue but have had the response that you cannot recreate the issue.

Kind Regards

It is important to note that we only get these empty temporary files left behind when the code is running in an ASP.NET application running under IIS (we use both IIS 7 on Windows Server 2008 and IIS 7.5 on Windows 7 and Windows Server 2008 R2).

We do not have this problem when the same code is running in a unit test, a console application, or if you are using Visual Studio Web Development Server or IIS Express. Please find our code below which replicates the issue.

private MemoryStream CreatePdfStream(string content)
var pdf = new Aspose.Pdf.Pdf();
var section = pdf.Sections.Add();
section.Paragraphs.Add(new Text(content));

var stream = new MemoryStream();
return stream;

var pdf1 = CreatePdfStream(“first”);
var pdf2 = CreatePdfStream(“second”);

using (var result = new MemoryStream())
var pdfEditor = new Aspose.Pdf.Kit.PdfFileEditor();

pdfEditor.Concatenate(pdf1, pdf2, result); // Empty temporary files created here and not deleted eg “tmp3E59.tmp” in “C:\Windows\Temp”

Hi Graeme,

Thanks for sharing the details.

I have again tested the scenario using Aspose.Pdf for .NET 7.4.0 over Windows 7 X64 Enterprise using ASP.NET web application created in Visual Studio 2010 professional where I have specified the target platform of my application as .NET Framework 4.0 and I am unable to notice any temporary files in C:\Windows\Temp and even in C:\Users\Nayyer\AppData\Local\Temp folder. I have also observed that the code snippet which you have shared is based on legacy version of Aspose.Pdf for .NET and Aspose.Pdf.Kit for .NET. Can you please try using the latest release version and see if you are still able to notice the Temporary files issue.

Please note that until or unless we are able to replicate this issue at our end, we might not be able to debug and fix this issue. We are really sorry for this inconvenience.

Can you confirm you are using IIS and not the Web Development platform to test this scenario (the default when you create a new project is the web development server).

We have further tracked this down to the licence key. If we set the licence key at startup then the temporary file is left behind. If we dont use a licence key we get a watermark but the temporary file is removed.

Can you please let me know if you can now recreate this?

Hi Graeme,

I tested the scenario while executing the code from VisualStudio. Anyways, I am working on replicating this issue and will keep you posted with my findings.

Is there any update on this at all?

Hi Graeme,

I have tested the scenario over Windows 7 where I have used IIS7 and I could not reproduce this problem. Nevertheless, I am testing this scenario over other machine and will update you shortly. We are sorry for this delay and inconvenience.

Have you tried it with and without the licence file?

Hi Graeme,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

We further checked your issue with and without license on different machines and still we are unable to reproduce the problem.

Also, you are using some old version of Aspose.Pdf for .NET and Aspose.Pdf.Kit for .NET. I would suggest you to download and try the latest merged version of Aspose.Pdf for .NET v7.5 (with all features of Aspose.Pdf.Kit for .NET merged under Aspose.Pdf.Facades namespace) and try it. Please check the following links to update you code.

Migration from earlier versions of Aspose.Pdf for .NET

If you still face any issue, please send us your sample application to reproduce the issue. This will help us in narrowing down the cause.

Sorry for the inconvenience,

Hi Graeme,

I have again tested the scenario using Aspose.Pdf for .NET 7.5.0 over Windows 7 X64 Enterprise where I have used IIS7 to host the web application developed in VisualStudio 2010 Premium with target platform of application set to .NET Framework 4.0 and I am unable to notice temporary files in Licensed as well as un-licensed mode. For your reference, I have also attached the sample application which I have used. Can you please try executing it at your end and see if you can reproduce the issue using this application.

We are really sorry for this inconvenience.