I have the source code for a C# project (which wasn't written by me) which I run on one of our servers.
There is a particular part of this program (a menu option) which occasionally fails silently and I can't figure out why from just looking at the source. (The part of the program that fails requires various features that are not on my development machine, so I can't test it on my own machine).
I would like to debug this program and in particular step through the code line by line. Since the server is outside our firewall, remote debugging feature will not work.
Is there any alternative other than installing Visual Studio on the server, ie are there any runtime debuggers that will show the C# source code and allow you to set breakpoints etc?
The project was written in VS 2008 and targets Framework 2.0.
You should be able to use DbgClr for a framework 2.0 app. It is a standalone graphical debugger that comes with the SDK. You will need to ensure that the PDB files, that matches the running build of the application, are available to the debugger.
That being said, if you have any option to punch a hole in the firewall, so you can use remote debugging, that would probably be the easiest way to go.
Of course, it would be best practice to setup your local environment so you can reproduce the bug and debug locally; but I can understand if there are reasons that might make this unfeasible.
Another option is to use WinDbg with the SOS extensions. It's an extremely light weight debugger that doesn't even require the .Net framework to be installed. It leaves much to be desired in the way of UI and has a steep learning curve. But once you get the hang of WinDbg it's an amazingly powerful debugging tool.
Related
I develop C# applications using VS 2010 Ultimate.
Usually, those applications run for long time, without user interaction and, of course, they usually have bugs inside.
Unfortunately, often the application crashes randomly and you just can't reproduce the error. Also sometimes I only have the message "The application has stopped working" with no more informations.
I can install Visual Studio on the machine of the customer, but I can't let him run VS and compile/start the source code in debug mode! What I need is to start VS after the application was started and crashed. It seems to be possible to do this, in fact when an exception happens at runtime, Windows ask you "do you want to debug with VS?", but if I answer YES, then VS starts but simply I can't see the source code (it is on the pc as well), thus I can't inspect the row of code that is causing the exception. VS just tells me "source code not available". Actually, I can't imagine how Windows could start VS and know where the source code of the crashed application is!
Does anyone knows how does this debugging scenario is intended to work, and how to configure it??
Thanks a lot,
Simone
Windbg debugging tool solves the purpose.
Take dump of the process state and start analyzing with windbg. It gives you the exception information
To debug from an already-running Visual Studio instance, select the "Debug" menu item, then "Attach to Process..."
Next, select the executable from the list, press "Attach" (or double-click), and you are now debugging the application. When you select "Yes" and Windows says that source code is not available, this most likely means that the PDB wasn't able to be loaded, so make sure that you have loaded the symbols for the module by examining it in the "Modules" window pane.
If you want to catch errors while running compiled program, you should use some sort of logging mechanism. These days you don't have to write it on your own, there's a great opensource logging engine designed for .NET applications, it's called NLog. It's capable of saving logs into files, emails, console or database, pretty much all you can want :).
Hope this helps :)
I'm starting out on a new project and a team member has decided to use C# as the implementation language. I don't have a lot of experience in C#, but a brief reading shows that it's very capable of being a complete cross-platform vm. Beyond the language, I've been having trouble selecting tools and workflows for managing the code as the project grows. It should be fairly small (<10K lines) but I would like to have the ability to generate documentation as the project grows, manage any external dependencies that we decide to use, and automate builds and testing. I am wondering what tools are commonly used or considered best practices for this language.
I am mainly concerned with how would a build system potentially work on *nix as well as windows? Are there C# specific tools or is Make more common? In addition, I'd like to use a dvcs, but it doesn't look like Visual Studio and MonoDevelop support the same ones. What's the common vcs of choice for C#? For testing sort of Unit testing is available for C#/Mono? Finally, I know that there are good doc generators, but with the question of the build system, I would really like to have that just be a single step in the build similar to how testing is a step. Normally I'd automate with Hudson, but I am wondering if there is something more specific to the platform.
Overall, I'd love to see a solution that provides a decent workflow on both windows and *nix without a heavy admin burden. I am pretty sure this is the holy grail of project management, so anything that puts me on that path is awesome.
In a project I work on, we use Visual Studio 2010, MonoDevelop/XBuild, Git, and monodoc. Project files created by Visual Studio 2010 can easily be read by MonoDevelop and XBuild. Also, Git is an excellent VCS for distributed development (I especially like its branching). Monodoc, with some tweaking of command line parameters, can generate documentation from XML comments in code.
You can use any dvcs you'd like with it. MonoDevelop (at least in the trunk, not sure if it has been released yet) as Git support built in. There are some plugins for Visual Studio that give you Git too.
Either way though, you don't need your source control to be integrated within the IDE, infact I prefer it not to be and use Git from TortoiseGit if I'm in windows, or from the command line on OS X (although I'm looking at Gitti for the OS X side).
For build, I would suggest TeamCity, since it supports up to three remote agents allowing you to build on Windows/Linux/Mac with the free version.
For build I'd use NAnt, although xbuild under mono works with solution files so that might be easier rather than maintaining two build scripts. I like NAnt for CI simply because I find it easier to break apart into build, test, cover, package, deploy etc.
I've found that the combination of MonoDevelop, Git, TeamCity and NAnt gives you a few nice cross-platform development setup.
I suggest you try to use one IDE mainly. Most Mono IDEs support Visual Studio formats I guess. At least SharpDeveblop does.
http://mono-tools.com seems the correct way to develop for .NET and Mono only in Windows (not free). I think this is the best option if I ever take developing for mono seriously ina commercial environment, but not 1005 sure.
http://sharpdevelop.com looks promising too, but still fells like the poor man option.
http://monodevelop.com/ is the way to go for developing for Mono in Linux.
For DVCS you can always use Tortoise stuff and be IDE independent. git works great in Linux and TortoiseGit on Windows is very nice. However, it terms of fame, SVN (not DVCS of course) is still dominant, especially it's client can connect to TFS via bridge. Mercurial and Git are starting to take place in C# community though.
CruiseControl.Net is a pretty good build / continuous integration system. It can integrate a load of applications into the build process; we use NAnt for builds, NUnit unit tests and FXCop for code analysis.
Cake (C# Make) is an open source build automation system with a C# based domain specific language that can do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages. It has tons of other built-in functionality and can easily be extended with custom code. It's available for Windows, Linux and OS X and can be used with several continuous integration systems such as AppVeyor, TeamCity, TFS, VSTS or Jenkins.
I have a program that I built that reads and writes files. I built it in Release mode, then tried to run the exe on Win7. At first, with troubleshooting on, Windows simply told me the application closed and it was looking for a solution. After a few seconds, the dialog would disappear and show nothing more.
So with some significant effort I got the debugger attached to the process, but it was only showing me disassembly, which tells me that the error taking place wasn't in my application code, but in the framework somewhere.
The strange thing is that when I let the debugger attach, then press "stop" in VS, and exit the debugger, the program actually runs at that point!
So now I'm stumped. I have an application that builds, that seems to be having a permission error when I run it, but if I let the debugger attach then close it, it runs, and there's no Exception to really look at.
How I troubleshoot this issue?
Edit: Responding to Merlyn:
It's a custom app written from scratch in c#. The only dependency it has outside of core .NET namespaces is the Ionic.Zip DLL.
Visual Studio 2008 (Writing in C# 3.5)
Windows 7 - Home Premium, v6.1 build 7600
CPU - x64 quad core
CPU are you compiling under: Any CPU
I haven't tried it on another machine or a different version of VS.
Edit: I was able to try the compiled version on another win7 computer, and it worked without issue, so it looks like a security (?) issue on my computer only.
Try it in the debugger with Just My Code disabled and Native Code enabled, then check the call stack.
Also, what happens if you run it directly in Visual Studio?
Uncheck Enable Visual Studio Hosting Process in Project Properties and see whether it still works in VS.
I'd suggest sending the issue to Microsoft support. Especially with the data given here, you will have an easy time convincing them it's their problem. You might need an MSDN subscription for that.
I'm looking into Mono and .NET C# and we'll be needing to run the code on Linux Servers in the future when the project is developed. At this point I've been looking at ASP.NET MVC and Mono.
I run an Ubuntu distro and want to do development for a web application, some of the other developers use Windows and run other .NET items with Visual Studio.
What does Mono not provide that Visual Studio does?
If running this on Linux later shouldn't we use MonoDevelop?
Are there some third party tools or add-ins that might be an issue with Mono later?
What does Mono not provide that Visual Studio does?
MonoDevelop is presumably what you mean here. MonoDevelop offers cross platform development on Linux, Mac OS X, Windows based on GTK. However it is not as polished as Visual Studio for obvious reasons - it's 3 people making it, not hundreds. It has some nice features, especially its source control plugin architecture. However as Visual Studio Express is free there aren't many advantages on Windows to using it.
It uses the same .csproj and .sln format as Visual Studio, however the XML docs format is different.
If running this on Linux later shouldn't we use MonoDevelop ?
As I mentioned above, the project formats are inter-operable.
Are there some third party tools or add-ins that might be an issue with Mono later?
Unlike Visual Studio, there aren't a huge wealth of add-ins for Monodevelop. The ones that you use in Monodevelop won't effect your .csproj files at all, as anything Visual Studio cannot read it generally ignores.
As people have said don't confuse Mono for MonoDevelop. MonoDevelop is an IDE for Mono that originally came from (forked) SharpDevelop.
Mono is the cross platform framework that 'apes' the Microsoft CLR and framework libraries.
I don't have much experience in this area but...
The Mono Project Roadmap has an overview of features that are new, upcoming, and not present in Mono compared to MS.NET. Even where Mono has the same classes as .NET, note that compatibility is not 100% (although that is generally their goal). I'm not sure if there exists a comprehensive list of things missing in Mono.
MonoDevelop is now available on both Windows and Linux so you're probably best off using it. However, MonoDevelop does appear to use the same project file format as Visual Studio and SharpDevelop, so you could make an attempt at mixing IDEs.
Of course, when using 3rd-party .NET libraries, note that many of them have not been tested with mono, and in particular anything that uses P/Invoke will not work on Mono for Linux. However, most incompatibilities with mono are minor, and if you stick with open-source libraries you can always fix any incompatibilities you run into.
You might also take a look at Mono Tools for Visual Studio. It lets your visual studio developers target and test with the mono platform.
You're aiming to always have support, and/or primarily use the software on Linux, correct? This is actually a question I asked the Mono developers at a conference a little while back, and it basically boiled down to what you want to do with it.
If you want it to always work on Linux, then use Mono. If you only care about Windows, then use Visual Studio.
If you're using Mono, then use MonoDevelop across all developers. It'll just make life a lot easier later on, and it'll make sure that whatever you write in the one will work for everyone.
Unfortunately, I do not know the answer to the exact limits/advantages of Mono vs. .NET, aside from .NET being further ahead, and Mono playing catch-up, nor about different addons.
If none of your developers need to develop on Mono for certain features, I suggest you all use Visual Studio on Windows. Then test the applications on Mono via
Mono Tools for Visual Studio
manually copy the binaries over
check out the code on Linux and build in MonoDevelop.
Personally I experienced a lot of small troubles when I tried out the third way, but luckily I am capable of finding workarounds.
It is only when you touch Mono, you know which part of your application needs to be tuned.
http://www.mono-project.com/Start
If you can help it, it'd recommend avoiding the Mono implementation of Remoting. There seem to be some unexpected hiccups and debugging it is not straight-forward.
We had a very Remoting heavy product that we tried to port to Mono so we could support Linux. Due to being unable to resolve the Remoting issues, we eventually had to abandon our attempts at supporting Linux altogether.
Caveat: my experiences may be outdated. See comments below
You don't need MonoDevelop in order to run ASP.NET program in Linux, make a shared folder on your development server (VMWare'd or real one), test often so you can easily work-around what's missing from Mono
That's the same approach I'm using in my .NET Remoting program I host on Ubuntu server. But I do the reverse, since I'm a solo programmer, I make a shared folder on my Windows development machine, then access that shared folder on my Ubuntu test server (vmware'd). On ASP.NET stuff, if the changes don't reflect on your Ubuntu test server, in Terminal just touch the Web.Config file in your Ubuntu test server. i.e. touch Web.Config, then refresh the page
Mono has a fully functional implementation of ASP.NET. This includes full support for ASP.NET Web Forms and Web Services. This essentially means that more or less any ASP.NET application that you have developed using with the .NET Framework will work with Mono. Obviously there might be changes needed, such as data access changes, removal of any
reliance on .NET Framework BCL types . Mono- Oracle users-.Net Programming C# : ubuntu 11.04
Time to ask the pros, since I can't find a good answer anywhere else and I'm venturing into a side of the world that I'm just learning.
I'm in a primarily open source shop that has recently begun taking in a lot of internal tools and partners that are .Net based. That got me to thinking that I may be able to utilize the best of both worlds by leveraging C#/mono in certain spaces. On a small scale I've been very successful and it's working great. However, pressing 'Build' and scp'ing the exe into place isn't going to scale well.
I'd like to step it up a bit and get some more resources behind it, so here's my question; what are the baseline resources I need to establish a good dev/testing/staging environment.
I don't need uber-detailed information and I'm willing to consider both commercial and open source solutions, I guess I'm more looking for good advice on resources. 99% of the items developed on either side of the OS line will be services.
What sort of Unit/Regression testing tools are recommended, is NUnit the standard?
What sort of deployment mechanisms are recommended for service level software?
What, if any, additional tools have you found useful or indispensable during your development/design work?
The first 2 items are of interest since they are the last things I'm lacking before I have workable, repeatable development and deployment process.
You might want to look into http://go-mono.com/monovs/
It will alow you to debug on Linux from within Visual Studio.
The unit testing framework in Visual Studio is rather good as well,
but if you use the standard or free version of Visual Studio, NUnit is a good option as well
(And there is the option of Visual Studio integration)
Aside from that I've come quite attached to Refactor Pro (and other products by that company)
http://www.devexpress.com/Products/Visual_Studio_Add-in/Refactoring/
As for scp'ing the files to your linux/mac machines, it might be easier to
configure MSBuild to do that for you automatically.
This might help: http://bartdesmet.net/blogs/bart/archive/2006/04/13/3896.aspx
Many more msbuild tasks can be found here: http://msbuildcontrib.codeplex.com/
I hope this helps.
For build and deployment you might give NAnt a try. It'll handle your builds, and has tasks for running your tests, doing clean SVN checkouts, zipping up releases, that kind of thing. You can embed C# too. Grab the nightlies rather than the releases and don't worry too much about the lack of recent activity. Also the nant-contrib project is full of additional goodies.
Another option is to try msbuild (I believe there's a Mono equivalent, although I'm not sure to what degree). Truth be told there's not a lot of difference between the two.
I have built effective build/test/deploy infrastructure with the following:
NUnit
CruiseControl.NET (or CruiseControl)
NAnt (and NAnt Contrib)
or MSBuild (depends on your environment)
We also use subversion to manage both source control, as well as deployment (for things like CMS and website systems)
A few of the build tools we use are:
Simian
NCover
NDepend
Powershell (for both build automation as well as deploy automation and machine control)
Of course any of these tools can be substituted for other tools you like (perl, python, ruby, Ant, etc).
This is roughly how I've set up my environment at work:
I use NUnit as a unit-testing platform
I use TestDriven.NET as a plugin to easily run my unittests from within my IDE
I've set up a separate computer, which runs CruiseControl.NET
This CruiseControl.NET computer checks my source-repository on regular times. When it sees that something has changed, it gets the latest version from the source-repository and builds it. It also performs unit-tests, and runs fx-cop over the targets.
Next to that, i've configured it so that it performs a nightly build as well. This does roughly the same:
When something has changed during the day:
remove every file that exists locally
get the latest version from the source repository
build it
run unittests
run fxcop
create documentation using sandcastle helpfile builder
when the build was successfull, copy the build output to a separate folder which is named 'build-yyyymmdd'.
I've setup my source-repository so that I can keep different versions (branches) from my project.
In short, my source-repository looks like this:
I have a folder which is called
'devtrunk', which contains the actual
codebase. (On which I'm actively
developping)
I have a folder calles 'releases'.
Every time I release a new version, I
make a branch of the trunk, and I put
this branch in a new folder under
'releases'. This allows me to fix
bugs in a version that has been
released, without disturbing my
actual work on the trunk.
Since I'm working on the Windows platform, I use MSBuild to create my build-scripts (which are executed by Cruisecontrol), but, you can use NAnt instead. (Which I've used as well).