We have a .NET Winforms application that hosts the Crystal Reports Viewer control (Version XI). It works well for the most part but when an export of data from the viewer is performed the application will crash on exit and in unmanaged code. The error message is not very useful and just says that an incorrect memory location was accessed. No other info such a specific DLL etc. is provided.
This only happens after the viewer is used to export a report to CSV, XML etc. My guess is that at some point in the export process Crystal creates a resource that attempts an action on shut down to a parent window (perhaps) that no longer exists.
I've seen a number of memory leak and shut down issues with Crystal but this one's new. Has anyone seen it and come up with a workaround or has ideas for workarounds?
So far we've tried explicitly disposing of all crystal-related objects, setting to null and even setting a Thread.Sleep cycle on shut down to "give Crystal time to clean up."
Update:
The crash happens only on shut down (so not immediate)
All export formats work
All export files are created properly
CR is installed on the same machine as the hosting .NET app
not sure about exporting from the IDE... is that even possible?
Check your code to ensure that you only open the Crystal Application object once during the lifecycle of your application. This will prevent excessive memory usage, usage that may be causing your crashes. Obviously, you can open and close reports at will.
Related
I am writing a Crystal Report Viewer in Visual Studios using ClickOnce to deploy updates and install on users computers. I am using Visual Studios C# and have the application checking for updates before loading the program to ensure all users have the latest version when needed.
One thing that I did not think about and just ran into is the number of reports attempting to load at once on a machine. Some users have 10+ reports starting simultaneously when they log into our ERP. I made a batch file to start all the reports they needed but I ran into an error:
Too many deployed activations are attempting to load at once
I tried searching for an answer as to how many ClickOnce instances are allowed to load at once and I could not find the answer. It seems to be around is 8 (based on my testing) and apparently it is in place to prevent DOS attacks against the ClickOnce server. I tried waiting a few seconds in the batch file after every 5 reports or so but this is not a long term solution.
Is there a way to increase this limit or should I just open all the reports needed in a single instance from a command? Even if I go with the second option, users can still add reports to automatically open in the ERP causing this issue to arise again. So is there a way to detect how many ClickOnce instances are currently loading and wait for them to finish, allowing me to bypass this issue entirely?
The solution I came up with for this was to expand the command to include multiple reports so all the reports will open under the same program. That way, ClickOnce is only involved once per batch file. Each report runs in its own thread so it behaves the same as running each report as a new instance of the program.
Theoretically a user could add enough batch files to our ERPs auto launch feature to overload the system and receive the same error as before but we could just add that to the batch file once we find out.
Until I find out if there's any way around this limit, this is the best I can come up with since it seems to be happening before the program even hits main().
I have faced a big and inconvenient problem with Excel spreadsheets that have internal data connections (queries that selects ranges of the own workbook) in them.
I wiil start by showing the problem e exposing how to reproduce it.
Problem: if I have some internal connetion and another instance (pay attention, instance, not other workbook) was already open, when refreshing that connection, the same workbook (which have the internal connection) is instantly opened in readonly mode in another window...
Why this occurs? The problem is that I'm developing a .NET automation application for Excel and this behavior breaks some process flow (because the readonly file stays open and sometimes it causes a non refresh in the original workbook)
To solve this problem I began to use the same instance if it is already open, but this is not the best solution because I need to handle the concurrency when running several VBA macros in the same instance via .NET Interop.
Here a workbook for those who wish to test this issue that I presented (just change the string connection inserting the new file path in your computer):
Excel File for Test
I recorded a video to show you the issue with more details and how to reproduce it. Please, take a look:
Video
I hope someone knows how to solve this problem because I've been searching for this several days...
Thanks
Obs.: The Office version is 2013
Whenever the program reaches the below code, the program hangs
protected void InitCrystalReport(String _reportUrl)
{
myReportDocument.Load(_reportUrl);
}
This situation only happens when I put the web on IIS (another server), but it doesn't exist when I run the application on Visual studio (Debug mode). I've also used process monitor to monitor the process to see if the file is access denied.
I've tried below on Web Server but none of them works:
Changing application pool to .NET Classic
Restart the printer spooler
Edit
I restarted the server and everything's OK now
I had this problem when i moved a new report to the test server. My fix was to set a specific printer through File.. Print.. to one i knew was on the server (in this case MS XPS Document Writer). Ensure you've used .dispose etc on the object when you're done.
Although this is old question already answered, I also encountered same problem and after wasting one whole day, I got suggestion from #PhilKemreen answer. Here is how I fixed it in my case:
Open report in Crystal Report Designer and Right Click
Select Design > Page Setup..., Page Setup Dialog box appears.
From the printer drop-down list, select Microsoft XPS Document Writer.
Click OK.
Then I deployed the new report file on server, it works.
I have written a C# program which import a product list from a .xlsx file and let the user create an order based on that product list.
When the user is finished, the program builds one or more system specifications based on the order.These specifications is written to a .docx file. I have Office 2007 installed on the computer and are using the Microsoft.Office.Interop.Excel and the Microsoft.Office.Interop.Word namespaces.
The problem:
After I have runned the program, Windows Explorer crashes very often and has to restart. This happens when navigating in folders or when right- clicking on folders etc.
This also happens after the program have been closed and the only solution to make it stop is to restart the computer. It seems like it only happens when I have created the output files (.docx). If i start the program and use it like I normally do, but without creating the word files, the problem don't seem to occur.
After the program have created the output files, Word gets "Visible" to the user for manual editing. The user closes the word application when finished editing the documents.
What can make the Windows Explorer crash when running word automation?
I really need help on this one. Any suggestions are welcome.
After execution, do you have ghost excel.exe and word.exe processes remaining?
These ghost are likely to make the system unstable.
You're likely not releasing properly the COM objects you instantiated via automation.
Use Marshal.ReleaseComObject(yourobj); on each and every COM objects you instantiate. It's a real pain, I know.
Note: be sure that you don't instantiate COM objects without knowing it:
mySheet = myExcelObject.workbooks[0].Sheet[0] won't just instantiate a sheet object, but also a workbook object.
Rule of thumb: never ever use a secondary property on a COM object ( foo.bar.baz ) and release everything.
Final note: don't use office automation at all on the server, it's bad, per Microsoft own words, there are fully managed libraries for that.
I am currently hosting an IE Browser control in a .NET (2.0) Form and using it to load Office files such as Excel and Word thusly:
_ieCtrl.Navigate("C:\\test.xls", False);
The hosting and loading works well except whenever I navigate to a file I am presented with a dialog that asks whether I want to save or open the file. (This is standard IE file-download behavior.) I always want to open it of course and I do not want the dialog to show.
Another issue is that when I close the window that hosts the IE control and the Office doc the document does not close and remains open on disk. This means that subsequent attempts to open the same file via my app or the native office app will fail because of the sharing violation.
Is there a programmatic way of avoiding this dialog and cleaning up resources afterward? I am asking for a programmatic answer because web research has only yielded solutions that entail modifying OS-level settings.
Bounty NOTE:
I am open to any solution to this issue that will allow me to:
Host an Excel spreadsheet inside my application
Work rather transparently (avoid usability issues like the one described above)
Avoid having to make any OS-specific changes that may affect other applications (especially icluding IE)
Is zero additional cost (no licensed 3rd party libs please) Code Project and other open source resources are OK
Not mess around with the DSO Framer ActiveX control, unless a stable version is developed/discovered
Is your intention for the user to be able to work with the Excel file in an Excel-ish way (i.e. columns, rows, formulas, etc.), possibly saving it back? If this is the case, I can't see how you can solve this problem well without relying on COM Interop with the Excel object model or by integrating third-party libraries to work with the Excel sheet. I know you said no paid solutions, but there are some feature-rich 3rd-party controls out there just for working with Excel files within applications.
I noticed in your comment to SLaks that the final product is a "dashboard of sorts". If your intention is to design a a custom dashboard application, have you considered parsing the Excel file(s) to extract the data and then presenting it in a logical manner within your application. This removes the need to directly display and work with the Excel file while still allowing you to work with the data inside that file. If you are trying to get the data outside of the file, here are two approaches among many:
You might consider using the Excel object model and COM interop to read the data from the Excel file into your application. Granted, this includes a dependency on Excel being installed, but it is a possibility. This article has some great code for getting started with reading Excel files in this way.
A better way might be to use a library that doesn't have a dependency on Excel being installed on the local system. This answer suggests using the Excel Data Reader library, available on CodePlex.
I know this answer side-steps your original answer of "hosting MS Office documents in [a] custom app," but in case what you're really interested in is the data inside those Excel files, hopefully this answer will prove helpful.
This is a horrible hack and should only be considered as a last resort: SendKeys.Send("{O}");
http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys%28VS.71%29.aspx
Something similar to
_ieCtrl.Navigate("C:\\test.xls", False);
(code to sleep or wait may be needed here)
SendKeys.Send("{O}");
Basically, you send the "o" key to the dialog so it presses the "open" option. You are simulating a keyboard presses to click the "open" button. It is hackey because
1) you may need to wait in between
calls. If you send the o key before
the dialog is up it will be missed.
Hopefully the navigate call is finished when the dialog pops (dont know behavior of control in c#). You may need to experiment with the time since different computers will open faster\slower
2) If the dialog is not shown on a
computer, you will be inserting "o"s
into it. This may cause problems when
exiting because it may popup another dialog to try and save
the changes. May be able to prevent this by opening it in read-only mode
3) Different versions or windows may need different sendkeys commands. For example, you may need to send "o" and them the "{enter}" key
4) Probably more :)
If you want to open the file in a separate Excel instance (not embedded in the WebBrowser control), you can simply call
Process.Start(#"C:\Test.xls");
Office was never meant to run in embedded mode, not in a web page or in an ActiveX Document host. Microsoft had time and time again given us the warning. From pulling dsoframer from the knowledge base to skipping the BrowserFlags registry key in Office 2007.
Move to Office add-ins, Excel Web Access or Office Web Apps as quickly as you can.