I've some Crystal reports in a VS2010 application. They all work fine, but sometimes (happened at least twice), they will stay on the hourglass without ever loading. If I launch another instance of the application and generate the report (while the other instance still loads), it works fine. If the non-working instance generates another report, it works fine. If the form is closed and reopened, it works fine.
So what may go wrong? There should be a timeout if there's an issue accessing the datasource.
Is this a bug or a known issue? I haven't found any info on that.
Is there a way to catch this "error" so the user doesn't waste his time for half an hour and then call me?
Cheers
To catch problems like this you may need to add logging code to your app.
Make sure the Log function includes a time stamp, Pseudo code:
Log("pre-DB connect)
...DB connection
Log("post-DB connect)
Log("pre-Load Report...")
...load the report
Log("post-Load Report")
Once you narrow it down to a section of code, you can add more logging code to that section until hopefully, you zero in on the line that is hanging.
Related
When I try to update the dynamic module contents and click on publish it is showing a popup with message 'The type initializer for '' threw an exception' and I am not able to publish any content.
This is an inconsistent issue for me. It is weird that without doing any change at times this issues does not happen but it comebacks again. Can anyone please help me with this issue. Is this anything related to server update or server utilization because recently I added some more contents to the modules no other code changes or anything was done?
I found this link 'https://knowledgebase.progress.com/articles/Article/Uploading-images-error-Cannot-save-the-file-The-type-initializer-for-Module-threw-an-exception' but unfortunately, this did not solve my issue.
This happens with the Emulator as well as with the real device, in Debug-Mode as well as in Release-Mode.
In the app I store several application settings successfully - from simple value types to more complex objects and lists of objects.
With "WP POWER TOOLS" I can track the file "__ApplicationSettings" in the root of the IsolatedStorage. It is "well filled" - in the first lines I find some classes and assemblies, that define the complex type definitions, and below the XML starts with the <ArrayOfKeyValueOfstringanyType...>
So, everything looks normal to me so far.
When I close my app, the last piece of running code is the "Application_Closing"-Handler in App.xaml.cs. In this moment I can check the ApplicationSettings the last time - everything is okay.
For example: I check the count of the entries:
var count = System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings.Count;
...and the count is right and the keys/values are right.
Then - I restart the app at once (Visual-Studio-Debugging is not interrupted) and the first piece of running code is the ctor App() in App.xaml.cs.
In the first line I check the count of ApplicationSettings-Entries again, and: it is 0 !!!
But: WP POWER TOOLS still show me, that the "__ApplicationSettings"-File is existing and is still filled like before.
(The consequence of this error is afterwards, that with the first attempt to save any setting again, the whole __ApplicationSettings-File is overwritten and contains just the one new setting.)
So what could be preventing the App from "using" the existing "__ApplicationSettings"-File???
Thanks in advance!
(PS 1: I already experienced, that all ApplicationSettings are destroyed, when there happens an Exception while saving the settings. I investigated all of that already and are 99.9% sure, that there is no Exception anymore.)
(PS 2: Just to make it clear: It is NOT the case, that the complete IsolatedStorage is gone. I have also another file for logging purposes, that I write to the root of the IsolatedStorage. This file is always there. Also the __ApplicationSettings file is not "deleted", it just seems, that the app doesn´t "read" it when launching.)
I tried the repro scenario with an app of mine and confirmed what I expected, that IsolatedStorageSettings.ApplicationSettings.Count was nonzero on entry to the App() ctor upon running the app for a second time in the same emulator process. So there is hope for you to get to this desired state too!
Since you report that the _ApplicationSettings file is not empty, I'll guess 2 possibilities: Maybe an app (or some other process?) keeps the _ApplicationSettings file open when the 2nd run of the app is trying to open the file for reading? MSFT doesn't document how the read is done, so maybe the file is opened with FileShare.None, or with FileShare.Read but some other process still has the file open for writing? I have no idea how to test this on the emulator, but on the real device you might try this scenario:
Run the app for the first time, verify it saves a non-empty _ApplicationSettings.
Restart the phone device (debugger will disconnect)
Run the app for the second time, with a breakpoint in App() ctor.
After 2) I would be confident no other process could have the file open, so the app should be able to read its contents without interference. But if you discover that it still has zero count in 3), then another possibility exists:
Maybe the restarted app encounters an error trying to deserialize the settings from the file into your data structure(s)? The error might not prevent the data from being serialized when the first run of the app is exiting.
To check this possibility, first look for error messages in the Output, Debug window. Do you see any errors when restarting the app the a second time?
If you don't see any helpful error messages, the next thing to try is to simplify the data structures being saved as settings. Try cutting down to just one setting that is a simple type like an int or string. See whether that can be restored correctly, then add more of your settings back into the file until you home in on the one which causes a problem.
Do you call Save on settings? Does it throw any error?
I recently encountered a very weird problem with report viewer (Windows Forms). Normally the reportviewer behaves very well, loads fast and shows the reports nicely. But, we encountered a certain scenario in which it to takes ages to show the report. I cannot post the whole code as it is not clear what causes the problem.
The problem
The following method call causes the problem (again, only in a very specific scenario):
reportViewer.LocalReport.GetDefaultPageSettings()
It can take up to 10 minutes for the application get past this line and in fact, if this line is commented out then everything starts working perfectly.
The special scenario
The only difference in the special scenario that causes the problem is that right before showing the report some python code gets executed before the report is shown (via IronPython and in the same AppDomain, the python code does not reference anything even close to reporting).
Profiler, anyone?
Ok, so I run this scenario with a profiler (Xte) and noticed that the method IronPython.Runtime.PythonContext.LoadAssemblyFromFile is the one that freezes up. There is no explicit assembly-loads in python code we are running, so this is an automated assembly load.
The weird part
So, the weird part that I cannot get is how are those two things connected? I took a look at the GetDefaultPageSettings() in ILSpy and saw this:
public override ReportPageSettings GetDefaultPageSettings()
{
object syncObject;
Monitor.Enter(syncObject = this.m_syncObject);
ReportPageSettings pageProperties;
try
{
this.EnsureExecutionSession();
pageProperties = this.m_pageProperties;
}
finally
{
Monitor.Exit(syncObject);
}
return pageProperties;
}
And I can only guess that its the lock that is causing this method to hang, but I cannot understand how executing python affects this lock. I mean, it is absolutely clear that if I do not run the python code then this method executes perfectly fine without delays.
And by the way - after approx. 10 minutes the thing shows the report. It just locks up for 10 minutes and then continues normally.
Suggestions on where to go from here?
So, I would really appreciate if anyone can give me any info on there should I go now. At the moment I am trying to isolate the case in a separate clean project and as soon as I succeed I will post it here.
Thanks!
Update 1: Python script example
So far I only got one piece of additional information - this problem occurs even if you run a minimal script. So, even executing script 0 (which just returns 0) the problem will occur.
Update 2: Running in a separate domain
Running python in a separate domain did not help. The issue is still present.
Update 3: CurrentUICulture is involved!
During my debugging sessions I noticed at some point that in the problematic scenario AppDomain tries and fails to resolve the following resource assemblies:
mscorlib.resources, Version=4.0.0.0, Culture=fi, PublicKeyToken=b77a5c561934e089
mscorlib.resources, Version=4.0.0.0, Culture=fi-FI, PublicKeyToken=b77a5c561934e089
This is the reason for the 10-minute delay - it just tries to load that assembly over and over again (both CurrentCulture and CurrentUICulture are set to fi-FI). If, however, I change the CurrentUICulture to en-US then the problem disappears (as it not longer needs that assembly.
But again - the mystery still remains - if the CurrentUICulture is set to fi-FI and I execute any script via IronPython it will desperately try to load this resources file and fail all the time. If anyone is able to explain this to me - please do :)
The text in Update 3 actually contains the resolution. At the moment the only solution I know is to change the CurrentUICulture to en-US for the moment when the report control is loading and rendering. This effectively eliminates the 10 minute delay.
I have essentially two programs:
main.exe
update.exe
Update creates a flag file (update.inprogress) so that main cannot run while the update is in progress.
If main opens and that file exists, it immediately exits to prevent a program in use conflict.
I'm only having one issue. If the update is in process, the main program closes without and reason when they try to go in. I need to tell them the program is updating to keep them from calling us that the world has come to an end...
My question is, how can I issue a message that the update is in progress without tying up the main.exe? If I issue it from main.exe, then it will be in use and cannot be updated.
I was thinking of opening up notepad and putting a message in there but that just seems like a bad way of doing it.
I could also create another exe that only displays this message, but, if I have to update it, it will be in use too.. kind of defeats my purpose.
Anyone have a better idea?
Clarification:
This is a peer-to-peer network. The update could be run on workstation XYZ and someone could attempt to get into the main.exe at workstation ABC. This is why I am using a flag file. I have to way to check the process running on another workstation.
I assume that when update.exe runs, it does not need to update itself? If that is the case, you can modify update.exe to invoke main.exe if no updates are necessary.
For instance, if an update is necessary(you can accomplish this via a adding a version number to your main.exe and checking it), update.exe will create your update.inprogress file and run the updates. Then if another instance of update.exe runs, it will see the update.inprogress file and alert the user that update is in progress and terminate itself without tying up main.exe. If update.exe runs when no updates are necessary and update.inprogress does not exist, it will invoke main.exe programmatically.
I would suggest to create a thread from your update.exe to check for the existence of your main.exe process. In case it shows up, alert the user with a message from your update.exe.
Recently deployed a project into production and have run into the "Invalid postback or callback argument" error. We haven't encountered this in testing at all and after some research have found that the problem occurs in the following situation:
Old version is published and accessed.
New version is published and accessed without clearing the Temporary Files.
Drop down is changed twice. (The first time everything works fine.)
The fix for the clients that have called in has been to clear their temporary internet files but this isn't the ideal fix. Can anyone think of a reason why this would be happening and stop happening after the temp files have been cleared?
BTW: The app is ASP.NET 3.5 written in C#. We're using a javascript call back in this particular control that's causing this issue.
We didn't want to use the "enableEventValidation=false" trick as this isn't a consistent issue. From pretty early on, we were able to fix the issue case by case by clearing the temp files.
After some more looking today it was suggested that we rename our js file and behold, the issue is resolved locally. Seems that each user has had our old js file stored.
As to why it was throwing the "Invalid Postback" rather than a javascript error, we're not sure. There are other ways of specifying the version number in the script tags but for now we opted for the rename.
Since you mentioned that you're using a javascript callback, this may be related to event validation. If that's so, there is a workaround for that problem which is adding the following line to web.config:
<pages enableEventValidation="false"/>
So that, event validation is disabled in your pages. To turn it off is not recommended for security reasons because it verifies that arguments are originated by the server control.
You can get detailed information here about why this error occurs.