Is there a way/system to debug/monitor code without stopping execution?
In industrial automation control programming (PLC/PAC/DCS) it is possible to connect the debugger while the program is running, and see in the code editor the value of variables and expressions, without setting breakpoints or tracepoints.
As an example, let's have a F# multithreaded application, where code is executed in a continuous loop or triggered by timers. Is there a way to attach a debugger like Visual studio Debugger and see the values of variables and expressions (in the code editor or in a watch pane) WITHOUT interrupting the execution?
It doesn't matter if it's not synchronous, it's acceptable if the debugger/monitor does not capture all the code scans.
I am tasked to create an high level controller for a process plant and I would like to use C# or F# or even C++ with a managed or native application, instead of a PAC system. But being forced to interrupt execution to debug is a huge disadvantage in this kind of application.
UPDATE
First of all thanks to all for their answer.
Based on those answers, though, I realized that probably I need to reformulate my question as follows:
Is anyone aware of any library/framework/package/extension that allows to work with a native or managed application in windows or linux (C#, F# or C++) the exact same way as a PAC development platform, specifically:
1) Put the dev platform in "status" mode, where it shows automatically the runtime value for variables and expressions present in the code exceprt currently visible, without interrupting execution?
2) Create watch windows that show the runtime value of variables and expressions, again without interrupting execution?
Also, what I am looking for is something that (like any PAC platform) offers these features OUT OF THE BOX, without requiring any change in the application code (like adding log instructions).
Thank you in advance
UPDATE 2
It looks like there is something (see http://vsdevaids.webs.com/); does anyone know whether they are still available somewhere?
UPDATE 3
For those interested, I managed to download the last available release of VSDEVAIDS. I installed it and looks working, but it's pointless without a licence and couldn't find information on how to reach the author.
http://www.mediafire.com/file/vvdk2e0g6091r4h/VSDevAidsInstaller.msi
If somebody has better luck, please let me know.
this is a normal requirement - needing instrumentation / diagnostic data from a production system. Its not really a debugger. Its usually one of the first things you should establish in your system design.
Not knowing your system at all its hard to say what you need but generally they fall into 2 categories
human readable trace - something like log4net is what I would recommend
machine readable counters etc. Say 'number of widget shaving in last pass',..... This one is harder to generalize, you could layer it onto log4net too. Or invent your own pipe
With regards to your edited question, I can almost guarantee you that what you are looking for does not exist. Consequence-free debugging/monitoring of even moderate usefulness for production code with no prior effort? I'd have heard of it. Consider that both C++ and C# are extremely cross-platform. There are a few caveats:
There are almost certainly C++ compilers built for very specific hardware that do what you require. This hardware is likely to have very limited capabilities, and the compilers are likely to otherwise be inferior to their larger counterparts, such as gcc, clang, MSVC, to name a few.
Compile-time instrumentation can do what you require, although it affects speed and memory usage, and even stability, in my experience.
There ARE also frameworks that do what you require, but not without affecting your code. For example, if you are using WPF as your UI, it's possible to monitor anything directly related to the UI of your application. But...that's hardly a better solution than log4net.
Lastly, there are tools that can monitor EVERY system call your application makes for both Windows (procmon.exe/"Process Monitor" from SysInternals) and Linux (strace). There's very little you can't find out using these. That said, the ease of use is hardly what you're looking for, and strictly internal variables are still not going to be visible. Still might be something to consider if you know you'll be making system calls with the variables you're interested in and can set up adequate filtering.
Also, you should reconsider your "No impact on the code" requirement. There are .NET frameworks that can allow you to monitor an entire class merely by making a single function call during construction, or by deriving from a class in the framework. Many modern UIs are predicated on the UIs being able to be notified of any change to the data they are monitoring. Extensive effort has gone into making this as powerful and easy as possible. But it does require you to at least consider it when writing your code.
Many years ago (think 8 bit 6502/6809 days) you could buy (or usually rent, I seem to remember a figure of £40K to purchase one in the late 80s) a processor simulator, that would allow you replace the processor in your design with a pin compatible device that had a flying lead to the simulator box. this would allow things like capturing instructions/data leading up to a processor interrupt, or some other way of stopping the processor (even a 'push button to stop code' was possible). You could even step-backwards allowing you to see why an instruction or branch happened.
In these days of multi-core, nm-technology, I doubt there is such a thing.
I have been searching for this kind of features since quite a long time with no luck, unfortunately. Submitting the question to the StackOverflow community was sort of a "last resort", so now I'm ready to conclude that it doesn't exist.
VSDevAids (as #zzxyz pointed out) is not a solution, as it requires significant support from the application itself.
Pod cpu emulators (mentioned by #Neil) aka in-circuit emulators (ICE) and their evolutions are designed to thoroughly test the interaction between firmware and hardware, not so useful in high level programming (especially if managed like .NET).
Thanks for all contributions.
Related
I'm going to design an Application (C# or VB.NET) which use .NET Framework to run for very long time. It may be restarted every year or even more...
Is there anything (using special design patterns or so) which I must care about in designing "Long time running applications in .NET"?
Is .NET ever a good platform for these kind of applications or I should use other platforms such as J2SE?
(It's not a web application.)
I actually would say that using .NET is well-suited to long running applications. Managed code, in general, tends to do fairly well in this type of scenario, as a compacting GC helps prevent issues that can arise due to memory fragmentation over time.
That being said, it's difficult to give much guidance, as there's very little information in the question itself. The "every year or more" run times is not enough information to say that a particular framework or language choice would benefit - any language can work, as the issues that arise from long running applications tend to be more design issues, and less framework/language/toolset/etc.
I've written some .NET-based applications which run as services and stay continually running for very long times, and never had any issues with the application (at least none related to the technology itself).
I'd worry less about keeping an app running and more about what happens when it inevitably stops - and make no mistake, it WILL stop.
There are many factors that can go wrong; a crash, server fault, network failure or someone simply stopping the app. The true work will be resuming the application's tasks after it restarts.
.NET's garbage collector is very good, so as long as you don't have any non-obvious memory leaks, that should be OK. "Non-obvious" includes not releasing event-handlers when you're truly done with them., using lambda expressions for event handlers in other classes, and that sort of thing.
Be sure that you're catching and logging all unhandled exceptions. If it does die, you'll want to know why.
Also, take a look at the application restart support in Windows 7. This can restart your app in case it does fail. Although it's written for unmanaged code, it's accessible for .net in the Windows 7 API code pack.
I develop mainly line of business applications.No scientific operations. No complex calculations. Just tie User Interface to database. The only reason I use threading is to do some work in background and still keep UI responding.
This may not be the best approach but this is what I follow
1.Create an working application first(without threads) and give it to end user to play for the sake of feedback.
2.Once all requirements are locked, I try to use threads wherever it makes sense to improve performance.
The code for steps 1 & 2 is overwhelmingly different and threading code dominates the actual code.
1.Will F# make my life easier in case of Line of Business applications?
2.Are there any particular UI technologies that will fit best with F#? I mainly work on ASP.NET & Silverlight. WPF now & then.
3.Are there any good examples of Line of business applications/demos with F#?
I am not asking whether it is possible to develop Line of Business application in F#. I am asking whether F# will make my life easier to develop Line of Business applications when compared to C#? My main concern will be threading & UI synchronization.
I'm in the same boat as you, doing lots and lots of line-of-business type apps, nothing "fun" like games or compilers or search engines.
Your mileage will vary, but at least in my own experience a lot of dev teams are reluctant to jump right into F# because no one else on the team knows or has even heard of it. And right off the bat, you have to fight those questions like "what does it do differently from C#?" If you can convince your boss to let you write a few demo apps with it, go for it!
So with that being said, I find that C# isn't very good at business rules, but it handles GUIs like a champ; F#'s immutability makes GUI development awkward, but business rules and workflows feel natural. So the two languages have their own strengths and compliments one another's weaknesses.
In my own LOB apps, F# runs circles around C# in a few areas:
F#'s async workflows and mailbox processors orders of magnitude easier to work with than native threads and even task parallel library. Since using mailbox processors for interthread communication, I don't even remember the last time I've had to lock or thread.join() anything for syncronization at all.
Defining business rules engines and DSLs with unions FTW! Every non-trivial LOB app I've ever worked on has its own half-baked rules language and interpreter, and its almost always based on recursively switching on an enum to drill through the rules and find a match. Current project I have now contains 1300+ public classes, 900 or so are simple container classes to represent a rule. I think representing the rules as an F# union would substantially reduce the code bloat and make for a better engine.
Immutable code just works better -- if you get a new object with an invalid state, you don't have to search far to find the offending line of code, everything you need to know is on the call stack. If you have a mutable object with an invalid state, sometimes you have to spend a lot of time tracking it down. You can write immutable code in C#, but its really hard not to fall back on mutability, especially when you're modifying an object in a loop.
I hate nulls. I can't give an exact estimate, but it feels like half the bugs we get in production are null reference exceptions -- an object is improperly initialized and you don't know about it until you're 30 stack frames deep in code. I think F# would help us write more bug free code the first time around.
C# usually works well when:
You're writing GUI code or working with inherently mutable systems.
Exposing a DLL or web service to many different clients.
Your boss won't let you use the tools you want ;)
So if you can get over the "why would we want to use a new language hurdle", I think F# will indeed make your life easier.
That's a very hard question to answer - I think that F# would make some aspects of your life much easier and some a bit harder.
On the plus side, dealing with threading should be relatively painless - F# async workflows are a huge benefit. Also, F# Interactive makes rapidly iterating and exploring code very easy. To me, this is a huge benefit over C#, since I can test out minor code changes without going through a full build.
On the down side, the tooling for F# isn't where it is for C#, which means that you won't have access to GUI-builders, refactoring tools, etc. It's hard to say how big of a productivity hit this would cause you without knowing more about your scenario. One workaround would be to create a multi-language solution which has a thin C# front-end, but again the complexity may not be worth the benefit.
#Juliet and #kvb have good answers, I just want to reiterate how useful F# is for making threading easy. In my blog post "An RSS Dashboard in F#, part six (putting it all together with a WPF GUI)", I say
...Note the nifty use of ‘async’ here – I
use Async.StartImmediate, which means
all the code runs on the UI thread
(where the Click handler starts), but
I can still do non-blocking sleeps
that don’t jam up the UI. This is one
way that F# async just blows the doors
off everything else.
...
Our “ago” information (“3 minutes
ago”) will quickly get stale if we
don’t refresh it, so we start a loop
that redraws every minute. Once
again, F# async kicks butt, as I can
just write this as though it were a
synchronous loop running on the UI
thread, but the non-blocking sleep
call ensures that the UI stays live.
Awesome. ...
but that blog post is an example of using F# to hand-code the entire UI. That implies trading away all of the great GUI tooling you get with C# or VB. I imagine that a hybrid approach can potentially net almost all of the benefits of both (with the cost of having two projects in the solution where you previous just had one), but I don't (yet) have direct experience of my own to share here.
(Is there a canonical "problem example" of a C# GUI app where you need to add threading to improve perf or keep the app live during some long operation? If so, I should check it out.)
Something you might like to see:
The First Substantial Line of Business Application in F#
A big LOB app in F#.
To address this I posted some thoughts of mine in using F#,
http://fadsworld.wordpress.com/2011/04/13/f-in-the-enterprise-i/ http://fadsworld.wordpress.com/2011/04/17/fin-the-enterprise-ii-2/
I'm also planning to do a video tutorial to finish up the series and show how F# can contribute in UX programming.
I'm only talking in context of F# here.
-Fahad
If I have an existing solution containing multiple c# projects, are there any static analysis tools that can help me determine which areas of code are the most often used?
I'd like to use this information in order to determine which areas should have their test coverage ramped up first.
I've looked at some static analysis tools already, but they mostly seem to focus on things like complexity, coding conventions, code duplication etc.
Alternatively, if there aren't any analysis tools available that can do this, do you have any advice about how to determine which code I ought to focus on testing first?
Thanks!
EDIT: Just to clarify, what I'm looking for isn't code coverage. I'd like a rundown of which parts of my application are most often used, so that I can in turn focus on improving the coverage in those areas. I'm trying to avoid just writing tests for areas that don't yet have any, as they may be edge cases that aren't often executed.
Even static analysis tools which do try to figure out what happens at run-time do not usually try to estimate how often a piece of code is executed. The subject is hard enough as it is!
But dynamic analysis tools (e.g. profiling tools that either rely on transparent instrumentation of the code or use sampling) can tell you, after one or several "typical" executions (you provide the entries that you judge typical), how often this or that function was executed.
See Profiling (computer programming) on Wikipedia.
If I understood the question right, you are looking for a profiler. Give EQATEC Profiler a try. It's free.
It's originally intended to profile an application before shipping (to detect bottlenecks by measuring execution time of methods etc.) so I'm not sure if it's suitable for an application in a productive environment. At least it changes your code for profiling purposes and that might be unwanted. You should check this out.
Code coverage appears to be what you want.
NCover is a popular code coverage tool for .NET, if you can afford it.
What you're asking for is simply impossible to do accurately. The number of times something is executed can and usually will depend on the data that's entered at run-time. The best you can hope for from a static analysis tool isa direct answer when statically determinedAn O(N) style analysis otherwise
Even the latter would be quite difficult to get right overall. For example, it would need to know the complexity of essentially every function in the (huge and ever-expanding) .NET library. Some of those are hard to even characterize.
Just for example, how long does it take to allocate a block of memory? Well, usually it's usually nearly constant time -- but it's always possible that an allocation can trigger a garbage collection cycle, in which case the time taken will be (roughly) proportional to the number of objects still in use that were allocated since the last GC cycle...
"Profiler" is what you're looking for; which you choose is up to you.
I've used HP's Diagnostic Server to do this, although it'd cost money. It'll tell me what methods are called how many times, and the average and worst-case time spent in them.
As an important safety tip, running a profiler will slow down the execution of your code; it's not ideal for a long-term installation into a production environment.
If you want to see just what is used:
SD C# Test Coverage Tool
If you want to see how often it is used:
SD C# Profiler Tool
If coverage is not what you look for then you could look use two things:
As suggested a profiler and run predictive test scenarios.
Use performance counters which would end in a more permanent solution. These are quite difficult to implement but are helpful to diagnose performance deltas by analyzing the counters report. One way to implement them would be to wrap boundaries and manage counters from those wrap. Be wary that it's way much easier to integrate in a new project than in an existing one.
I'm embarking on a C# project where certain tasks will be divvied up and run on multiple threads. I'm looking for as many good tools as possible to help make sure I'm running as efficiently as possible. So I want to watch for things like resource (CPU) usage, blocking, deadlocks, threads that are waiting for work, and so on. I want to be able to compare different approaches to see what works best under different conditions.
I'm also looking to learn what Perfmon counters are more or less useful for trying to optimize and compare threading models.
I also can't afford to purchase anything too expensive, so the free-er the better.
This is a C# project on .NET 3.5, with VS 2008 (though I could use the VS 2010 beta if it offered more help for threading, which I've heard it does).
Thanks.
EDIT: I'm definitely looking for Perfmon recommendations, as well as any other tool that I can also use when I want to monitor the app in a production environment. So, debugging tools are needed, but I also want tools for non-debug environments. Thx.
FURTHER EDIT: Here are a few useful links I've found since I asked the question:
Tools And Techniques to Identify Concurrency Issues (MSDN Magazine Article)
PerfMon - Your debugging buddy (important counters for .NET debugging, including threading related counters)
Indeed Visual Studio 2010 is a good option: http://www.danielmoth.com/Blog/2009/05/parallel-tasks-new-visual-studio-2010.html
One "trick" that helps me when debugging threads is to remember to set each thread's name property, as it helps a lot during debugging. If the thread's Name property is not assigned, it has a null value, and the debugging window will show <No name>, so it it won't be very helpful.
I've had the best results by creating a logger class and instrumenting my code so that I can catch when threads start and stop and measure elapsed time for their internal processes. You can also use the various .Net libs for capturing memory load as mentioned here: How to get memory available or used in C#.
I've logged to queues, databases (System.Data.Sqlite is great for this), and files. Even a cobmination queue->database with the logger on a separate thread. This has particularly helpful for multi-threaded Windows services because I can monitor the logs while its running and even control the logging verbosity through a separate control table via a small Windows app. Even the sys admins find it easy to use.
It's not that much extra work and you always have it once you deploy.
Another thing i would suggest is: expose some of your classes as wmi instances. This way you can tweak settings and call functions without restarting the application, this way you can notice the effects immediately. See this article.
I know this is a C# question, but still : in C# you can use any CLR libraries including those written in F#. In F# there are lots of cases where concurrency becomes very easy due to its functional nature (no side effects). Maybe writing some parts in F# might pay of.
Why wasn't the Java "throws" clause (in method declaration) included in C#?
Anders Hejlsberg (the lead C# architect) explains it in this interview:
http://www.artima.com/intv/handcuffs.html
(In addition to Patrik's somewhat-definitive answer.)
Checked exceptions in Java are a very controversial issue. I used to love them, and missed them a lot when writing C#. It felt like I was driving without a seatbelt. Now, they annoy me... because while they sound like a good idea in theory, they've definitely caused me a lot of grief but without providing much tangible benefit. I can't remember ever encountering a bug in C# code which checked exceptions would have saved me from. That's not to say it can't happen, but it hasn't happened to me.
The annoying thing is that in some ways it still feels like C# is too lax - but that Java's approach isn't quite the right one. It's like there's a better solution waiting to be discovered, and Java's attempt was a good experiment, but it didn't quite work.
I think checked exceptions, as a language feature, exposes some of the cultural differences between Microsoft and Sun.
For the most part, Microsoft is a client company. Most of the software they make, and what their development stack is targeted at, is client software.
Yes, yes, I know that Microsoft makes server software. However, Office and Windows are WAY bigger in terms of revenue than Windows Server and Exchange are.
I think it's fair to say that most software written in .NET, (and even more so with VB 6) is client software. Sure, a big chunk of it is Web Software, that runs on a Web Server, but most of it is really ... "clienty type web apps". I'd say most web apps are more like "Word" then they are like Exchange.
And yes, I know there are WCF and SOAP services and things like that, but those are usually just "middle ware" for "clienty" type stuff.
Sun, on the other hand, is primarily a server company. Their software isn't exactly the greatest when it comes to user interface (this isn't a slight on Unix... just Solaris.. Mac OS X is based on unix and it has a phenomenal user interface, the difference between the two is that Sun really doesn't care as much about UI as Apple does ). They even sell THIN CLIENTS, which try to push everything onto the server.
So... in any case... Microsoft is mainly a client company, and Sun is mainly a server company.
When you write server software, reliability is a big thing. It's huge. If an email server crashes, people don't get email, and business grinds to a halt. So, making sure that the server can intelligently handle most errors that can happen is a big part of selling an email server.
With client software. reliability IS important, but no where near AS important as it is with server software. As long as most main line scenarios work, people are happy. In many cases, crazy edge scenarios can just be ignored, or handled generically.
One key to being super reliable is making sure that you handle all the possible edge cases that can occur. What happens if we can't open the database file because it's locked by another process, or we don't have permission to read it? What if we run out of memory, or disk space? What happens if the power goes out while running this procedure?
With really high reliability requirements, having checked exceptions CAN be helpful.
If there is a scenario you didn't anticipate, and it's important to your business that you anticipate everything, then having the compiler tell you ... "hey you didn't handle the RocketFuelExhaustedException" would be helpful.
So, I think checked exceptions stem from Sun's point of view as a server vendor.
To Microsoft, as a client company selling developer tools to client software developers, checked exceptions are of course horribly irritating things that just get in the way of real work getting done.
That's my $0.02 anyways...
The main reason is that C# designers decided not to use "checked exceptions". This means that the developer doesn't have to surround an exception throwing clause inside a try-catch block. It was considered that this is only helpful for small scale applications and doesn't have a real benefit for bigger projects. Additionally checked exceptions were actually misused by the developers, who constantly use empty catch blocks. Since there are no checked exceptions, there is no reason for a method to declare, which exceptions could be thrown.
The use or not of "checked exceptions" is a controversial topic, but most seem to agree that there is no need for them. Spring, which is a prominent framework in Java, turns checked exceptions into runtime ones.
Exceptions are apparently 'exceptional' events. In .net's paradigms, exceptions should never occur (that's why you have methods like TryParse, ...), so it makes little sense to be forced to handle events that shouldn't occur anyways.