For a project at work, my program should open a newly added excel file every day and export data to database. I have code written that should theoretically do that, but turns out the guy who wrote the program for those excel files to go onto the sharepoint site has them named as XLS but has them formatted as XML type. Without having to go into his program to fix that (even if that is easier), what is a quick way to convert types? Or would using an XML reader just be faster?
XML is OK, and easier to work with than xls. You can use xslt, linq to xml.. If your program is using Office Interop, just specify the file is in Office 2003 XML format.
I have encrypted my ASP File. But when i run it in browser it fails. How to execute that asp file so that my application could run ?
how to decrypt it, it is encrypted using a tool , how do I decrypt it while execution ? I don't want that anybody whom I give that file , sees the code of the file , but could only execute it and use it.
Ah, I think I understand:
ASPEncrypt is a component you can use to encrypt files using ASP or ASP.NET. It is NOT a tool to encrypt your ASP(.NET) source code files with.
You're looking for something like Microsoft script encoder (I don't know if it's still available), you want your sourcecode to be unreadable right?
There are tools that claim to do this, but there isn't one I know of that can't be reversed. So it's only a small obstacle if someone really wants to get their hands on your code.
Here are some more tools that claim to do this.
I hope one of them suits your needs.
I have a client who has set-up a testing environment in some AI language. It basically runs some predefined test cases and stores the results in as log files (comma separated txt files). My job is to identify and suggest a reporting system and I have these options in mind. either
1. Importing the logs into MSSQL and use the reporting(SSRS) it uses
2. or us import the logs to MySQL and use PHP to develop custom reporting.
I am thinking that going with option2 is better. The reason for this is, the logs are inconsistent and contain unexpected wild characters that normally DB's don't accept. So, I can write some scripts in php before loading them to the database.
Can anyone please suggest if this is your problem what will you suggest to do?
It depends how fancy you need to be. If the data is in CSV files, you could even go so simple as to load it into Excel (or their favorite spreadsheet tool), and use spreadsheet macros to analyze it.
I have a .ddb file that is used as a telephone directory for an application written in flash/VB.net (i guess). The problem is that the application is crashing and my only was to access the application is through the mysterious (*.ddb) file (99% of the application size.)
The application contains an also mysterious dll (NK_SQLite.dll).
So far I have tried:
SQLite Browser
tried opening the file in PL/SQL
tried opening the file in SQL Server
Any ideas about how to solve this issue,
Is it possible that the DDB extension is misleading? Have you tried opening it as a CAB or ZIP file? The NK_SQLLite.dll file certainly makes it sound like a SQLLite database but again it could be a red herring.
Another possibility... if any of the code is .NET, have you tried disassembling it? You might get some hints about what's going on that way, so long as it's not obfuscated. If you're unfamiliar with how to do that, I would recommend a tool like RedGate's Reflector (http://www.red-gate.com/products/reflector)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to properly clean up Excel interop objects in C#
Suppose a ASP.NET web application generates automated Excel Reports on the server. How do we kill a server-side Excel.EXE once the processing is over. I am raising this purposely, because I believe that the Garbage Collecter does not clean the Excel executable even after the Excel file is closed.
Any pointers would be helpful?
Sorry to say this, and I'm not trying to be smart, but... don't put office on the server!!!
That's if I've understood correctly! :)
EDIT: Even though I've been marked down for this, I will never ever advocate running Office on the server - it has proven way too much of a pain in the ass for me in the past.
Having said that, the same now goes for me and Crystal Reports ;-)
I agree with not running Office on a server. Not that I have any choice in the matter :)
One thing to keep in mind with the taskkill option, is that unless you specifically plan for it (aka - singleton), you may have multiple copies of Excel (or any other Office app) running, and unintentionally close the wrong instance.
Also note that per http://support.microsoft.com/kb/257757
Microsoft does not currently
recommend, and does not support,
Automation of Microsoft Office
applications from any unattended,
non-interactive client application or
component (including ASP, ASP.NET,
DCOM, and NT Services), because Office
may exhibit unstable behavior and/or
deadlock when Office is run in this
environment.
As an alternative, there is a product called Aspose Cells that offers a product that is designed to allow you to programmatically work with an Excel sheet in a server environment. As a disclaimer, I have never personally used this product, but I have heard about it from several people I worked with in the past.
I've had more time to think about this answer, and would now recommend using an XML approach with the Open XML Office spreadsheet format.
Heres some good links to get started on building a office document with code.
http://msdn.microsoft.com/en-us/magazine/cc163478.aspx
http://msdn.microsoft.com/en-us/library/bb735940(office.12).aspx
Just use SSIS on SQL Server. It provides the ability to export to Excel.
Don't run office on the server. Alteranatively waste money on aspose or spreadsheetgear.
GC does work your just not using it properly follow this pattern...
private void killExcel()
{
xlApp.Quit();
Marshal.ReleaseCOMObject(xlApp);
if(xlApp != null)
{
xlApp = null;
}
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
}
get your Excel operational class to implement IDisposable, and then stick killExcel() in the Dispose method.
UPDATE: Also note that sometimes dev will still see Excel.exe running in task manager. Before assuming the above code isn't working, check that the process that is running the code is also closed. In the case of a VSTO or COM addin, check that Word/powerpoint/other excel instance is also closed as there is still a GC root back to the launching process. Once that is closed the Excel.exe process will close.
Are you using VSTO? You can close the Excel app after you finished with excelobject.Quit(); It worked for me, but I don't use Excel on server-side anymore.
You can have a look on Excel's XML schema to build the Excel file without Excel itself. Check out CarlosAg Excel Writer, which does exactly the same.
I've had a similar problem. While 'taskkill excel.exe' or enumerating all "excel" processes and killing them does work, this kills ALL running Excel processes. You're better off killing only the instance you're currently working with.
Here's the code I used to accomplish that. It uses a PInvoke (see here) to get the ProcessID from the Excel.Application instance (Me.ExcelInstance in the example below).
Dim ExcelPID As Integer
GetWindowThreadProcessId(New IntPtr(Me.ExcelInstance.Hwnd), ExcelPID)
If ExcelPID > 0 Then
Dim ExcelProc As Process = Process.GetProcessById(ExcelPID)
If ExcelProc IsNot Nothing Then ExcelProc.Kill()
End If
Please not this might not work on all platforms because of the PInvoke... To date, this is the only method I have found to be reliable. I have also tried to find the correct PID by enumarating all Excel processes and comparing the Process.MainModule.BaseAddress to the Excel.Application.Hinstance.
'DO NOT USE THIS METHOD, for demonstration only
For Each p as Process in ExcelProcesses
Dim BaseAddr As Integer = p.MainModule.BaseAddress.ToInt32()
If BaseAddr = Me.ExcelInstance.Hinstance Then
p.Kill()
Exit For
End If
Next
This is not a reliable way to find the correct process, as the BaseAddress sometimes seems to be the same for several processes (resulting in killing the wrong PID).
The command you need is "taskkill".
http://technet.microsoft.com/en-us/library/bb491009.aspx
> taskkill excel.exe
:). I jotted down my skirmish with Excel here. It also has some links that I found after some heavy searching. Hope it helps.
Basically Excel is a pain even though it can be automated.
I also would not recommend using office apps on a server except for data access to mdb files.
I can definitely understand that there are times where it is necessary. In thoses cases
I would recommend the following:
Create a separate server where that is the only function. (Let's you reboot with minimum impact).
Have the server implement a mechanism of queuing requests
Keep a single thread processing the queue. This gives you the ability to keep track of the office app, kill it if necessary, and continue on without impacting any queued up jobs or other applications.
If you absolutely need to do it on the same server, then at least implement the above in it's own app pool.
Limiting yourself keeping a queue of work and only one instance of Excel (or any other office app) let's you kill it with abandon with TaskKill or .Kill() and not lose work.
I believe if you keep it to a single thread then you would rarely have a need to kill it.
I have used spreadsheetgear to generate XL reports on the server and it works really well. We don't have to worry about the EXCEL process..
I had a similar problem and used the following code:
System.Diagnostics.Process[] procs = System.Diagnostics.Process.GetProcesses();
for (int i = 0; i < procs.Length; i++)
{
if(procs[i].ProcessName == "EXCEL")
{
procs[i].Kill();
}
}
This worked pretty well, but I would really think about working with Office on a server.
I actually had a question that was similar to this awhile back - Check for hung Office process when using Office Automation - some of the responses to that question might be useful for you.
Also, I have to agree with what everyone else is saying in regards to keeping any Office products off of a server; however, since you are doing Excel, it might be feasible for you to generate Excel XML documents. You can do this without having to do any Office automation and the process is fairly straightforward. For simple grid based spreadsheets I have found it to be a bit easier than trying to automate it using Excel. The Office Open XML is quite powerful and allows for more complex reports are possible as well some more effort.
You need safely dispose all COM interop objects after you end your work. By "all" I mean absolutely all: collections property values and so on. I've created stack object and pushed objects during their setup:
Stack<object> comObjectsToRelease = new Stack<object>();
...
Log("Creating VBProject object.");
VBProject vbProject = workbook.VBProject;
comObjectsToRelease.Push(vbProject);
...
finally
{
if(excel != null)
{
Log("Quiting Excel.");
excel.Quit();
excel = null;
}
while (comObjectsToRelease.Count > 0)
{
Log("Releasing {0} COM object.", comObjectsToRelease.GetType().Name);
Marshal.FinalReleaseComObject(comObjectsToRelease.Pop());
}
Log("Invoking garbage collection.");
GC.Collect();
}
If Excel is still there you have to kill it manually.
The best approach is to use a purpose built library such as the one from Aspose to generate the spreadsheets or populate templates. The next best approach is to use the xml formats for office if practical for your needs. A lightweight approach that is sometimes suitable is to create an HTML file with one table in it and name it with an .xls extension. Excel will happily read that, but it is very limited in what it can do.
Those are the options I've used (but not much). There's also a thing called Microsoft Office Sharepoint Server, but I've no idea how much it really lets you do.
That said, your problem is happening because when you invoke the regular Excel libraries, you're actually spinning up Excel completely independently of .Net and actually just working with a proxy library to talk to it. This is pretty much the same kind of thing you'd have with WCF and a service. You wouldn't expect the service to die just because the client application was done using it. Worse, Excel is an unmanaged resource and will not be disposed/ finalized/ garbage collected at all. The .Net Runtime doesn't know about Excel, it just knows about those proxies. Application.quit is what you need and also you may need to explicitly release the com objects that are created.