I have a solution which contains 5 C# projecst, 2 wix projects and a C project (2010). We have been developing this in VS2013 Ultimate and all has been fine. I've just tried opening the solution in VS2015, I have no errors, and no warnings. When I press the start button (F5), nothing happens. I don't even hit the first line of the Program.cs file. All it seems to do is build the project. Any ideas?
EDIT
The same project was open in both VS2013 and VS2015 at the same time as I was comparing config etc.
When I closed down VS2013, the program ran!
Not entirely sure why this occurred...
Yes the problem is indeed with running the same project in both Visual Studio 2013 and 2015 at the same time.
When you start the program, only the version of VS which was opened first will be able to run the program. This is because the first opened VS attaches the vshost.exe process to the project and denies any access to that exe, which is why the last opened version fails to attach its own vshost.exe. Thus it stops after building the solution.
The same project was open in both VS2013 and VS2015 at the same time as I was comparing config etc.
When I closed down VS2013, the program ran!
Not entirely sure why this occurred...
Related
I have a solution that was compiling and running fine in Visual Studio 2022. I added another project to the same solution, did some work on the new project and then checked it all into Devops. Now, everything compiles fine. I can "publish" to a folder and get the EXE and it runs. But I CAN'T run it in Visual Studio or by trying to run the EXE in the bin folder structure. When I click the run button in VS, I get:
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[21684] Enable Instant Book.exe' has exited with code 2147516551 (0x80008087).
Now, this is a Winforms application targeting .Net 6.0 on Windows. So I'm not sure why it's suddenly throwing this error nor why it says "CoreCLR" in the error when I'm not targeting Core. I'm so frustrated with it that I'm thinking of dumping it all and redoing it in VS 2019 with .Net 4.x. But I thought I would see if any of you knew some magic to get it to return to a working state first.
Some of the things I've tried:
Clean and rebuild
Remove all projects except the very first one that I know was working and rebuild
Close and reopen VS / Reboot PC
Delete everything in "bin" folder and rebuild
Changing the compile from "Any CPU" to x64
Any ideas?
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 have a strange behavior with Visual Studio 2013 and .Net Compact Framework:
I can compile my WinCE program correctly, I can deploy it and start in debug mode by pressing F5. Everything is fine. But if I change my program and press F5 the application is compiled but not deployed, debugging starts with the old application.
(after than I can deploy the application and start it by hand, so I see it's compiled but not deployed)
If I start a new solution, add a new Visual C# project it all works correct. It worked in my working solution but not anymore. My working solution has a 'C# Class Library', 2 C# projects and 1 C++ project.
Hardware is a Toradex Ixora with Windows Embedded Compact 2013, VS 2013 Update 5.
Ah, a little embarrassing:
Right click on solution -> expand 'Configuration Properties' -> click 'Configuration'
There the checkmarks are missing for 'Deploy'
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.
Starting from yesterday, whenever I try to open a C# project (.csproj) in visual studio
I get this 3 times:
And then I get this 1 time:
And thus it doesn't open the project.
This doesn't appear when opening C++ or VB projects, only C#
I have tried running the application with parameters like /resetsettings and /resetskippkgs but it didn't do.
Please help me solve the problem
Reinstall VS.
Try to open another project and see if you can open it, if it opens, copy the source files to the new project and continue as usually.
What version of VS are u using?
Your Visual Studio install has become corrupted. Reinstall Visual Studio ("Repair" should work ) and it should fix itself.