I've been having this issue for a while now an I just cant work past it anymore. I use to just recreate the project but now that solution no longer works for me either and i've had no luck with google at all.
I have a silverlight 5 website with a WCF service. Basically what happens is I'll have a piece of code i need to debug e.g.
using (var connection = new SqlConnection(AccessCardConnection))
{
connection.Open();
var command = connection.CreateCommand();
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "GetAccessCardTimes";
command.CommandTimeout = 300;
command.Parameters.AddWithValue("#EmployeeName", fullName);
command.Parameters.AddWithValue("#FirstDate", firstDate);
command.Parameters.AddWithValue("#LastDate", lastDate);
var accessCardReader = command.ExecuteReader();
while (accessCardReader.Read())
{
var time = TimeSpan.Parse(accessCardReader["TotalOnSiteTime"].ToString());
duration += time;
}
return (duration.TotalHours);
}
However once the first break point hits its anybodies guess which line it will jump to.. It doesnt follow any kind of logical order it, if i set a break point on connection.Open() for example it may jump back into the connection intialization then back down again and jump any which way it pleases, up, down, stay on the same line etc. Jumping in and out of methods as it seems to have no regard for what its doing.
None of the solutions I've found online have helped:
Why do my debugger randomly jump out of debug mode? (Fix is for visual studio 2008)
Visual Studio 2010 Debugger jumps around (Deleting the /bin and /obj files to regenerate the symbols didnt help)
Please can someone give me a hint as to what it may be I cant work like this :(
Thanks for your assistance!
Sounds like you have multiple calls hitting the service. WCF spawns new worker threads for each request so what you are seeing is the debugger "jumping" from thread to thread.
Related
error message: form1.execValidate is not a function. but this has worked fine for years!
Last week the client (large bank) rolled out a new version of Adobe Reader XI 11.0.21. Perhaps registry keys were changed as well - don't know.
So now all livecycle forms are crashing. Below is one error message seen on the console followed by the crash.
The code being used has been executed 10K+ times over ~5 years, over roughly 5 different forms over many versions.
form1.FirstPage.sfBody.sfSectionB.sfEnder.SendReferral::click - (JavaScript, client)
var res = form1.execValidate(); // does form validation, if all good returns true
if (res) {
cLookFeel.fMailTo(event.target);
}
(Code is attached to the click method on a button, cLookFeel is the name of my code block.)
And strangely - Reader then seems to (often) crash. Go figure.
followed by a crash:
Okay, turns out it's a known bug by Adobe on 11.0.21. They've issued a fix.
https://helpx.adobe.com/acrobat/release-note/acrobat-dc-august-11-2017.html
When I attempt to run the line:
MyDBContext.Database.Log = Console.Write
The compiler smiles and tells me I don't know what I am doing...
The app won't compile because of the line and the error on that line is:
Overload resolution failed because no accessible Write accepts this number of arguments.
That makes sense. 'Console.Write' returns nothing and I am setting it equal to a System.Action(Of String)
This just seems kind of half baked.
I tried numerous ways to fix it including delegates, and some of the other 'new possibilities' moving this off the Context is supposed to offer but still no dice.
What am I missing? Is it something that was changed at the last minute?
I have two large edmx files (one connects to SQL Server and the other to Oracle) in the solution and all of that is working great.
Here are my version numbers if that can help.
EntityFramework 6.0.0.0 (folder is ...\EntityFramework.6.1.3\lib\net45\EntityFramework.dll)
EntityFramework.SqlServer 6.0.0.0 (folder is ...\EntityFramework.6.1.3\lib\net45\EntityFramework.dll)
Oracle.ManagedDataAccess.EntityFramework 6.121.2.0
I have a tool I created that lets me paste the output of the L2S 'mycontext.log' into it and it then parses it and creates SSMS ready SQL with variables... it has been incredibly useful. This has been one of my favorite features of L2S.
Please help me understand why this isn't working.
Thanks in advance.
This technique works for me:
public override int SaveChanges()
{
SetIStateInfo();
#if DEBUG
Database.Log = s => Debug.WriteLine(s);
#endif
return base.SaveChanges();
}
http://blogs.msdn.com/b/mpeder/archive/2014/06/16/how-to-see-the-actual-sql-query-generated-by-entity-framework.aspx
Well, the answer was to research the Action(T) Delegate which showed me how to do it.
#If DEBUG Then
myctx.Database.Log = AddressOf Console.Write
#End If
Just needed the AddressOf and I was back in business.
I have an Excel add-in with a button on it that calls a WPF application on a new thread. When I close Excel not having opened my WPF application or after opening it and then closing it again, Excel closes immediately, however, whenever I open the application and then close Excel, Excel takes 5-10 seconds to close. I've only come across these solutions, neither of which has helped:
VSTO Runtime Update to Address Slow Shutdown...
This one sort of asks the question, but the asker's issue ends up being different.
I'm running VS 2010 and Excel 2010, so there shouldn't be an interoperability problem.
Does anyone have a suggestion?
Thread Code:
Private qbdThread As Thread = Nothing
Private frmQBD As QBDApplication.MainWindow
qbdThread = New Thread(New ParameterizedThreadStart(AddressOf RunQBD))
qbdThread.SetApartmentState(Threading.ApartmentState.STA)
qbdThread.Start(TabletType)
AddHandler QBDApplication.MainWindow.QBDClose, AddressOf QBDThreadClose
Private Sub RunQBD(Optional tabletQBDSelected As String = Nothing)
...
frmQBD = New QBDApplication.MainWindow(contacts, saveLocation, tabletQBDLocal)
frmQBD.Show()
frmQBD.Activate()
System.Windows.Threading.Dispatcher.Run()
End Sub
This code runs when the app is closed by the user on the new thread:
Me.Close()
System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown()
An event is then raised on the main thread (ThisAddin.vb) with this code:
Private Sub QBDThreadClose()
qbdThread = Nothing
frmQBD = Nothing
End Sub
One other thing to note is that when frmQBD is not created as a class variable, and instead dimensioned in the "RunQBD" sub, this issue does not occur. This would solve my problem, but then I wouldn't be able to access something like frmQBD.Activate() on the main thread, which I need to be able to do.
EDIT: Code has been updated
We found a solution for this problem.
You have to set an AppSwith in the framework
Public Sub EnablePointerSupport()
AppContext.SetSwitch("Switch.System.Windows.Input.Stylus.EnablePointerSupport",True)
End Sub
You can find more information about it here and here.
This Microsoft bug is described at https://connect.microsoft.com/VisualStudio/feedback/details/783019/word-slow-shutdown-on-windows-8-when-using-wpf-in-application-addin. It was initially reported in 2013 and supposedly fixed in 2014, but appears to be back now.
We can reproduce this exact problem with Excel and Word 2016 running on Windows 10, but mysteriously not in PowerPoint. Latest version of VSTO Runtime is installed. We could not reproduce the problem in Office 2013 running on Windows 8.1.
The workaround is as described at the link above--go to Device Manager > Human Interface Devices and disable "HID-compliant touch screen" (in our testing) or perhaps another one of the "HID-compliant" items.
We're migrating SQL to Azure. Our DAL is Entity Framework 4.x based. We're wanting to use the Transient Fault Handling Block to add retry logic for SQL Azure.
Overall, we're looking for the best 80/20 rule (or maybe more of a 95/5 but you get the point) - we're not looking to spend weeks refactoring/rewriting code (there's a LOT of it). I'm fine re-implementing our DAL's framework but not all of the code written and generated against it anymore than we have to since this is already here only to address a minority case. Mitigation >>> elimination of this edge case for us.
Looking at the possible options explained here at MSDN, it seems Case #3 there is the "quickest" to implement, but only at first glance. Upon pondering this solution a bit, it struck me that we might have problems with connection management since this circumvent's Entity Framework's built-in processes for managing connections (i.e. always closing them). It seems to me that the "solution" is to make sure 100% of our Contexts that we instantiate use Using blocks, but with our architecture, this would be difficult.
So my question: Going with Case #3 from that link, are hanging connections a problem or is there some magic somewhere that's going on that I don't know about?
I've done some experimenting and it turns out that this brings us back to the old "managing connections" situation we're used to from the past, only this time the connections are abstracted away from us a bit and we must now "manage Contexts" similarly.
Let's say we have the following OnContextCreated implementation:
private void OnContextCreated()
{
const int maxRetries = 4;
const int initialDelayInMilliseconds = 100;
const int maxDelayInMilliseconds = 5000;
const int deltaBackoffInMilliseconds = initialDelayInMilliseconds;
var policy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(maxRetries,
TimeSpan.FromMilliseconds(initialDelayInMilliseconds),
TimeSpan.FromMilliseconds(maxDelayInMilliseconds),
TimeSpan.FromMilliseconds(deltaBackoffInMilliseconds));
policy.ExecuteAction(() =>
{
try
{
Connection.Open();
var storeConnection = (SqlConnection) ((EntityConnection) Connection).StoreConnection;
new SqlCommand("declare #i int", storeConnection).ExecuteNonQuery();
//Connection.Close();
// throw new ApplicationException("Test only");
}
catch (Exception e)
{
Connection.Close();
Trace.TraceWarning("Attempted to open connection but failed: " + e.Message);
throw;
}
}
);
}
In this scenario, we forcibly open the Connection (which was the goal here). Because of this, the Context keeps it open across many calls. Because of that, we must tell the Context when to close the connection. Our primary mechanism for doing that is calling the Dispose method on the Context. So if we just allow garbage collection to clean up our contexts, then we allow connections to remain hanging open.
I tested this by toggling the comments on the Connection.Close() in the try block and running a bunch of unit tests against our database. Without calling Close, we jumped up to ~275-300 active connections (from SQL Server's perspective). By calling Close, that number hovered at ~12. I then reproduced with a small number of unit tests both with and without a using block for the Context and reproduced the same result (different numbers - I forget what they were).
I was using the following query to count my connections:
SELECT s.session_id, s.login_name, e.connection_id,
s.last_request_end_time, s.cpu_time,
e.connect_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_exec_connections AS e
ON s.session_id = e.session_id
WHERE login_name='myuser'
ORDER BY s.login_name
Conclusion: If you call Connection.Open() with this work-around to enable the Transient Fault Handling Block, then you MUST use using blocks for all contexts you work with, otherwise you will have problems (that with SQL Azure, will cause your database to be "throttled" and ultimately taken offline for hours!).
The problem with this approach is it only takes care of connection retries and not command retries.
If you use Entity Framework 6 (currently in alpha) then there is some new in-built support for transient retries with Azure SQL Database (with a little bit of configuration): http://entityframework.codeplex.com/wikipage?title=Connection%20Resiliency%20Spec
I've created a library which allows you to configure Entity Framework to retry using the Fault Handling block without needing to change every database call - generally you will only need to change your config file and possibly one or two lines of code.
This allows you to use it for Entity Framework or Linq To Sql.
https://github.com/robdmoore/ReliableDbProvider
Title's about it. WPF app with some WCF stuff for IPC. I call Application.Current.Shutdown() and the app continues on happily. I thought Shutdown was supposed to be unstoppable.
Perhaps because it's being called from a background thread? Do I need to do some dispatcher fiddling?
You get an exception when I call Application.Current.Shutdown in any thread other than the main one, so I'd assume you where using "dispatcher fiddling" properly already.
In any case, this compiles and quits an application, so if the dispatcher bit doesn't look like what you have you could sling it in:
ThreadStart ts = delegate()
{
Dispatcher.BeginInvoke((Action)delegate()
{
Application.Current.Shutdown();
});
};
Thread t = new Thread(ts);
t.Start();
In my experience all threads have to either be terminated explicitly or be marked as background threads in order for the application to close.
Here is an example of kicking off a read thread in the background:
_readThread = new Thread(new ThreadStart(ReadThread));
_readThread.Name = "Receiver";
_readThread.Priority = ThreadPriority.Highest;
_readThread.IsBackground = true;
_readThread.Start();
The IsBackground property is the key. Without that being set, the thread won't terminate on when you call Shutdown.
I only experience Application.Current.Shutdown not working when I'm running from Visual Studio. Within Visual Studio (at least the 2010 version I'm using) Application.Current.Shutdown doesn't do a thing. If I single step through it executes this line and then continues. If I run the program (as an .exe) from Windows Explorer then Application.Current.Shutdown works fine.
There is probably an explanation for this since during debug other threads are active, but I can't explain it.