I've got a C#/WPF application which was originally built in Visual Studio 2012. Eventually we upgraded to Visual Studio 2015 and that worked fine. Lately I've upgraded further to Visual Studio 2017 and now I'm having lots of problems. I've got the drop-down options set to "Debug," "Mixed Platforms," and my project name, and when I hit Start it does indeed start up my project. However any recent changes I make to the project don't get reflected.
At first I was wondering why a TouchUp event handler I had added wasn't seeming to be hit. Then after further experimentation, I changed one of the existing log messages slightly (we have a logger that logs to a local text file). However, it continues to log the old message. Another symptom of this is that none of my breakpoints get hit. When I add them it shows up as the standard red circle, but as soon as I press start they change to a white circle with a red perimeter, and the tool-tip hint says that it cannot hit the breakpoint because the source does not match what is running.
This is extremely frustrating as the debugger is one of those things that should just work. Has anyone else run into anything similar after upgrading to VS'17? Any advice?
So I found a workaround to my problem, but not a solution. When I deleted the files from the "bin" folder, it just stopped working altogether. So instead I manually built the project using MSBuild, in the C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin folder. The two commands I ran in succession were:
MSBuild.exe /target:Clean /p:Configuration=Debug /p:Platform="Any CPU" MySolution.sln
MSBuild.exe /target:Build /p:Configuration=Debug /p:Platform="Any CPU" MySolution.sln
In fact, I don't really need to do the "Clean" step every time, and this works. However it's really quite slow and I am genuinely surprised that VS apparently isn't doing this automatically, under the hood.
Related
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
I had been trying out some of the Performance Profiler tools in VS 2017. All was working great except when I tried the Instrumentation profiling method. It asked to elevate the permissions of that process. Which I did.
Now every time I try to debug my app, I get an error that the VSPerf "Instrumention" Tool has stopped working.
I've tried everything, clearing out my .vs folder, bin folders, looking through the .csproj and .sln files. Completely repairing Visual Studio and removing whatever references I could find to "performance" in the options. It's getting really irritating.
Any suggestions?
For some reason I just started having an issue with my release builds.
I'm able to run any of my projects without issue from the debug builds, I can also run my release builds as long as I attach a debugger, but when I try to run the release builds on their own they either hang infinitely (The UI crashes, but I'm unable to stop the process with task manager), or they load up EXTREMELY slowly (I've only ever had them eventually load twice, and that was on a separate machine from my main PC).
I know I don't have any viruses or any other system issues (I take very good care of keeping my system extremely clean), and I've tried running the programs with AV disabled.
Nothing I do seems to make a difference, and the fact that debug builds of my projects perform exactly as expected leads me to believe somehow I've altered a setting in VS regarding how it builds releases or something similar.
Could this be the case? If so, how should I go about fixing it?
If you need any more information please let me know.
EDIT: Something else I've just noticed about this issue is, the only time I'm able to run any of the executables I've built is if they are in the bin\debug\ folder of my project. That includes copying the "release" build of my project into the debug folder. It then runs just fine. I've also tried building an installer for my project, and it also will only run while in the debug folder, and nowhere else on my system. Doesn't seem to matter whether it's a release or debug build, as long as it's in that folder.
I ended up doing a complete uninstall of Visual Studio Community 2015 and all of the runtimes/etc. that were installed on the same date as VS, and reinstalled the program.
I then deleted all of the debug/release builds for my project, cleaned the solution and rebuilt them.
So far everything seems to be working okay now.
I'm not sure what the issue was, but a fresh install seemed to fix it.
I use unmanaged dll with P/Invoke in this app, and I always tested it inside Visual Studio (with debug mode on x86 CPU because the dlls are only x86), and it works just fine. But when I just start the exe manually after some time (probably at the first operation with those dlls, but I don't know exactly) it says the exe has stopped working, and it starts checking for solution (I use Visual Studio 2013 on Windows 8.1, if that matters). I tried to add the dlls to the project as existing item, but that doesn't help. Also I know, that it's not because it can't find those dlls, cause if I delete them, it doesn't crash, just freeze without any error message. Shouldn't it work the same from Visual Studio as manually started?
There is also a weird bug when I run from Visual Studio: everything's work fine, but sometimes Visual Studio just suddenly stops debugging, as if the program were closed and the GUI of my app freezes, and I can only close it by closing Visual Studio (as I close it, the GUI disappears). Maybe it's a totally different problem, but it can be connected.
Edit:
Here's the project on github, if somebody could check it:
https://github.com/geiszla/CycriptGUI
Some news: If I run it with Ctrl+F5 it also crashes. What's the difference between F5 and Ctrl+F5, that can cause this problem?
Searched all over Google with no real simple answers. Here it is folks(at least it worked for me and is simple):
When you run the console app in Visual Studio, look at the output window at the bottom, get the location of the ..\bin\Debug\*.exe
Copy the *.exe and the *.config to your desired folder, run it, it should work the same way in Visual Studio.
Thanks for every help, my problem was solved: I called an unmanaged function with only 2 parameters, while it had 3. However I still don't understand why it worked with debugging mode, and not without debugging.
The problem I have run into twice now is that my program seems to be running code that no longer exists. I figure that some old version is stuck some how but have no idea how to get the compiler to run the updated code I've written.
The way I have spotted the problem is by observing that bit maps I've loaded keep getting drawn even after I've removed instructions to do so. The problem persists even after removing every reference to the image in question, content load lines included.
The first time this happened restarting the compiler didn't fix the problem but restarting the computer did. Now the problem has persisted after a full shutdown.
I m using ms C# 2008 express edition if that has any bearing.
My first thought would be that the build is failing and that Visual Studio is running the old version. I don't have VS 2008, but in VS 2010 the option to change this option is in Tools->Options->Projects and Solutions->Build and Run.
You have to figure out where the mismatch is coming from.
What happens when you run the .exe from outside VS? What about from inside VS? Can you verify that after a build, the binary you're executing has an updated timestamp? Is the stale code in a .dll where the new version isn't getting pulled in?
In my experience this happens when configuration profile is changed from debug. For instance if I am running the debug profile, it works. Then I change to the QA profile and make changes and then build the new assemblies. The assemblies are built to a directory called "QA" however, when I debug through visual studio it runs the code from the debug profile. I can remove references, recompile the code, visual studio will still run from the debug profile. It appears that none of the changes I made are in the code. When in reality I'm inadvertently running a old build.