Reputation: 1286
I am using C# to create a spreadsheet, here is the code:
try
{
_excel = new Excel.Application();
_excel.Visible = false;
_workbook = _excel.Workbooks.Add( Type.Missing );
_worksheet = (Excel.Worksheet)_workbook.Sheets[1];
createColumnHeaders();
_workbook.SaveCopyAs( savePath );
}
catch (Exception ex)
{
Logger.Error( "Error creating spreadsheet: {0}", ex.Message );
}
finally
{
// Cleanup
}
This runs nicely, saves the sheet into the savePath. However, if I change SaveCopyAs() to
SaveAs( savePath,
Excel.XlFileFormat.xlWorkbookNormal,
Type.Missing,
Type.Missing,
false,
false,
XlSaveAsAccessMode.xlNoChange,
Type.Missing,
Type.Missing,
Type.Missing,
Type.Missing,
Type.Missing );
then the application gets a COMException saying
'C:\//temp/00-04.20.18-24-07-2014/' cannot be accessed. The file may be corrupted,
located on a server that is not responding, or read-only.
This is a pain since I really need to be saving in .xls format, not .xlsx. Any ideas why this exception occurs for SaveAs()?
Upvotes: 1
Views: 469
Reputation: 941465
It's kinda obvious what went wrong here. That's not a valid path of course, //
should only ever appear as the lead characters for a path to name the machine that contains the file system.
You'll have to de-tune the "Windows works like Unix" expectation when you work with Microsoft application software. Forward slashes in a path are not a problem when you make direct operating system calls. Windows supports them well, not in the least because Windows NT once supported Posix out of the box. The same is not true for other apps, particularly the kind whose source-code base is 25 years old. But is not limited to just old code, VS has problems too. Microsoft treats these kind of bugs reports a bit like Jeff Atwood treats pluralization bugs.
The proper path separator character without any surprises is a backslash.
Upvotes: 2