When I run my program with Visual Studio in debug mode I get a real slow down compared to release mode. I know that debug mode unoptimize code and especialy the one from Standard Library which I don't care about. However I really need to be able to debug an unoptimize code when I wrote it. Is there any way to keep Visual in debug mode with my code fully unoptimized while everything from the Standard Library is optimized ?
Cheers
Victor
My understanding is that you could change the project property for you project or referenced project like optimization or un-optimize if you have the project source code or you can re-compile it. Of course, if we enable the optimization for one project or reference project, it would impact some debugging feature more or less:
https://msdn.microsoft.com/en-us/library/606cbtzs.aspx?f=255&MSPPError=-2147217396
Related
I am building my window service c# project of VS 2010 in Release mode. My first chance to get surprised was that it's creating pdb files even in release in mode. I was not able to load the debug symbols after attaching the process for debugging.
My question is that if we have pdb files in both debug and release mode then why there is need for two compilation mode.
My question is that if we have pdb files in both debug and release mode then why there is need for two compilation mode
There are differences other than PDB generation between debug and release. If you go into the Build properties and go into "Advanced", there are different levels of debug information to be generated - Full, PDB-only and None.
In addition, there are different levels of compile-time optimization, and the presence of different preprocessor symbols (e.g. so that each Debug.Assert will be present or absent).
Of course you can have your own varieties of build configuration too, with a variety of options.
There are many reasons why there is a debug/release mode, unrelated to the creation of PDB files.
VS executes your compiled programs faster in release mode. In addition, there are compiler directives that can change the way the program behaves if you are in debug vs release mode. For example, you can use compiler directives to disable your top-level try catch blocks so that you can isolate an exception that is being thrown to a specific line of code.
That's just a couple of examples. In short, debug mode has many more purposes than just creating PDB files for you.
You can have more than two compilation modes. Usually, debug and release mean stand for whether you want optimizations or not. Regardless, you can still generate debug information, only a PDB for a release build won't be of much help. Inline functions, variables can be excluded, etc.
I recently did a winupdate(20120508) and Visual studio seemed to be really slow debugging afterwards
with a 1 minute delay after compile-to-runDebug lag, then when the debug program exited, another 1 minute delay to
get control again of visual studio. I did clean all, but no joy.
Solution: I manually deleted the *.sdf and *.suo files in my project/solution and rebuilt. Issue went away magically.
Not sure why, but something was out of sync, corrupted, or incompatible with the update and needed to be blown away manually.
I am creatinig Managed Extensibility Framework extensions for some program. That program uses dll files witch i create. I dont have visual studio project of that program, but i have that program. I can run these extensions using that program, but cant debug them properly.
Is it possible to use visual studio debugger to debug my code?
I found solution to this, thanks!
I found solution to this by my self, but thanks for sugestions.
I can use that app for which i am creating this extension, class libary project.
I press properties on project, then select debug tab and set "start external programm" an set it o that main app. then i press f5 and that app starts and when it uses my extension i can debug it using visual studio debugger. And i forgot to tell that i am creating this in C#.
http://msdn.microsoft.com/en-us/library/68c8335t.aspx
I believe what you are looking for can be found here:
http://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx
According to this article, you could use the "Add Existing Project" dialog in you solution (for your DLL) to add the executable that you do not have the solution for. Because you are using MEF, it might get a bit tricky and you might want to create a new solution for debugging instead. However, this seems to be the general way to handle your situation. Since you have the source code for your DLL, I believe it should allow you to step through your code fully at the very least.
Note: You will need to make sure you have Visual C++ installed in your development environment.
If you are trying to debug the assembly code, then you can use the technique discussed by #BiggsTRC, if you are simply trying to identify why parts aren't being loaded, you could consider looking at the Composition Analysis Tool (mefx). This is a command-line tool for analysing a set of parts and finding out where failures may occur during composition.
Reading this question, in the first comment, #Cody Gray says:
Erm, you know that you're not supposed
to redistribute the "Debug" version,
right?
I'm concerned about it. In Visual Studio, I usually develop my applications in Debug mode, and if I need to distribute the executable, all I do is zip the .exe and required .dll files (in bin\Debug folder).
Why is it a bad idea?
What is the difference between doing this and doing exactly the equivalent thing in Release mode?
Edit:
I asked this question time ago, but I just wanted to edit it to add a difference:
When using Debug.Assert in the code to test it, and compile in Release Mode, all those lines are gone, so that could be another difference.
It depends on what kind of language you use to develop your program. When you use C++, you get the overhead of /RTC and the Edit + Continue support. They slow down the generated code by a great deal and make it likely your app crashes early on a StackOverflow if you use recursion. The runtime exceptions you can get from the checking code can be hard to diagnose without a debugger.
If you use VB.NET then you'll easily have a unpluggable memory leak when you use the Debug build without a debugger. A flaw in its Edit + Continue support code causes a WeakReference to be leaked for every instance of a class that contains a WithEvents event. Your app eventually dies on an OutOfMemory exception.
If you use C# then not a heckofalot goes wrong, the JIT compiler is just prevented from generating optimized machine code and garbage collection isn't as efficient. Your program will run slow and consume more memory than necessary. This applies to VB.NET and C++/CLI as well.
Perf is usually foremost on a programmer's mind when writing code. As such, shipping the debug build is a bit blasphemous. A significant number of programs are however completely throttled by I/O, the disk, network card or the dbase server typically. Raw cpu perf doesn't matter a great deal in that case.
I think performance is an issue, this post has more detail
A pure C# or VB.NET application may work on any machine with the right .NET framework redist being installed, but a C++ or C++/CLI application (or a mixed application) needs the VC redist package, which does not contain the debug versions of the needed libraries. Assuming that on your users PC Visual Studio is not installed, only a redistributable package, I would say you have the risk that a debug version of your program simply might not work there.
There are legal reasons also -
Quote:
"Note that debug versions of an application are not redistributable and that none of the debug versions of various Visual C++ dynamic-link libraries (DLLs) are redistributable."
From Redistributing Microsoft Visual C++ 6.0 Applications
And this is for Visual Studio 2010 "Determining Which DLLs to Redistribute":
"You cannot redistribute all of the files that are included in Visual Studio; you are only permitted to redistribute the files that are specified in Redist.txt. Debug versions of applications and the various Visual C++ DLLs are not redistributable. From Determining Which DLLs to Redistribute
Regarding performance, I'd be interested to see some metrics about debug versus release.
Whilst I'm sure the metrics would vary depending on exactly what the application does, but my hunch is that most of the time the end user wouldn't know the difference.
I use a 3rd party DLL in my VB.NET project (VS2005) that responds to slow and give wrong values in debug mode. In run-time mode everything works as expected.
I do understand that there are something going on in the debug mode which makes the DLL communication slow. This behavior makes it hard to debug the application correctly.
Is there any way to force VS to communicate with the DLL in "run-time" mode during debugging but let the rest of the project be in control of the debugger?
I found a setting that resolved my issue:
Project Properties > Debug > Enable Debuggers > select "Enable unmanaged code debugging".
Now the DLL communication flowed smoothly. The DLL I use is a middleware between my app and a USB device. There is no Debug/Release version of the DLL.
Change the debug DLL for the release one, either by switching files or by telling the linker/build process to only use the release one, but like the comment above I'd suspect there's some funky stuff going on in both.
I'm curious about your thoughts on moving to a new IDE (specifically Eclipse). I have been hearing wonderful things about it from this community and I'm always on the lookout to try new things.
Currently I'm running Visual Studio 2005, with a bunch of external commands loaded (for compiling down to a binary, running lint, etc). We're developing C code for microcontrollers.
I've read over some of the other threads on here about the advantages and disadvantages to Eclipse and Visual Studio (specifically SO - best IDE thread and SO - best C IDE thread), but I'd like to hear your thoughts on using it for programming an embedded environment. I'd imagine that there is a simple way to use the external tools that Visual Studio currently uses (it simply calls various batch files that we've created).
Is it worth it to specifically switch over to Eclipse?
Answer to you question about way to call external tools: no problem - from eclispe you can anything: external program, batch file etc. Moreover, if you use custom build generator - you could use it transparent with eclipse.
I don't think I would switch from Visual Studio to Eclipse in hopes of getting a better IDE. Typically an embedded manufacturer makes plugins and toolchains that work specificially with Eclispe, that's what makes it worth using in the Embedded world. For example with the NetBurner plug-ins, when creating a new project you can just select New NetBurner Device Excecutable, or New NetBurner Library, all the default includes and libraries get set up for you and the proper cross platform tool chain is set up for you automatically. In the NetBurner case it also uses the Eclipse managed build process (as opposed to make files) which I find nice. There is also support for using make files if you prefer that option.
While I have a couple of tools set up to run as external tools (lint, an auto version updater, DOS prompt etc) most steps can be triggered from pre-build or post-build steps or there are many many add-ons for common needs like source code management, bug tracking, etc. There is great support for SVN, Trac and Mylyn for example. I use both VS2010 and Eclipse. I like them both but VS2010 is the better IDE. It's a little hard to compare because I do C# (and a little C++/CLI )in VS and C++ in Eclipse. That said, I wouldn't relish the though of trying set up VS to do my embedded tasks.