I have a solution which contains multiple C# projects. One of these projects is an executable, the rest are DLLs.
The problem is, some of the projects do not actually run on the same process as the executable start-up project. This is because some of the projects are really extensions to a WCF service that allow the service to play with the executable.
My question is: is it possible in any way, shape, or form to set a breakpoint in said projects? I am aware of the ability to "attach to process", but I'm not sure it is a good solution for me.
I want to:
Be able to see the source as I break
Not have two copies of Visual Studio open if possible
EDIT: the only reason I am not sure of 'attach to process' would work well for me is because I have little experience with that feature - perhaps it is what I should be using? Can I still load .pdb files?
EDIT 2: If one of the commenters would like to submit their comment as an answer, I will accept
Attaching to the WCF service seems to be the exact tool for the job:
It allows you to attach to a running process, even if you've only got the code and PDBs for a plugin/extension for that process. You can set breakpoints in your own code and they'll be hit when the 3rd-party process calls them.
You can attach to any process from an existing VS instance, even if that instance is used to debug a different executable, in this case your main EXE project. You can start debugging your app, then attach to the service before making the service call.
Make sure, though that the DLLs called by the WCF service are the same ones as you have in your VS instance - if they're called from the same location as the VS build output, you'll be fine. If not, make sure they're in sync.
Related
I have a Visual Studio C# project, and I would like to run/debug multiple instances of that project with different launch profiles for each instance. As this is something that I will be doing very frequently, it's important that I be able to run the projects with as few clicks/keystrokes as possible, ideally just 1.
I am aware of a handful of "almost" solutions that don't quite work, so I'll mention those and why they don't work for me:
It is possible to run multiple projects simultaneously when clicking the run/debug buttons, but this dialog does not appear to allow me to run multiple instances of the same project.
It is possible to right-click on the project and select Debug->Start New Instance, but Visual Studio doesn't allow me to change the launch profile while already debugging. (Plus that's a lot more clicks than I'd like.)
It is possible to start the project multiple times and then attach the debugger to each later, but I need the debugger attached to each from the very beginning. (Plus that's also a lot more clicks than I'd like.)
There is the very handy SwitchStartupProject Visual Studio extension, but I have been unable to get it to successfully launch multiple instances of the same project.
It is possible to run multiple instances of Visual Studio, but that will hog a ton more resources and, yet again, require too many clicks.
It is possible to create a "dummy" project that runs the EXE of the main project. This is the closest solution I've found, but it has the problem that it's tied to the location of the EXE built by the main project, so if I change the main project from Debug->Release (or vice-versa) then I have to first select the dummy project, swap its own launch profile to one that points at the correct EXE location, and swap back. This is a lot more work than I'd like to do for something I have to do so frequently. (In theory I could change both the Debug & Release configurations of the main project to output to the same location, but I have other tooling that assumes the default output locations.)
This is very easy to do if using Jetbrains Rider, but of course that requires switching to Rider, which is not something I'm ready to do right now.
Any ideas?
I am new to Visual Studio Express.
I am writing an Class Library and want to debug it, but I don´t get how I do that.
The dll is for an App which itself injects into an other Software. I have direct Access to that App.
So far I have attached the Debugger to the App, but what now? Do I have now to specify something so that always when I debug it a new Version is builded in the Plugin Directory of the App? Or shall I set my Working Dir to the Apps Plugin Directory?
I have read https://msdn.microsoft.com/en-us/library/aa291243%28v=vs.71%29.aspx and various other resources, but it never happens what is expected.
Add a new project to your solution that outputs an executable assembly, such as WinForms, Console, or Web.
Set this new project to be the startup project.
Add the Class Library project to the Executable projects references.
Write your test code.
Run the executable project.
I think that you may be confused what debugging in visual studio. Debugging in Visual Studio allows you to set breakpoints and see errors more clearly by highlighting the line of code that is throwing the error.
I am writing an Class Library and want to debug it, but I don´t get how I do that. The dll is for an App which itself injects into an other Software. I have direct Access to that App.
Library classes are hard to debug, b/c they won't want to run by themselves. I actually wouldn't call your class a library. Your code is an application that "hooks" itself into another software. You can debug your application by running it with a debugger attached (simply pressing start should attach the debugger unless you explicitly ask for it not to be attached in project settings) and then using your application to inject itself into another software. Any errors that result from the application while in testing will be caught by the debugger.
I am developing a DLL (in Visual C# Express) with some plugin logic for an application.
Is there any way to debug this DLL, once it get's used by the application? The application is running as a service on Windows, and it's a COTS application, meaning that it's not a C# project I can start debugging from.
I am aware that there are limitations regarding debugging in Visual C# Express. Is this task possible in Visual Studio Pro?
What I want to acheive is to be able to step through the logic, set break points to see what happends when the call comes. Any clues?
I am not sure about VS Express but, normally,
Open Visual Studio
Open your Solution (Windows Service Project)
Debug -> Attach To Process
Select your Service from Available Process List
You may use breakpoints and other stuff.
Hope it helps.
While I'm not entirely sure how this works with services specifically, you can set an arbitrary debug target.
In the debug panel (in project properties), you can set any executable or other command as the debug target. The process spawned by this command will have the debugger attached, regardless of whether where the executable came from. There are no requirements that the target be a C# project, or any Visual Studio project. This should be available in both Express and Pro. It's possible to attach to a later process (if you have a launcher), but that's probably beyond your current scope.
You then set breakpoints in your code as usual, and when the code is hit (regardless of whether your code calls it or the host executable), the breakpoint will be triggered. Depending on how much information you have about the host, you may be able to effectively debug it as well; even if you have no information, you'll be able to step through the assembly.
The only requirement here is that the target load and run your code. Depending on the context (plugin to a program, injected dependency, whatnot) this is of varying difficulty. The technique is used in a number of places, particularly plugin systems where you may not be able to debug the actual host, but still want to do so with your plugin.
Another, slightly uglier variation, is to force the host to break and self-identify. This is only useful for debugging, as it's very disruptive. The typical method is to show a message box (modal) with the process ID. The process will then be suspended until the message is dismissed, and a debugger can be attached. This becomes more difficult with services, although there are still ways to publish your information in a blocking fashion.
You could use the System.Diagnostics.Debugger.Break() method.
I'm coding an application on C#, and it runs perfectly fine when I click the "Run" button in Visual Studio C# Express 2010. But, when I go to Debug -> Build Solution, after I run the .exe file, it says "XXX.EXE has stopped working..."
I have inserted break-points and commented out chunks of my code, rebuilt the project, and ran again to try to isolate the problem, but I can't figure out what is causing this. The fact that it runs fine in debug mode is strange.
Some things to try:
Check the system Event log for ASP.NET errors.
Try setting the build to Release mode and using Run--no debugging. See if it crashes then. Watch the Output and other windows for any errors during/after the crash. Depending on those results, check that your solution and project properties are correct in both Debug and Release configurations.
You can also build in debug mode, launch it externally, than attach the Visual Studio debugger to the process. But of course if it crashes on startup than that won't work.
You can add Debug.Assert lines to see if you can get one of those to throw.
Wrap your code in a big try/catch and make sure your catch handler somehow reports or logs the full exception for you.
Adding logging would be good idea. You can log to a file or the system event log. I suggest log4net or similar logging tool for that.
I just had this issue and was going to see if I could catch when the error happened via a console window, when I changed my app to console based the program stopped crashing, I commented out all Console writes and set it back into a windows forms app and voila, runs fine now.
-I know its an old post, but its open and unanswered so I think its fair game.
Try adding your application to your Antivirus Whitelist or exclusion list. This is a known problem with McAfee and Avast!
I may be misunderstanding the problem, but if you are trying to run your app from its .exe file (originally located at Visual Studio ####\Projects\ProjectName\bin\x86\Debug\ProjectName.exe), you must make sure that that .exe file is in that original directory. You cannot move it. I ran into a similar problem with XNA projects. If you want to move the.exe file somewhere else, you can create a shortcut to it, but don't ever move it. If you try and run it from a different location, or if you move any of the other files from that directory, you'll get an error message exactly like the one you described.
Also note that some Visual Studio projects (like XNA ones) will not run as standalones. Building the projects doesn't export them into a standalone format, they can only run on computers that have VS and all the projects framework installed, and their .exe file must remain in its original place.
I have a C# console application written in Visual Studio 2008.
Usually I just build the application and then copy the files from the 'Release' folder but this time trying to do it 'properly' by publishing the application.
I went through the 'Publish Wizard' and end up with a 'Setup.exe' file in the specified folder. When running this setup file on another computer the install fails and indicates via a error message that:
Cannot download the application. The Application is missing required files...
When I select the 'details' button the error log shows that the program was trying to download files from the last version directory (ie 1_0_0_4).
What am I doing wrong? (aside from being tired...)
Show I de-activate the version auto-incrementing?
Unless you have a valid reason to do so, I would abandon the publishing and just go back to the XCopy installation. (And by Valid, I mean something other than someone told you that it's the "proper" way to do it.) I base this advice on the following arguments:
We used ClickOnce for all our WinForms apps for a while, but eventually it got to be more trouble than it was worth. For one thing, you need to deal with the security certificates. We had issues when we replaced a server with a new one with a different name, then we had issues when we replaced our development machines, etc.
You said this is a console application. ClickOnce publication seems to be overkill for a simple console application unless there are third party dependencies that you need to include in your install.
Don't get me wrong, I liked using ClickOnce for the ease of putting updates out there, and we use it still when it's the best option. However, in your situation, it looks to me like XCopy deployment should be sufficient for a simple console application.
Not knowing what you choose in the wizard, web or CD, the setup.exe file needs to be able to reference it's installation files. If using the CD method, you will notice in the output directory you revision directories, e.g. 1_0_0_4, where each revision of your app is kept. I agree with #David_Stratton, and unless you really need to use one-click publishing, don't. Just use xcopy (robocopy), zipfiles, etc. It will greatly reduce your stress levels down the road.
Everything David Stratton has stated is correct. ClickOnce is overkill for what you're trying to do, and publishing through Visual Studio has always given me headaches.
I might recommend taking a look at NSIS if you're looking for generating an installer for others. It's relatively simple to generate full installers that merely grab files from your /Release/ directory, with plenty of sample code for getting an installer working quickly. Once you have your working script, making your installers are as simple as a right-click and clicking compile.