I use a third-party dll in my application developed in Visual Studio 2010 and C#. When I debug my application by clicking the "Run (Debug)" button in Visual Studio 2010, that dll can detect and know that I am in so-called "development mode".
When I go the bin/debug folder and double click my application's exe file, the dll doesn't complain.
How can I configure so when I run the application in "development mode", the dll still thinks that it is executed in normal mode?
It's probably checking Debugger.IsAttached.
Solution: Don't use the debugger.
Real solution: Buy the library.
Depending on what the library does, it may be possible to separate out your application into separate components, one of which uses the library and does not run in debug mode. This will allow you to debug your application while still using the library.
Pro: What you are trying to do is definitely in violation of the license. This solution might not be in violation of the license.
Con: This will make it impossible for you to debug your use of the library. All it accomplishes is to allow you to debug the rest of your application by separating off the library usage.
Con 2: This will probably makes your application more difficult to maintain. It may also impact performance.
Related
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
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.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
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.